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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM UTC.
Mentions 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
44 sourcesRust has had a stable SIMD vector API[1] for a long time. But, it's architecture specific. The portable API[2] isn't stable yet, but you probably can't use the portable API for some of the more exotic uses of SIMD anyway. Indeed, that's true in .NET's case too[3]. So .NET has to rely on "manually vectorized with intrisics for each individual platform" as well.
Rust does all this SIMD too. It just isn't in the standard library. But the regex crate does it. Indeed, this is where .NET got its SIMD approach for multiple substring search from in the first place[4]. ;-)
You're right that Rust's standard library is conservatively vectorized though[5]. The main thing blocking this isn't the lack of SIMD availability. It's more about how the standard library is internally structured, and the fact that things like substring search are not actually
Read the rest
defined in `std` directly, but rather, in `core`. There are plans to fix this[6].
With all that said, I wouldn't necessarily disagree with the broader point in this thread. .NET's regex engine performance is quite impressive[7]. (And I still have to merge the PR updating to .NET 8.) I'm really only replying here to correct more narrow points.
[1]: https://doc.rust-lang.org/std/arch/index.html
[2]: https://doc.rust-lang.org/std/simd/index.html
[3]: https://github.com/dotnet/runtime/blob/72fae0073b35a404f03c3...
[4]: https://github.com/dotnet/runtime/pull/88394#issuecomment-16...
[5]: https://github.com/BurntSushi/memchr#why-is-the-standard-lib...
[6]: https://github.com/rust-lang/rfcs/pull/3469
[7]: https://github.com/BurntSushi/rebar#summary
Mara's blog post also describes the benefits of standardizing Rust.
Since she created the RFC for standardizing Rust (https://github.com/rust-lang/rfcs/pull/3355) and is also on the team that is working on Rust standardization (https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...), I think she was making the point that Rust has good controls in place for adding features while compatibility, not that "Rust does not need a standard".
If she really believed that Rust does not need a standard, why would she create the RFC and join the team working on the effort?
Rust is a great language. There is no reason why it should not have a standard to better formalize its requirements and behaviors.
In Progress toward a GCC-based Rust compilerRust needs a language standard:
https://blog.m-ou.se/rust-standard/
https://rust-lang.github.io/rfcs/3355-rust-spec.html
https://github.com/rust-lang/rfcs/pull/3355
There are many organizations and industries that will not adopt Rust until it has a standard.
C, C++, C#, and even JavaScript (ECMAScript) have language standards. Why shouldn't Rust have one too?
C: https://www.iso.org/standard/74528.html
C++: https://isocpp.org/std/the-standard
C#: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
JavaScript / ECMAScript: https://ecma-international.org/publications-and-standards/st...
In Progress toward a GCC-based Rust compilerAs others pointed out, there also exists `bool::then` that always accepts a closure and doesn't have this issue. In fact both `bool::then` and `bool::then_some` are originated from a single RFC [1], and people unanimously agreed on `bool::then` but not `bool::then_some`, so the latter spun off its own issue [2]. It seems that `bool::then_some` was eventually accepted mainly due to the lack of better alternatives---there were enough people wanting the value form and other pairs of method names were considered better.
[1] https://github.com/rust-lang/rfcs/pull/2757
[2] https://github.com/rust-lang/rust/issues/64260
In Bug in my code from compiler optimization [video]> One of the more under-appreciated features of Rust is that it traps on integer overflow / underflow by default.
I think this is only true on debug builds, with --release (which most Rust binaries an end-user uses should be compiled with) it just wraps [1] [2]
[1] https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db2...
[2] https://stackoverflow.com/a/60238510
In OpenBSD – pinning all system callsHere is the original GitHub issue on the question:
https://github.com/rust-lang/rust/issues/15699
And an RFC by some people that felt frustrated by this arguably implementation-centric view that kind of lost steam:
https://github.com/rust-lang/rfcs/issues/391
Intuitively, the bottom lifetime should the one that is uninhabited, which would be a lifetime with no extent rather than 'static.
In Common Rust Lifetime Misconceptions (2020)We have an RFC for this that has fairly broad support that I just need to bug some people some more so we can approve it.
https://github.com/rust-lang/rfcs/pull/3243
In Was Rust Worth It?> It also looks like (soon) you’ll finally be able to configure global lints for a project. Until now, you had to hack your solution to keep lints consistent for projects. In Wick, we use a script to automatically update inline lint configurations for a few dozen crates. It took years for the Rust community to land on a solution for this, which brings us to…
Wow, as the author of that feature, I'm surprised to see someone was so passionate about it. I've found that many times I've been having to tell people why they should care about it.
> I don’t know why. Maybe the pressure to maintain stable APIs, along with Rust’s granular type system, makes it difficult for library owners to iterate. It’s hard to accept a minor change if it would result in a major version bump.
There is a tension between people wanting features and people not wantin
Read the rest
g to deal with version bumps. I've seen this a lot in maintaining clap, especially when it went from unmaintained for years to having active releases.
As for cargo, the compatibility guarantees are tough. Take the lints table. We can't throw in a first try, knowing we can fix in in a cargo 2.0. We are tied into the rust project itself which means we have the same compatibility guarantees. This is one reason we generally encourage trying ideas out in third-party plugins before we integrate them in directly since they can break compatibility.
> You can’t even publish a crate that has local dev dependencies
You can; cargo automatically strips them. However, if you tell cargo that there is a version of it in the registry (by setting the version), then it must be published. This is why when I redesigned `cargo add` for being merged into cargo, I made it so `cargo add --path ../foo --dev` will not add the `version` field. We do need to find ways to clarify that the purpose of the version field is for looking it up in the registry.
Allowing the dev dependencies to be stripped also helps with issues of circular dev-dependencies.
> However, many developers break large projects down into smaller modules naturally, and you can’t publish a parent crate that has sub-crates that only exist within itself.
We do have an RFC for this: https://github.com/rust-lang/rfcs/pull/3452
The most complex part is the Index, figuring out how to represent it in the metadata tables we maintain so we avoid having to download every `.crate` file.
I also worry there might be tech debt around assumptions of there being a single version of a package when nested packages will easily break that.
> You can see the problem manifest in the sheer number of utility crates designed to simplify publishing workspaces. Each works with a subset of configurations, and the “one true way” of setting workspaces up still eludes me. When I publish Wick, it’s frequently an hour+ of effort combining manual, repetitive tasks with tools that only partially work.
I'm a bit confused on this point. While there are things to improve around publishing workspaces, I'm not sure how this relates to setting workspaces up or what problems they've had with that. I'd also be curious what problems they had with releasing packages. I don't think I've seen issues from them in cargo-release's Issues.
This is a really overwrought alternative to just breaking up `std` and listing which new libraries one wants in the regular [depenencies] section.
https://github.com/rust-lang/rfcs/pull/1133 Yeah definitely I haven't been wanting this for years...
In Making Rust supply chain attacks harder with CackleThat's positive news, but I'll have to reserve my enthusiasm. I've been burned too many times with what seem like reasonable-looking RFCs that seem to have some initial momentum and then get closed out after a few years with no progress being made (& how that's communicated out & tracked is another complaint).
For example & relevant to this:
https://github.com/rust-lang/rfcs/issues/816 redirected to https://github.com/rust-lang/rfcs/pull/2318
https://github.com/rust-lang/rfcs/pull/2318 says merged but links to tracking issue https://github.com/rust-lang/rust/issues/50297 which was closed out without ever being implemented.
So 5 years with no progress & a restarted effort. Don't get me wrong. I appreciate all the people devoting energy to this & other issues, & it's certainly easy to provide criticism from the sidelines, especially since a
Read the rest
ctually solving the problem I'm sure can be hard & I'm not putting my cycles toward this. All I'm trying to communicate is that I'm personally not going to get my hopes up but I really wish the team luck and hope progress can be made here finally!
The recently-formed testing subteam is looking to solve your exact complaint: https://github.com/rust-lang/rfcs/pull/3455
In Divan: Fast and Simple Benchmarking for RustIt's been a long time since I have touched Ada and I don't really know Rust. But I do know that Ada allows you to specify the range of custom numeric types[1]:
type Page_Num is range 1 .. 2_000;
type Line_Size is range 1 .. Max_Line_Size;
subtype Buffer_Size is Integer range 0 .. Max;
type Byte is mod 256; -- an unsigned byte
type Hash_Index is mod 97; -- modulus is prime
Looking around, I see that the Rustaceans are working on ranged types, as discussed here[2]. They even mention Ada. And there is a PR for a ranged types MVP here[3], which was ultimately closed to do some more thinking.
[1] https://www.adaic.org/resources/add_content/standards/05rm/h...
[2] https://github.com/rust-lang/rfcs/issues/671
[3] https://github.com/rust-lang/rust/pull/107606
In AdaCore Announces Gnat Pro for RustRust has had an interesting and probably pretty unique story, moving from a GC’d language with a runtime + green threads[1] to what it is today.
They are treading a line that is uniquely difficult to tread, and I think it’s mostly working. Async is still a bit of a mess but it seems that’s because it’s inherent to the constraints they had to impose on themselves.
It’s kind of cool that I can use Async stuff in embedded devices[1] and a web app, even if I do get frustrated with mind-numbing Async issues from time to time.
1. https://github.com/rust-lang/rfcs/pull/230
2. https://embassy.dev/
In Removing garbage collection from the Rust language (2013)See for example https://github.com/rust-lang/rust/issues/63818 and https://github.com/rust-lang/rfcs/pull/3467
Basically the problem is that async blocks/fns/generators need to create a struct that holds all the local variables within them at any suspension/await/yield point. But local variables can contain references to other local variables, so there are parts of this struct that reference other parts of this struct. This creates two problems:
- once you create such self-references you can no longer move this struct. But moving a struct is safe, so you need some unsafe code that "promises" you this won't happen. `Pin` is a witness of such promise.
- in the memory model having an `&mut` reference to this struct means that it is the only way to access it. But this is no longer true for self referential structs, since there are other ways
Read the rest
to access its contents, namely the fields corresponding to those local variables that reference other local variables. This is the problem that's still open.
I'll believe it when they actually do something, such as delete the garbage crates from my second link. These "policies" and "discussions" have been going on since 2014. Note that even your link is not an accepted RFC; it's still being reviewed ( https://github.com/rust-lang/rfcs/pull/3463 )
In Rust crate rg typosquatting/redirect to ripgrepShowing the 15 most recent of 44 sources. Enable JavaScript to search and browse every indexed mention.