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
rust
Rust2012–2026
rust-lang / rust
rust
Empowering everyone to build reliable and efficient software.
818Distinct people
1,825Mentions
8Explicit recommenders
121.9KGitHub stars
What to know before exploring
What it is
Empowering everyone to build reliable and efficient software.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
10 years ago, I commented on the Rust issue for "Incremental recompilation", where it was suggested that Rust could at least adopt Haskell GHC's model of incrementality, which…
nh2 used a recommendation phrase. 11 indexed comments match. This is a phrase match, not a verdict.
Informational Commenters provide technical explanations for Rust's release cadence and design choices, such as the separation of stabilization processes and syntax tradeoffs. The discussion highlights consistent development practices and detailed reasoning behind language features.
What changed this week. Read the supporting reply
Also in these discussions
- rust-lang/rfcs · linked in 55 of the same discussions
- golang/go · linked in 8 of the same discussions
- rust-lang/cargo · linked in 8 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Informational
Commenters provide technical explanations for Rust's release cadence and design choices, such as the separation of stabilization processes and syntax tradeoffs. The discussion highlights consistent development practices and detailed reasoning behind language features.
Supporting reply 1 · Supporting reply 2 · 4 discussions summarized
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:56:55 PM UTC.
The discussion centers on Rust 1.100.0, highlighting major stabilizations like the never type and custom allocators while noting that some APIs were omitted from the initial summary. A significant portion of the thread debates the feasibility and necessity of a stable ABI, with technical explanations contrasting against user desires for precompiled libraries.
47 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4Read the discussion on HN. A full-thread summary is not available yet.
Showing the three threads with the most distinct people linking this repo, from 51 threads this week.
Mentions over time
HN mentions by year1,825 dated mentions
Observed mentions: 2012-01-20 23:03:27 UTC to 2026-10-22 06:16:46 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 |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 42 | 6 | 36 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 82 | 6 | 76 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 138 | 6 | 132 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 114 | 9 | 105 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 122 | 5 | 117 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 119 | 12 | 107 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 88 | 1 | 87 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 115 | 11 | 104 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 166 | 20 | 146 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 149 | 12 | 137 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 151 | 25 | 126 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 167 | 12 | 155 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 132 | 11 | 121 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 158 | 8 | 150 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 82 | 14 | 68 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Website | Getting started | Learn | Documentation | Contributing
This is the main source code repository for Rust. It contains the compiler,
standard library, and documentation.
Why Rust?
Performance: Fast and memory-efficient, suitable for critical services, embedded devices, and easily integrated with other languages.
Reliability: Our rich type system and ownership model ensure memory and thread safety, reducing bugs at compile-time.
Productivity: Comprehensive documentation, a compiler committed to providing great diagnostics, and advanced tooling including package manager and build tool (Cargo), auto-formatter (rustfmt), linter (Clippy) and editor support (rust-analyzer).
Quick Start
Read "Installation" from The Book.
Installing from Source
If you really want to install from source (though this is not recommended), see
INSTALL.md.
Getting Help
See https://www.rust-lang.org/community for a list of chat platforms and forums.
Contributing
See CONTRIBUTING.md.
For a detailed explanation of the compiler's architecture and how to begin contributing, see the rustc-dev-guide.
License
Rust is primarily distributed under the terms of both the MIT license and the
Apache License (Version 2.0), with portions covered by various BSD-like
licenses.
See LICENSE-APACHE, LICENSE-MIT, and
COPYRIGHT for details.
Trademark
The Rust Foundation owns and protects the Rust and Cargo
trademarks and logos (the "Rust Trademarks").
If you want to use these names or brands, please read the
Rust language trademark policy.
Third-party logos may be subject to third-party copyrights and trademarks. See
Licenses for details.
Read the full README on GitHubWhat Hacker News says
115 sourcesSmall note, we don't use the C++ mangler (https://github.com/rust-lang/rfcs/pull/2603), and did the upstream work in GDB to get it to understand things. (There's also more work to do: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais... )
That being said, yes, we see integration into the parent platform as being an important design constraint for Rust. I think Go made reasonable choices for what they're trying to do, though. It's all tradeoffs.
In Why are my Go executable files so large?The point of the article is that there's glue code needed for this, I think.
It seems like Rust also needs this, either through linker magic or extern C:
https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=er...
In The Unix C library API can only be reliably used from CI was about to post with the same question about Rust. It looks like there's no issue with using anything other than the "Rust" or "Cargo" names and the logo, as per this:
> You are correct that we intended the trademark to apply when
> distributing a package or other binary called "Rust" -- and in
> particular that if modifications are made, then we would expect a
> trademark request outlining the sorts of changes being made (as the
> policy notes though, we are inclined to accept such a request).
> regards,
> Niko
https://github.com/rust-lang/rust/issues/53287
This thread in the project's (hyperbola) issue tracker seems silly and needlessly exclusive, given what seems to be a relatively minor restriction: https://issues.hyperbola.info/index.php?do=details&task_id=7...
In HyperbolaBSD Roadmap: hard fork of the OpenBSD kernel and userspaceThis proposal has been made in the tracking issue already, yet it hasn't been picked up on yet: https://github.com/rust-lang/rust/issues/44109#issuecomment-...
In Rust 1.40For enums at least, I'm not recommending it's use (yet), as with _Nonexhaustive you can make sure you caught all cases internally. Matching on _Nonexhaustive as a user of the library is of course a bad idea. There've been proposals to a lint like
#[deny(reachable)] to make such checks possible for #[non_exhaustive] as well but it seems that nothing has happened yet: https://github.com/rust-lang/rust/issues/44109#issuecomment-...
In Rust 1.40> Somewhat interestingly, it detects it and SIGABRTs, which technically isn't a segfault. And that's now some black magic that I'm curious about as I really thought it would have segfaulted.
It's a signal handler, of course: https://github.com/rust-lang/rust/blob/d8bdb3fdcbd88eb16e1a6...
In Make CPython segfault in 5 lines of codeAlso, due to this bug, adding a single printf line causes everything after it in the file to be recompiled without there being a need: https://github.com/rust-lang/rust/issues/47389
In Speeding Up the Rust Compiler> Essentially, compile only what has changed, re-use compiled forms of everything that hasn't.
That's what incremental compiling does, and it has been enabled for a while. Unfortunately, it doesn't help on fresh builds.
> Essentially, pre-compiled dependencies will be sourced and plugged in to a Rust project.
There are two aspects here. The more recent one, which you are thinking of, is building and shipping procedural macros as WASM binaries. Procedural macros are very powerful, but they take a token stream as input to allow for future changes to the language. Because of this, basically every macro uses a Rust parser crate called syn. Since it's a fully-fledged parser, syn takes a while to compile (30 seconds or so, certainly not minutes), which many people find annoying, and it gets worse if you end up using different versions of syn fo
Read the rest
r different proc macro crates. The plan here is to build the proc macros (including syn) somewhere on the Rust infrastructure and ship the binaries to the users. The sandboxing story is somewhat complicated: proc macros and build scripts can legitimately read or download files, or produce non-deterministic output in other ways. A WASM macro would not be able to do this, so the whole thing would be opt-in. It also provides no benefit for crates that don't use procedural macros. See https://github.com/dtolnay/watt for more details.
The other possible avenue is MIR-only rlibs. When you compile a dependency, you get machine code (with the exception of generic code). It might be possible to compile crates to MIR (again, on the Rust infrastructure) and only do the final codegen on the user's computer. But that's still complex, and not necessarily much faster. See https://github.com/rust-lang/rust/issues/38913.
Worth noting that support for custom allocators in standard collections is not finalized yet: https://github.com/rust-lang/rust/issues/32838
The (awesome) bumpalo crate that you link to gets around this by providing ported implementations of Vec and String, but if you need e.g. a custom-allocated HashMap, you need to implement it yourself.
In Game Boy Advance “Hello World” Using ZigI agree. That, and no need to rush new features, stabilize old ones and fix their bugs. I am still waiting for RFC0066[1] to be fixed. It is from 2014-05-04! Here is its GitHub Issue: https://github.com/rust-lang/rust/issues/15023. Backstory: I started writing a relatively simple Rust program many years ago when I ran into this issue. It was my first attempt at writing Rust, and I did not like the workaround.
[1] https://github.com/rust-lang/rfcs/blob/master/text/0066-bett...
In GCC-Rust: Rust frontend for GCC> has a not broken implementation of restrict (which should be useful for Rust)
The most recent restrict bug the rustc developers found (which made they disable restrict again) was found in both LLVM and GCC (they made a C reproducer, so they could test in both). See: https://github.com/rust-lang/rust/issues/54878 (rustc) https://bugs.llvm.org/show_bug.cgi?id=39282 (LLVM) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87609 (GCC).
In GCC-Rust: Rust frontend for GCCActually in Rust you have a problem where you can't express partial access to a struct at a function level. This means that you can't put some code into a separate function right now, making use of closures/iterators harder. There are attempts to fix this ([1] [2]). If borrow checking is done on collections of objects instead, the problem can be tackled more easily I think.
[1]: https://github.com/rust-lang/rust/issues/53488
[2]: http://smallcultfollowing.com/babysteps/blog/2018/04/16/rust...
In Microsoft is creating a new Rust-based programming language for secure codingI would say that SPJ was quite right, though. Compare and contrast with Haskell. In Haskell, there are broadly only three cases of unsoundness:
* Infinite loops
* `undefined`
* Abuse of unsafe IO behavior, including monads built on or reducible to IO
Rust's unsoundness bugs are all over [0], and come from so many different angles that they feel indistinct from any other low-level C-like language.
I looked a little into RustBelt; how would it have helped this `Pin` issue? I browsed [1] a bit and it seems like `Pin` would have to have been proven on its own in an ad-hoc way not covered by RustBelt.
[0] https://github.com/rust-lang/rust/labels/I-unsound%20%F0%9F%...
[1] https://gitlab.mpi-sws.org/iris/lambda-rust/tree/popl18
In Unsoundness in PinFor the uninitiated: Rust differentiates between safe and unsafe code (safe being the default and unsafe needing the unsafe keyword). The unsafe code is like C/C++: it's more powerful than safe code, allowing you to do more things, including allowing you to trigger undefined behavour. Any mistake can possibly mean UB with all the consequences of crashes, wrong behaviour and nasal demons. Safe Rust on the other hand, is not supposed to be allowed to trigger such UB, no matter what you write. If you are able to trigger UB in 100% safe code, it's considered a bug in the language, an unsoundness bug.
Note that it was known that Pin/Generators had soundness problems when you turned on noalias optimization flags [1]. They have however decided to stabilize it without fixing those problems as they could be fixed afterwards as well. I'm not entire
Read the rest
ly sure yet about the impact of this one, will have to read the thread I guess.
[1]: https://github.com/rust-lang/rust/issues/62149#issuecomment-...
LLVM is (at least currently) being dynamically linked to allow shipping multiple copies of LLVM (one for emscripten, one for everything else) without having to ship multiple entire compilers. Now that emscripten uses LLVM's built in wasm backend it's not needed any more, but currently support is still in the compiler. This is a PR to remove it: https://github.com/rust-lang/rust/pull/65703
In Real hardware breakthroughs, and focusing on rustcShowing the 15 most recent of 115 sources. Enable JavaScript to search and browse every indexed mention.