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, 8:59:20 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
64 sourcesThat RFC was accepted and merged quite a while ago!
https://github.com/rust-lang/rfcs/pull/2504
In Rust 2019 and beyond: limits to some growthThis post reminds me of a problem I've hit with my Objective-Rust project[1] (Rust code that's interoperable with Objective-C), to which I haven't found a good solution.
The closest analog to Objective-C's @protocols in Rust are traits. I would love to be able to transliterate the following Objective-C:
@protocol SomeProtocol
// methods
@end
void demo() {
// Just a demo of how to use SomeProtocol with a var:
id<SomeProtocol> variable = nil;
}
To the following Rust:
#[objrs(protocol)]
trait SomeProtocol {
// methods
}
fn demo() {
// Just a demo of how to use SomeProtocol with a var:
let variable: *mut Id<SomeProtocol> = 0 as *mut _;
}
// The following is provided by objrs:
struct Id<T: ?Sized>(core::marker::PhantomData<T>, Opaque);
extern "C" {
type Opaque;
}
Unfortunately, RFC 255[2
Read the rest
] breaks this. This fails because SomeProtocol is not object safe. Trait objects in Rust can be pretty frustrating in Rust, as this post illustrates.
I've had to workaround this in objrs by doing something like the following:
#[objrs(protocol)]
trait SomeProtocol {
// methods
}
// The macro above generates stuff kinda like this:
struct SomeProtocolId;
impl SomeProtocol for SomeProtocolId {}
impl<T: ?Sized + SomeProtocol> SomeProtocol for Id<T> {}
fn demo() {
// Now you have to know when to use SomeProtocol vs SomeProtocolId:
let variable: *mut Id<SomeProtocolId> = 0 as *mut _;
}
I'm going to see if there are some places where this blog post might simplify some things in my code... it's got some interesting ideas.
[1]: https://gitlab.com/objrs/objrs
[2]: https://github.com/rust-lang/rfcs/blob/master/text/0255-obje...
To save others searching; The mentioned NLL is: https://github.com/rust-lang/rfcs/blob/master/text/2094-nll....
“non-lexical lifetimes”
In Bootstrapping RustThis is a great idea (ignore the naysayers). It's been discussed before here and in the link 2 comments later: https://github.com/rust-lang/rfcs/issues/600#issuecomment-40...
In How I Wrote a Modern C++ Library in Rust> once async/await lands, I think I'll be much happier
The current futures proposal is on track for stabilization[1]. You can use futures with async/await today in nightly, and what you use will probably be exactly what lands in stable soon.
The biggest missing piece is documentation, but thats starting to improve. My go-to for examples is the futures test suite[2]. And if you want more features, futures-preview 0.3alpha adds a bunch of useful future combinators[3]. futures-preview now just wraps nightly's std::future, which is very nice.
Except for the missing documentation, rust's futures are looking great. You can have a play today if you feel keen to jump in. But, as you said it will take some time for the web development ecosystem to mature around the futures API.
[1] https://github.com/rust-lang/rfcs/pull/2592
[2] https://github.com
Read the rest
?[1] is indeed based on traits and try! is a macro that depends on the trait system (line 303: $crate::convert::From::from(err)) to do the very important job of propagation and coercion, by means of error-wrapping. If all it could do was pass the error forward, it'd be quite annoying to deal with. Specifically that since rust represents errors with enums, and you have to handle every error, the eventual caller function would end up dealing with 10 different possible errors, defined in 10 different libraries, and has to be made aware of all downstream dependencies. Or you'd end up avoiding the operator altogether, and force the coercion in every instance, defeating the point of the operator.
The ?/try! utilizes traits to instead allows you to auto-coerce them to a new error with a relevant message/trace (given the appropriate Into definiti
Read the rest
on), allowing it to be a simple one-character addition with most of the expressive power of exceptions.
The heavy lifting is specifically that coercion; the "continue or return" part isn't that significant (that would just be avoiding the any language one-liner: if err return err)
[1] https://github.com/rust-lang/rfcs/blob/master/text/0243-trai...
I'm surprised there's no reference to rust epochs [0]. Sure, they haven't seen use in the wild to learn lessons from in that regard, but they're a very well thought out solution to an effectively identical problem.
They both ended up with very similar results (define a version in cargo.toml/go.mod, use that version of the language to build), but there's also more to it than that, and the rust proposal could help guide discussion of other possible issues too.
[0]: https://github.com/rust-lang/rfcs/pull/2052
In Proposal: Go 2 transitionNo, it's not about panicking. It's undefined behavior to run code compiled with CPU features that aren't supported by the current CPU. See: https://github.com/rust-lang/rfcs/blob/master/text/2045-targ...
There are some other ideas for making it easier to reason about safety at this level: https://github.com/rust-lang/rfcs/pull/2212
Can you point to where you heard about unsupported SIMD causing a panic? I'd like to fix that because it's really wrong!
In Towards fearless SIMDThe author takes a very pragmatic, rather than theoretic, approach to defining "functional programming." And it's the one I subscribe to: if we get more reliable software by calling programming patterns that provide many of the benefits of functional programming "functional programming," it is perhaps a moral obligation to loosen the definition.
All that said, the main way in which Rust falls short is tail call optimization for recursive algorithms. Sadly, it's not likely to happen any time soon due to real technical challenges: https://github.com/rust-lang/rfcs/pull/1888#issuecomment-360... ... and also the fact that WebAssembly does not support tail calls either: https://github.com/WebAssembly/tail-call/blob/master/proposa...
In Is Rust functional?> outright denial of any attempt at TCO because "Guido doesn't like recursion".
No, don’t ignore problems of TCO by saying “guys don’t like functional programimg”. Guido cleary states why he doesn’t like it: [1]. Even though TCO is one of the ES6 standard, TCO also is largely denied by JS implementors (Firefox, Chrome, and Edge devs) because of the similar reasons. As a result, Safari is the only browser that supports TCO. [2][3] And Rust team is not eager to introduce TCO [4].
[1]: http://neopythonic.blogspot.com/2009/04/tail-recursion-elimi...
[2]: https://www.chromestatus.com/feature/5516876633341952
[3]: https://github.com/kangax/compat-table/issues/819
[4]: https://github.com/rust-lang/rfcs/pull/1888
In Stop writing lambda expressions in PythonHopefully!
The RFC I'm referring to[1] is the first step; this isn't my area of specialty, so I can't say if it alone is enough to replicate it. But if not, it's the first step towards it.
The end goal is first-class support to allow people to build excellent libraries like Eigen.
1: https://github.com/rust-lang/rfcs/blob/master/text/2000-cons...
In C++ Lifetime profile v1.0 postedRust: rename 'unsafe' to 'trusted.' (2014)
3 points · Open discussionI was just about to link to something like this[0] before I read your last sentence.
[0]: https://github.com/rust-lang/rfcs/pull/911
In Becoming a Better Software Developer: A Handbook on Personal PerformanceRust RFC to remove M:N threading (2014)
3 points · Open discussionRust has alignment annotations.
https://github.com/rust-lang/rfcs/blob/master/text/1358-repr...
In David Patterson Says It’s Time for New Computer Architectures and LanguagesShowing the 15 most recent of 64 sources. Enable JavaScript to search and browse every indexed mention.