A few other langs have it too. It's just something to return when no return is actually possible. And then it can propagate, so it makes some nice things possible that weren't before.
It's the type called "!", or the return value of diverging control flow, such as infinite loops, returns or function calls that panic or abort. It's an uninhabited type, meaning no values can actually exist, and that any code that would encounter such a value is unreachable.
This site doesn't even fully support Markdown or Unicode and people think for some reason that Twitter-style username tagging will actually work. U+1F923
- Introduced minimum publish age configurations, also known as dependency cooldowns. When the relevant config is set, the resolver ignores versions published more recently than that, unless they are already in Cargo.lock. (RFC 3923) docs #17335
- cargo-install: now uses the existing lockfile in the .crate tarball by default. --locked in cargo install becomes a no-op. #17388
Any faster vs what baseline? They’ve constantly made improvements and Rust today is pretty darn quick, especially for incremental. There’s work to parallelize the front end which will help a little bit and you can always use the cranelift backend for debugging which is substantially faster than LLVM.
They’re also doing work to reduce the amount of disk space usage (by clearing out unused articacts) and make it easier to maintain.
The primary challenge in having a stable ABI is that we have generics. So, even if we never changed the calling conventions, an ABI is not as simple as exporting a symbol with the right name. We implement generics by providing MIR (our main intermediate representation) that gets compiled by the linking program for each instantiation of a generic.
Swift handles this through the equivalent of Rust's `dyn`. We could have a stable ABI that's based entirely on `dyn`. Such an ABI would have some limitations, since there are traits `dyn` can't represent (anything that's generic over something other than the type that implements the trait, which is quite common), though we're working on some of those.
Essentially, you wouldn't be able to have a `Vec<T>` in your ABI without either pinning down T or using something like `Vec<Box<dyn Trait>>`. Which is possible, but kind of awful.
We're still planning to ship a stable ABI at some point, but that gives a flavor for some of the kinds of problems we'd need to solve in order for that stable ABI to be useful.
(C++ typically handles generics by having types defined in header files, and those get compiled with the program consuming the library, which is effectively the same situation Rust is in. You could export symbols from a shared library for specific instantiation of a template, but people rarely do that.)
Well yes, but then your interface is a C ABI. That's fantastic if the side using my library is any language where C is the only common ground. When the application side is Rust though, it leaves a lot to be desired. It would be delicious to actually interface in a way that respects Rust!
Hell, even if all exposed functions and types would need to be fully monomorphized at the interface, it would be a lot nicer to pass a `&'a [i64]` rather than a `const * int64_t` together with a `size_t n` and have to marshall the slice on both sides.
Another year or three of insane memory and disk prices and people will come around.
A stable Rust ABI would be nice for not just Rust, especially if they refine or extend (formally or de facto) the SysV ABI to optimize passing and returning of discriminants. That could then smooth the way for developing these features in C and C++, such as a primitive error-result type that saw some brief attention in both C and C++ WGs a couple of years ago. Doing it properly--absolute minimum cost, ABI stable, and cross-language--seemed to require too much orchestration across the ecosystem so enthusiasm and ambition seemed to peter out. The work required for a stable Rust ABI could provide the inertia to get that done.
Rust will almost certainly never have a stable ABI by default, and libraries will continue to be compiled from source by default. It might one day have an opt-in stable ABI.
when can we expect `Result::into_ok` and `Result::into_err` to land? the blog post includes the `infallible_unwrap` demo which is the exact functionality these two functions implement. i wonder why they didn't release these at the same time as never?
(As for why they weren't stabilized at the same time: because it's not worth adding more baggage to a major, difficult stabilization process; as that would just be more surface area that has to be reviewed and another source of potential issues or delays. Instead, the stabilization process for infallible_unwrap was started immediately after `!` was stabilized. That process includes a 2-week final comment period for community feedback which is why they landed in different releases.)
I just spent last few days fixing arena leaks (Bumpalo doesn't call drop) and had to use allocator-api2 for Vec::new_in which is now available in stable Rust.
I haven’t seen any blog on the topic but I fully believe in the age of coding agents and LLM backward compatibility is a bit less important than it has been in the past and should be relaxed in some cases to allow language to move faster.
The blog post summarized the most important changes.
> warning: unused dependency `tracing-subscriber` --> Cargo.toml:23:1 | 23 | tracing-subscriber.workspace = true | ^^^^^^^^^^^^^^^^^^ | = note: `cargo::unused_dependencies` is set to `warn` by default help: consider removing the dependency on `tracing-subscriber`
Heck yes
https://blog.rust-lang.org/2026/11/12/Rust-1.100.0/#never-ty...
- Stabilize never type
- Stabilize custom allocators
- Introduced minimum publish age configurations, also known as dependency cooldowns. When the relevant config is set, the resolver ignores versions published more recently than that, unless they are already in Cargo.lock. (RFC 3923) docs #17335
- cargo-install: now uses the existing lockfile in the .crate tarball by default. --locked in cargo install becomes a no-op. #17388
- bool::toggle() https://doc.rust-lang.org/stable/std/primitive.bool.html#met...
- Box::map() https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#m...
- str::trim_prefix(), str::trim_suffix, Path::trim_prefix()
And the large target directories is also being worked on as well.
They’re also doing work to reduce the amount of disk space usage (by clearing out unused articacts) and make it easier to maintain.
Swift handles this through the equivalent of Rust's `dyn`. We could have a stable ABI that's based entirely on `dyn`. Such an ABI would have some limitations, since there are traits `dyn` can't represent (anything that's generic over something other than the type that implements the trait, which is quite common), though we're working on some of those.
Essentially, you wouldn't be able to have a `Vec<T>` in your ABI without either pinning down T or using something like `Vec<Box<dyn Trait>>`. Which is possible, but kind of awful.
We're still planning to ship a stable ABI at some point, but that gives a flavor for some of the kinds of problems we'd need to solve in order for that stable ABI to be useful.
(C++ typically handles generics by having types defined in header files, and those get compiled with the program consuming the library, which is effectively the same situation Rust is in. You could export symbols from a shared library for specific instantiation of a template, but people rarely do that.)
https://github.com/joshtriplett/rfcs/blob/crabi-v1/text/3470...
An actual stable native Rust ABI sounds like a forward compatibility nightmare.
Hell, even if all exposed functions and types would need to be fully monomorphized at the interface, it would be a lot nicer to pass a `&'a [i64]` rather than a `const * int64_t` together with a `size_t n` and have to marshall the slice on both sides.
A stable Rust ABI would be nice for not just Rust, especially if they refine or extend (formally or de facto) the SysV ABI to optimize passing and returning of discriminants. That could then smooth the way for developing these features in C and C++, such as a primitive error-result type that saw some brief attention in both C and C++ WGs a couple of years ago. Doing it properly--absolute minimum cost, ABI stable, and cross-language--seemed to require too much orchestration across the ecosystem so enthusiasm and ambition seemed to peter out. The work required for a stable Rust ABI could provide the inertia to get that done.
when can we expect `Result::into_ok` and `Result::into_err` to land? the blog post includes the `infallible_unwrap` demo which is the exact functionality these two functions implement. i wonder why they didn't release these at the same time as never?
(As for why they weren't stabilized at the same time: because it's not worth adding more baggage to a major, difficult stabilization process; as that would just be more surface area that has to be reviewed and another source of potential issues or delays. Instead, the stabilization process for infallible_unwrap was started immediately after `!` was stabilized. That process includes a 2-week final comment period for community feedback which is why they landed in different releases.)
Two jokes that are expiring this month
[1]: https://www.youtube.com/watch?v=RFm9ClqlGuo
I just spent last few days fixing arena leaks (Bumpalo doesn't call drop) and had to use allocator-api2 for Vec::new_in which is now available in stable Rust.
https://github.com/bancek/rust-sass/pull/1
Wait for the timing of the next release. It will be a Christmas present.