The discussion highlights significant new features in Rust 1.100, such as the stabilized never type and unused dependency warnings, while sparking a substantive debate over whether the language's lack of a stable ABI is a necessary trade-off for its generic system or an impediment to library distribution. Participants clash between those viewing the current source-only model as sufficient and those arguing that a native stable ABI is essential for practical binary interoperability.
66 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4rust-lang
rfcs
Markdown2014–2026
rust-lang / rfcs
rfcs
RFCs for changes to Rust
352Distinct people
685Mentions
5Explicit recommenders
6.6KGitHub stars
What to know before exploring
What it is
RFCs for changes to Rust
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
It is completely the answer to your question. Note that Rust does not have green threads (RFC 230: https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...), so without…
halostatue used a recommendation phrase. 5 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- rust-lang/rust · linked in 55 of the same discussions
- alexcrichton/futures-await · linked in 2 of the same discussions
- jeff-davis/postgres-extension.rs · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:02:50 PM UTC.
The discussion centers on whether the *sshole vulnerability in musl was a failure of C language design or poor engineering norms, with some arguing that Rust's community standards prevent such logic errors while others contend it is merely a programmer mistake. Critics of the original article argue that blaming C for this specific issue ignores the role of individual developer responsibility and existing safety features in other languages.
42 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4Mentions over time
HN mentions by year685 dated mentions
Observed mentions: 2014-04-09 12:17:16 UTC to 2026-08-22 09:34:08 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 50 | 5 | 45 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 87 | 1 | 86 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 105 | 5 | 100 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 81 | 5 | 76 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 64 | 6 | 58 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 41 | 3 | 38 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 63 | 11 | 52 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 46 | 3 | 43 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 38 | 2 | 36 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 44 | 2 | 42 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 31 | 1 | 30 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 22 | 2 | 20 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 13 | 0 | 13 |
From the project README
An excerpt from the repository, fetched Nov 12, 2026.
Read the project’s introduction
Rust RFCs - RFC Book - Active RFC List
The "RFC" (request for comments) process is intended to provide a consistent
and controlled path for changes to Rust (such as new features) so that all
stakeholders can be confident about the direction of the project.
Many changes, including bug fixes and documentation improvements can be
implemented and reviewed via the normal GitHub pull request workflow.
Some changes though are "substantial", and we ask that these be put through a
bit of a design process and produce a consensus among the Rust community and
the sub-teams.
Table of Contents
Opening
Table of Contents
When you need to follow this process
Sub-team specific guidelines
Before creating an RFC
What the process is
The RFC life-cycle
Reviewing RFCs
Implementing an RFC
RFC Postponement
Help this is all too informal!
License
Contributions
When you need to follow this process
You need to follow this process if you intend to make "substantial" changes to
Rust, Cargo, Crates.io, or the RFC process itself. What constitutes a
"substantial" change is evolving based on community norms and varies depending
on what part of the ecosystem you are proposing to change, but may include the
following.
Any semantic or syntactic change to the language that is not a bugfix.
Removing language features, including those that are feature-gated.
Large additions to std.
Some changes do not require an RFC:
Rephrasing, reorganizing, refactoring, or otherwise "changing shape does
not change meaning".
Additions that strictly improve objective, numerical quality criteria
(warning removal, speedup, better platform coverage, more parallelism, trap
more errors, etc.)
Additions only likely to be noticed by other developers-of-rust,
invisible to users-of-rust.
Minor additions to std: these only require an ACP.
If you submit a pull request to implement a new feature without going through
the RFC process, it may be closed with a polite request to submit an RFC first.
Sub-team specific guidelines
For more details on when an RFC is required for the following areas, please see
the Rust community's sub-team specific guidelines for:
language changes,
library changes,
compiler changes.
Before creating an RFC
A hastily-proposed RFC can hurt its chances of acceptance. Low quality
proposals, proposals for previously-rejected features, or those that don't fit
into the near-term roadmap, may be quickly rejected, which can be demotivating
for the unprepared contributor. Laying some groundwork ahead of the RFC can
make the process smoother.
Although there is no single way to prepare for submitting an RFC, it is
generally a good idea to pursue feedback from other project developers
beforehand, to ascertain that the RFC may be desirable; having a consistent
impact on the project requires concerted effort toward consensus-building.
The most common preparations for writing and submitting an RFC include talking
the idea over on our official Zulip server, discussing the topic on our
developer discussion forum, and occasionally posting "pre-RFCs" on the
developer forum. You may file issues on this repo for discussion, but these are
not actively looked at by the teams.
As a rule of thumb, receiving encouraging feedback from long-standing project
developers, and particularly members of the relevant sub-team is a good
indication that the RFC is worth pursuing.
What the process is
In short, to get a major feature added to Rust, one must first get the RFC
merged into the RFC repository as a markdown file. At that point the RFC is
"active" and may be implemented with the goal of eventual inclusion into Rust.
Fork the RFC repo RFC repository
Copy 0000-template.md to text/0000-my-feature.md (where "my-feature" is
descriptive). Don't assign an RFC number yet; This is going to be the PR
number and we'll rename the file accordingly if the RFC is accepted.
Fill in the RFC. Put care into the details: RFCs that do not present
convincing motivation, demonstrate lack of understanding of the design's
impact, or are disingenuous about the drawbacks or alternatives tend to
be poorly-received.
Submit a pull request. As a pull request the RFC will receive design
feedback from the larger community, and the author should be prepared to
revise it in response.
Now that your RFC has an open pull request, use the issue number of the PR
to rename the file: update your 0000- prefix to that number. Also
update the "RFC PR" link at the top of the file.
Each pull request will be labeled with the most relevant sub-team, which
will lead to its being triaged by that team in a future meeting and assigned
to a member of the subteam.
Build consensus and integrate feedback. RFCs that have broad support are
much more likely to make progress than those that don't receive any
comments. Feel free to reach out to the RFC assignee in particular to get
help identifying stakeholders and obstacles.
The sub-team will discuss the RFC pull request, as much as possible in the
comment thread of the pull request itself. Offline discussion will be
summarized on the pull request comment thread.
RFCs rarely go through this process unchanged, especially as alternatives
and drawbacks are shown. You can make edits, big and small, to the RFC to
clarify or change the design, but make changes as new commits to the pull
request, and leave a comment on the pull request explaining your changes.
Specifically, do not squash or rebase commits after they are visible on
the pull request.
At some point, a member of the subteam will propose a "motion for final
comment period" (FCP), along with a disposition for the RFC (merge, close,
or postpone).
This step is taken when enough of the tradeoffs have been discussed that
the subteam is in a position to make a decision. That does not require
consensus amongst all participants in the RFC thread (which is usually
impossible). However, the argument supporting the disposition on the RFC
needs to have already been clearly articulated, and there should not be a
strong
Read the full README on GitHubWhat Hacker News says
81 sourcesSorry for not responding sooner, but I agree with you completely that the right thing to do is not to focus on "how many" `unsafe` lines you have, but how well encapsulated they are into a module that can't be broken by outside input. And I'm glad we both see this. My "problem" is less that `unsafe` doesn't do the things I mentioned, but that whenever Rust and `unsafe` come-up there tends to be lots of people who don't understand what it is, or how it works, and I think that is a very dangerous mindset because it leads to completely pointless (and dangerous, from a safety perspective) stuff like how that paper literally measured how many lines were `unsafe` and displayed it as a percentage to prove their code was good.
With all that said, while this is a separate topic, I think that the complete lack of a spec for lots of details surround
Read the rest
ing `unsafe` makes it still basically impossible to do correctly. I think Rust really needs some type of language spec, but it doesn't look like any work is being done on that front [0].
[0] https://github.com/rust-lang/rust/issues/30500 - I apologize for this link being a bit of a rabbit-hole, but I think the whole thing is a very interesting read. It continues on here (https://github.com/rust-lang/rfcs/issues/1447), and then to a repo for a Rust Memory Model specification here (https://github.com/nikomatsakis/rust-memory-model). Unfortunately, as you can probably tell, those conversions started in Dec 2015, and any real work on this front seems to have stalled almost a year ago.
https://github.com/rust-lang/rfcs/blob/master/text/1598-gene... has all the gory details, reading that is probably best!
In Announcing Rust 1.22You can write Rust in a quite functional matter, but as a language it works quite differently from Haskell or Scala. There's been a lot of discussion [1] around extending the type system to support something akin to higher-kinded types. The current result is the RFC you can find in [2], as well as a work-in-progress implementation of a new trait-resolution system for use in the compiler [3].
[1]: http://smallcultfollowing.com/babysteps/blog/2016/11/02/asso...
[2]: https://github.com/rust-lang/rfcs/pull/1598
[3]: http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowe...
In Announcing Rust 1.22This DSL seems largely motivated by the desire for provable compile-time bounds checking. One general-purpose modern language that can check bounds at compile time and generate code that is performance-competitive with C is ATS:
http://www.ats-lang.org/
Dependent types are meant to solve exactly this class of problem. Rust has an RFC for adding these:
https://github.com/rust-lang/rfcs/issues/1930
In Puffs: Parsing Untrusted File Formats SafelyTo add a little context here:
> 2. Arrays in Rust are a second-class citizens, actually I think they don’t even have their visas. I hear them laughing at me when I try to use them. You can’t even clone them:
RFC 2133[1] adds Clone to Arrays (and Tuples), it has been merged and implemented[2].
> 3. Rust is still “discussing” integer as generic type parameter (since 2015), meaning a matrix type Matrix[M, N, float] will not exist before a long long time. The following github discussions are quite the read:
It links to a bunch of stuff, but fails to recognize that this also has a merged RFC [3] and implementation is actively worked on[2].
[1] https://github.com/rust-lang/rfcs/pull/2133
[2] https://github.com/rust-lang/rust/pull/43690
[3] https://github.com/rust-lang/rfcs/pull/2000
[4] https://github.com/rust-lang/rust/issues/44580
In Why Rust fails hard at scientific computingSee the second paragraph of my comment with regard to representing matrices efficiently with just slices. I would argue that Rust is actually better here than most languages, as its native multidimensional "arrays" (slices) are equivalent in memory usage and performance to single-dimensional ones.
More generally, the 1-32 issue should be solved when RFC 2000 is implemented [0]. In the meantime there's generic-array [1], built on top of typenum [2], which you could think of as a sort of polyfill.
[0] https://github.com/rust-lang/rfcs/blob/master/text/2000-cons...
[1] https://github.com/fizyk20/generic-array
[2] https://github.com/paholg/typenum
In Why Rust fails hard at scientific computingRe: (3), this one: https://github.com/rust-lang/rfcs/pull/2000
In Why Rust fails hard at scientific computingRe: (2), this RFC was merged: https://github.com/rust-lang/rfcs/pull/2133
In Why Rust fails hard at scientific computingHow do you handle real-time thread priorities and CPU affinity? I work in soft real-time software as well (feedback control for humanoid robots) and I've been wanting to play around with Rust for real-time programming for a while. Given that your workload is parallel I would imagine CPU pinning is pretty important for making your deadlines. Since my current job involves maintaining a bunch of natively bridged code to add real-time scheduling to a non-realtime environment (Java) I don't wanna muck around with it until the language itself adds the stuff needed to the native API.
I've been watching this RFC[1] for years waiting for some notion of progress of support for this in the language itself. Doesn't seem to be a lot of focus on it right now.
[1]: https://github.com/rust-lang/rfcs/issues/819
In Rust for real time audio analysisThe box keyword isn't in stable Rust yet, and isn't even "the box keyword" anymore. https://github.com/rust-lang/rfcs/blob/master/text/1228-plac... is the latest RFC I believe, but even that I believe is changing since the latest allocator API work, though I'm not 100% sure.
In Enabling Rust on Embedded Platforms – Linux, RTOS, Bare MetalRust with https://github.com/rust-lang/rfcs/blob/master/text/2000-cons... should be better positioned to pay physicists real dividends than C++. Fingers crossed!
In Why physicists still use Fortran (2015)Yes.
The issue is actually being worked on. For example, the draft RFC for fallible collection allocations is now in final comment period [0].
Edit: fix link
[0] https://github.com/rust-lang/rfcs/pull/2116
In Enabling Rust on Embedded Platforms – Linux, RTOS, Bare MetalIt's not about an RFC; it's that at the impl period days at RustFest, Oli managed to get Miri integrated into the compiler and bootstrap for the first time. https://github.com/rust-lang/rust/pull/45002
https://github.com/rust-lang/rfcs/blob/1f5d3a9512ba08390a222... is the relevant historic RFC; still not yet stable. This work is what will enable a follow-on RFC for "real" CTFE in Rust, which in my understanding has been waiting for this to shake out. https://github.com/rust-lang/rust/pull/25609 landed right around 1.0, two years ago, but real CTFE required waiting on MIR, which took a while to land, and then building Miri in the first place.
In Enabling Rust on Embedded Platforms – Linux, RTOS, Bare MetalTo explain more besides Steve's commit, there has been another RFC that significantly expands the scope of impl Trait. It was accepted, but it also had the effect of punting the stabilisation of the feature a bit until things settle down. I don't know if the "conservative" version of impl Trait is going to land first anyway, but I find it just reassuring that people aren't rushing things.
(For reference:
The original impl Trait: https://github.com/rust-lang/rfcs/pull/1522
The refinement, readying it for stabilisation: https://github.com/rust-lang/rfcs/pull/1951
The latest one, which gives it more expressive power: https://github.com/rust-lang/rfcs/pull/2071
)
In Rust 1.21> the bar is high and Rust has set the bar
I don't think Rust deserves much praise for its module system. It is widely regarded as being extremely confusing even for pros. There are efforts underway to make it saner:
https://withoutboats.github.io/blog/rust/2017/01/04/the-rust...
https://github.com/rust-lang/rfcs/pull/2126
In Killing the C++ Modules Technical SpecificationShowing the 15 most recent of 81 sources. Enable JavaScript to search and browse every indexed mention.