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
105 sourcesSince the parent is content to just argue, in the interest of transparency, we have made one or two small fixes so far.
Specifically, I'm thinking of https://github.com/rust-lang/rfcs/pull/1214 , which was a soundness fix that went through warnings in 1.4 and became an error in 1.7.
Code like this:
struct Foo<'a, X> {
f: fn(&'a X)
}
Would compile on 1.4, but not 1.7. The fix is:
struct Foo<'a, X: 'a> {
The compiler would tell you exactly what to replace, and that's all it took to upgrade. This was worth fixing a soundness hole. We originally thought that it would become an error in 1.5, but we monitored the ecosystem to see how many packages upgraded, and it wasn't until 1.7 that we were comfortable making the change. This meant that there was no effective break, even though code technically broke.
Those are the circumstance
Read the rest
s in which this might happen: very important, yet trivial to fix. We've only done it once or twice, and the vast majority of code written in the real world that built on 1.0 in practice builds on 1.14 today.
Trust me; we hear you. pre rust 1.0 was not pleasant, and it was even my job to keep up with the changes.
For more on how this works:
https://blog.rust-lang.org/2014/10/30/Stability.html
https://github.com/rust-lang/rfcs/blob/master/text/1122-lang...
https://github.com/rust-lang/rfcs/blob/master/text/1105-api-...
These are the RFCs and policies we came up with when cutting 1.0. I haven't read them in a while, but there haven't been any changes. Some of the text and/or examples might be reflective of the time they're written.
Oh, and one more thing: we have a tool, "crater", that we run every so often against every open source package in the ecosystem to make sure things don't break. Some of the most popular packages are built on every commit, as well.
In The Resurgence of C ProgrammingI do agree that there is a problem with the nightly/stable split in Rust, but I think a big part of this problem will be solved by macros 1.1: https://github.com/rust-lang/rfcs/blob/master/text/1681-macr...
In The Rust split: stable vs. nightlyWe're in the process of addressing discoverability of the crates.io ecosystem, which led to this RFC: https://github.com/rust-lang/rfcs/pull/1824
A quote from it:
> By far, the most common attribute people said they considered in the survey was whether a crate had good documentation. Frequently mentioned when discussing documentation was the desire to quickly find an example of how to use the crate.
Open source projects, in a sense, are like startups: if you want to acquire users, your users have to be able to understand the product! A deeply impressive technical project is, well, impressive, but if nobody can figure out how to use it, it's not going to see nearly as much uptake as a technology that's got a clear and easy way to use it.
There's secondary effects too: a project with a slick website like this makes people take it more serio
Read the rest
usly. It's less likely that someone who put this much effort in is just going to drop it immediately, though of course, that's not an absolute rule.
TL;DR: developers are users too. Developer marketing matters!
Yes. It's a perfect storm of coincidences, basically. It's a combination of timing + a tiny feature.
Let's take a step back. Macros 1.1 is RFC 1681: https://github.com/rust-lang/rfcs/blob/master/text/1681-macr...
See the section saying "The initial implementation of librustc_macro is proposed to be incredibly bare bones:" it really is very, very small. So it landed, and while there was some questions that came up, people migrated to it, and it works well.
22 days ago, it was to be reviewed: https://github.com/rust-lang/rust/issues/35900#issuecomment-...
However, two things happened: one, the Mozilla all-hands in Hawaii, which shook things up, but secondly, that meant a lot of people, including one of the reviewers, took PTO around that time, to actually see some of the islands. That includes someone who was on the reviewers list. So in ge
Read the rest
neral, "oh hey this is waiting on one person who forgot to check a box but isn't reachable now" is awkward.
Luckily, in this case, we know that it was just forgetting to check the box; Felix did not have any objections that we were aware of. So we decided to sign off for him, and put it into FCP. This happened so that FCP technically passed the deadline for 1.15, but given how important it is to ship, we're planning on nominating it for a backport, and don't anticipate complaints.
So: tiny feature, code wise. Big win for being stable. Procedural mishap involving awkward scheduling. All these things played into it. Make sense?
I've seen the "..." used for matching a range of values, whereas ".." is used in other places where we disregard a value while patter matching.
I'm sure someone from the rust team can give a better answer, but to me this change looks like it was just bringing the pattern matching for structs to be consistent with other uses of ".."
Relevant RFC: https://github.com/rust-lang/rfcs/blob/master/text/1492-dotd...
In Announcing Rust 1.14Ah, in that case I suppose it's blocked by lack of type parametrization with integers: https://github.com/rust-lang/rfcs/issues/1038 https://github.com/ticki/rfcs/blob/pi-types/text/0000-pi-typ...
In Rust: 128 bit integers preparing to be releasedIn case anyone else is interested in reading it, the relevant RFC is here: https://github.com/rust-lang/rfcs/blob/master/text/1504-int1...
In Rust: 128 bit integers preparing to be released> Also, looking at the byteorder crate, I wouldn't be surprised if it's even slower than the simpler and correct loop I posted elsethread. read_num_bytes in that create uses copy_nonoverlapping, which I assume is analogous to memcpy in C. That's a very round-a-bout and inefficient way to accomplish the task, and likely patterned after similarly bad C code.
It wasn't patterned after any C code. ptr::copy_nonoverlapping doesn't necessarily compile down to memcpy. Namely, concrete sizes are given, so the compiler backend can optimize this down to simple loads and stores on x86, which is probably going to do better than the bit-shifting approach. Namely, loading a little-endian encoded integer on a little-endian architecture should be as simple as a single word-sized load (because the byte swap is unnecessary). It would be interesting to cons
Read the rest
ider whether the safer and more readable bit-shifting approach could be compiled down to the same code, but when I wrote the byteorder crate, this wasn't the case.
This isn't the only place that ptr::copy_nonoverlapping is useful. I used it in my snappy[1] implementation as well, specifically to avoid the overhead of memcpy. To be clear, this wasn't my idea. This is what the C++ Snappy reference implementation does as well. Avoiding memcpys in favor of unaligned loads/stores is a dramatic win. I know this because I tried to write my Snappy implementation without specific unaligned loads/stores, and it performed quite a bit worse. The performance of the Rust implementation is now on par with the C++ implementation. Of course, this is always dealing with raw bytes---there's no type punning here.
ptr::copy_nonoverlapping is a bit generic for this use case. That's why we recently accepted an RFC to add read_unaligned/write_unaligned to the standard library[2]. (Which are implemented via straight-forward calls to ptr::copy_nonoverlapping.)
[1] - https://github.com/BurntSushi/rust-snappy/blob/master/src/de...
[2] - https://github.com/rust-lang/rfcs/blob/master/text/1725-unal...
128-bit Primitives for Rust (RFC 1504)
5 points · Open discussionHow far along is the effort for efficient code reuse (such as filling the gaps of lack of inheritance)?
I.e. this:
* https://github.com/rust-lang/rfcs/issues/349
* https://github.com/rust-lang/rust/issues/31844
Is it something coming soon, or it's pretty far still?
In Announcing Rust 1.13So do all the functions have to have the same error type as the function that is calling them? I don't know rust, but in haskell notation, if a function returns "Either x y" would it then only be able to use the "?" notation on functions that themselves return "Either x z", and not on functions that return "Either a b" (so, failure sides have to match, but success sides are flexible)?
EDIT:
Answering my own question: https://github.com/rust-lang/rfcs/blob/master/text/0243-trai... makes it pretty clear; the error types must be the same. Which completely makes sense.
In Announcing Rust 1.13This is a better link, as it will include the discussion: https://github.com/rust-lang/rfcs/pull/1774
In 2017 Rust RoadmapIt's important to note that this is an RFC which has been proposed, and there's likely to be a good deal of discussion and revision before it's merged/adopted as the official 2017 roadmap.
The conversation can be followed/joined/whatever here: https://github.com/rust-lang/rfcs/pull/1774
In 2017 Rust RoadmapShowing the 15 most recent of 105 sources. Enable JavaScript to search and browse every indexed mention.