- 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
I updated to 1.100 during a Claude session and it complained about new warnings, so I told it to fix them. It removed a large number of unused dependencies without issue.
I believe so. The maintaner of cargo-udeps did most of the work as an effort to upstream it.
The main limitation is in dev-dep detection since there isn't a way to exhaustively run everything that uses dev-deps yet. You can look at logging statements to get an approximation though.
For someone who has decades of experience from other programming languages this does not look clear to me at all but rather confusing. Calling an method can change value of variable of primitive type?
Looks like part of the motivation was for things with long names like `some_struct_a.some_field_b.some_subfield_c`, where needing to name the field twice would have pushed people to using `^= true` instead, which is a bit more roundabout to decipher and risks people forgetting the idiom and writing `^= false` by accident. Not necessarily the most useful API, but not unmotivated and harmless to add.
Faster compile and smaller build-dir can be at odds with each other.
That said, this release includes some incremental improvements as well as the unused-dependency lint to help reduce wasted work within the ecosystem.
Some changes that have been or are about to be merged for upcoming releases
- We will be reducing the debug info generated for the `dev` profile which reduces build-dir size and speeds up builds. We've split off a `debug` profile for when that is needed.
- Cargo will be deleting the directory rustc writes before each invocation, avoiding the leaking of debug files when split-debug is enabled (default on Mac)
- rlibs for workspace members will no longer be copied from build-dir to target-dir which takes up extra space on systems without hardlinking or where we skip it (like Mac)
- redundant information in rlibs and rmeta's is going to be de-duplicated
Examples of further out changes
- This release includes the foundational work to add a build-dir GC
Yes this is why I switched to Go for backend, much faster compiling and performance isn't an issue for the application yes using 100GB+ is just bad tooling.
try disabling at least some debug-info for your dependencies.
use cargo's --timings option to identify the slow crates, then use measureme to figure where rustc is spending time.
try fiddling with detached debug-info, dwp files can be smaller than their constituent dwo files.
ensure really small "template wrappers" are inlined.
lower the number of compilation-units you use.
For incremental builds I have found it can _sometimes_ be effective to split out larger dependencies into a dynlib. You create a dylib crate that re-exports said dependencies and your executable depends on that. Ofc things like generics from the offending libraries will still end up in your executables; Though I think there is a way to mitigate this a little.
This mostly helps with link-time, and saving space if you have a bunch of executables (using the argv[0] trick will help more, though).
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.
Best to do some benchmarks for cranelift on your codebases and system. It used to be quite a lot faster, but for me the advantage has disappeared over the last year of Rust improvements.
If your codebase is not some small project, its excruciating slow. Even if you try different linkers, and other compilers, nothing really make incremental compiles eat so much of your system. Even more so if you have multiple AI agents doing security and other checks.
Switched to Go for several months, and the difference was very noticeable. Until you started to get there also 50k+ files that are interlinked. And let us not talk about Go and Rust their issues with insane amount of debug/cache buildup.
Imaging if you have 4 to 6 agents running that, with each seeing the cache grow from 20, 30, 40 ... To the point that a 100/1000GB SSD grows to 800, 900GB usage. Often in barely a day.
Seen my NVME drive its lifespan drop from 98% to 91% in barely a few month time. I dread looking at it again lol
What was the solution? Going back to C ... Despite right now working on a 800k lines project, it compiles way faster the Go, and well, Rust will have pegged all 16 cores for a minute, for EACH agent trying to recompile on a small change.
Memory safety? Instead of checking at compile time, and wasting my time, this has simply been moved to AI agents checking, making tools, checking, at night. So it does not disturb my own work.
Its ironic, how both modern projects, end up being worse off. Best of all, the C project is way faster then the same project in Go and Rust. Yea, it was "fun" having AI transcompile them twice but the difference on actual large codebase, and not some micro benchmarks is not a joke. To the point that now all my projects have gone back to C...
And yea, i expect some fast downvotes by our Rust friends because saying something negative about Rust always gets people downvoted here. No offence but Rust being linked to LLM and the whole checker was a benefit before AI came around. But now you can offload a lot of safety checks to the backend/offhours, instead of paying for it with every compile.
Rust encourages a kind of generic programming that can result in generating too much code.
The compilation model is vastly, vastly, vastly better than languages like C++ and C, though, and it does compile much faster than an equivalent C++ build (doesn't count if you download precompiled binaries of your c++ dependencies)
That still isn't a paradox. Furthermore it still makes sense: a language designed to generate the fastest code has constructs that cannot be compiled quickly, even without optimizations.
There's no paradox here. You can use any benchmark you like to prove that Rust is a fast language. The work that the compiler does is irrespective of the language that rustc is written in.
On macOS there is a known bug where some temp files are always created anew, not reused, which slows down compilation and wastes more space than other platforms.
I don't understand why people complain about this non-stop. If compilation time is such an issue use a different language. I can't say I've been bottlenecked by compilation in a very long time.
Would you say that having 100 releases of the language more of a positive thing or a negative thing?
For comparison, C has had, say, 4 versions, and C++ 7 had versions (depending on how you count). But - Java has had 27 main versions and probably more than a 100 if you count minor versions/updates.
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.)
A generic could be seen as a pure (in the functional sense) program that is run at link time that takes various type information as input and outputs an implementation.
I wonder why not make the ABI contract explicit, instead of do what C do that froze the lang.
Similar to :
#[rust_abi]
struct MustConform
fn must_conform
So the user must write the shims instead of rust magically build it. This also mean that ABI changes become visible, and changes to rust not mean worries about ABI.
Thank you for your work, it's always interesting to read your take.
Forgive the naive question on something that's probably been discussed many times over, but could there be a middle ground when it comes to a stable ABI and generics? Something where the person building the library for dynamic linking chooses which explicit monomorphizations they'd like to provide for each public generic function (and type), and the compiler stamps out all combinations of those concrete instances? Could the way these are named and stamped out be standardized so that this could be treated as a stable ABI for non-generics?
It seems to me that it would at least cover distros: they could make a pass over all their Rust code and determine which monomorphizations are needed throughout the distro.
Yes, in that it's primarily a linux thing as MS has gone the route of saving off basically all dlls for all their OSes for backwards compatibility (though they still backpatch).
No, in that other than Rust and Go (and maybe a few others that emit single binaries, zig?) this is how it works with OS distributed programming language packages. Python, ruby, java, perl, C#, the OS will for all of them control distribute and update the libs independent of the apps that use them.
Also, C/C++ still make up a huge percentage of all apps in pretty much any OS.
> No, in that other than Rust and Go (and maybe a few others that emit single binaries, zig?) this is how it works with OS distributed programming language packages.
Uhmm... No? E.g.:
- Python has long strongly recommended virtual environments.
- Not to talk about JavaScript which of course manage things per project by default.
- I don't remember what was the state of things in .NET Framework, but in modern .NET NuGet packages are distributed as DLLs with your app.
I don't know other ecosystems well but I believe they aren't different.
That's not true. Scripting languages of course need no ABI. Managed languages like C# and Java often keep compatibility of the bytecode. Only AOT languages like Go and Rust cannot.
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.
I don't think a stable ABI has enough advantages to be worth it. C++, IMHO, is a great examples of the downsides of a stable-enough ABI, where stability was never guaranteed, but is now so entrenched that it'll likely never be broken again (limiting the language & the usability in a bunch of ways).
It might make sense to have a subset Swift-style stable ABI, but that's a huge engineering effort, has lots of overhead and is also likely not worth it IMHO.
Mathematically, types are sets of possible values.
Any type (like in TypeScript; Rust doesn't have one) is a set of every possible value; a supertype of all types. Every expression regardless of type can be assigned to a variable of type any.
The opposite is the never type, which is an empty set; no value is of type never. Per set theory, an empty set is a subset of every set, which makes the never type a subtype of all types. An expression of type never can be assigned to every variable regardless of type.
If never type has no values, then how can an expression have never type? Easy: it must never evaluate. Infinite loops, unconditional panics/exceptions, process exit/abort, etc. Also, generics - you can have Vec<!> that's always empty, Result<T,!> that can never be an error, etc.
Why not? I mean if you refer to Rust specifically, yes, because there is no subtyping except for lifetimes, only coercion (and `Any` also cannot contain any type). But in general, why not?
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.
Without looking up the Rust implementation I would hazard a guess that it is loose language to say "something to return when no return is actually possible" because if it is anything like the Bottom Type then there is no something that is being returned which is what this function signature indicates. Generally used for exception handling or intentional infinite loops (in both cases the function does not return from whence it came) … please correct me if I'm wrong here …
Basic use cases like that have always been possible in Rust, either via defining your own enum with zero variants (`enum Foo {}`), or by using a function return type of `!` which was hardcoded to work for certain things, e.g. infinite loops. What this release does is generalizes it so that `!` can participate in types in general, and the coolest part is that pattern matching is aware of this, so for example if you have a `Result<u8, !>` where the error variant is impossible, a `match` over this would allow you to omit the impossible error arm, and furthermore because this enum now effectively only has a single variant, it would allow you to use the pleasant irrefutable destructuring assignment syntax `let Ok(foo) = blah();`.
It has existed as a real type for a very long time (I believe in the beginning it really wasn't a real type but that's a long time ago), you just weren't allowed to name it. There was also an (unsupported) hack that allowed you to use it on stable.
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 of it can actually exist, and that any code that would encounter such a value is unreachable.
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.
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 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.
I get your point but disagree strongly. One topic that's been on my mind a lot is durability. The culture of LLMs is that everything is transitory. Why bother keeping a vibe coded codebase around for more than a few weeks, when the next big model iteration will be able to vibe code it better?
By contrast, free software in general, and Rust very much in particular, has cultural norms that things should last a while, rather than immediately being thrown away. I think that's worth preserving.
You can marshal values, but you can't marshal lifetimes, ownership, (lack of) thread-safety, (lack of) side-effects, etc. The ABI carries far less information than the Rust compiler relies on. Thus, any FFI call is inherently unsafe. It takes you, the programmer, with knowledge the compiler doesn't have and the architecture doesn't provide, to determine whether the code as you use it actually is safe or not.
It is explained elsewhere, but a summary is that any language with generics is going to have any stable abi as a subset of the language. There is already a subset of the language that is a stable abi, it is the c abi. Expanding that subset has to be worth it in terms of what people actually want to export from a library. As I use generics fairly heavily I don't think I would use that expanded abi for anything.
- 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
Long time follower of this. Very grateful it's been implemented.
> 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
The main limitation is in dev-dep detection since there isn't a way to exhaustively run everything that uses dev-deps yet. You can look at logging statements to get an approximation though.
- 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()
But under the hood it's all the same https://doc.rust-lang.org/stable/src/core/bool.rs.html#157-1...
Looks like part of the motivation was for things with long names like `some_struct_a.some_field_b.some_subfield_c`, where needing to name the field twice would have pushed people to using `^= true` instead, which is a bit more roundabout to decipher and risks people forgetting the idiom and writing `^= false` by accident. Not necessarily the most useful API, but not unmotivated and harmless to add.
That said, this release includes some incremental improvements as well as the unused-dependency lint to help reduce wasted work within the ecosystem.
Some changes that have been or are about to be merged for upcoming releases
- We will be reducing the debug info generated for the `dev` profile which reduces build-dir size and speeds up builds. We've split off a `debug` profile for when that is needed.
- Cargo will be deleting the directory rustc writes before each invocation, avoiding the leaking of debug files when split-debug is enabled (default on Mac)
- rlibs for workspace members will no longer be copied from build-dir to target-dir which takes up extra space on systems without hardlinking or where we skip it (like Mac)
- redundant information in rlibs and rmeta's is going to be de-duplicated
Examples of further out changes
- This release includes the foundational work to add a build-dir GC
- Cross-workspace de-duplicating of build-dirs
- Cross-workspace build-dir cache
- Early cut off
“Relink, don't rebuild” #790
https://github.com/rust-lang/compiler-team/issues/790
And the large target directories is also being worked on as well.
use cargo's --timings option to identify the slow crates, then use measureme to figure where rustc is spending time.
try fiddling with detached debug-info, dwp files can be smaller than their constituent dwo files.
ensure really small "template wrappers" are inlined.
lower the number of compilation-units you use.
For incremental builds I have found it can _sometimes_ be effective to split out larger dependencies into a dynlib. You create a dylib crate that re-exports said dependencies and your executable depends on that. Ofc things like generics from the offending libraries will still end up in your executables; Though I think there is a way to mitigate this a little.
This mostly helps with link-time, and saving space if you have a bunch of executables (using the argv[0] trick will help more, though).
They’re also doing work to reduce the amount of disk space usage (by clearing out unused articacts) and make it easier to maintain.
If your codebase is not some small project, its excruciating slow. Even if you try different linkers, and other compilers, nothing really make incremental compiles eat so much of your system. Even more so if you have multiple AI agents doing security and other checks.
Switched to Go for several months, and the difference was very noticeable. Until you started to get there also 50k+ files that are interlinked. And let us not talk about Go and Rust their issues with insane amount of debug/cache buildup.
Imaging if you have 4 to 6 agents running that, with each seeing the cache grow from 20, 30, 40 ... To the point that a 100/1000GB SSD grows to 800, 900GB usage. Often in barely a day.
Seen my NVME drive its lifespan drop from 98% to 91% in barely a few month time. I dread looking at it again lol
What was the solution? Going back to C ... Despite right now working on a 800k lines project, it compiles way faster the Go, and well, Rust will have pegged all 16 cores for a minute, for EACH agent trying to recompile on a small change.
Memory safety? Instead of checking at compile time, and wasting my time, this has simply been moved to AI agents checking, making tools, checking, at night. So it does not disturb my own work.
Its ironic, how both modern projects, end up being worse off. Best of all, the C project is way faster then the same project in Go and Rust. Yea, it was "fun" having AI transcompile them twice but the difference on actual large codebase, and not some micro benchmarks is not a joke. To the point that now all my projects have gone back to C...
And yea, i expect some fast downvotes by our Rust friends because saying something negative about Rust always gets people downvoted here. No offence but Rust being linked to LLM and the whole checker was a benefit before AI came around. But now you can offload a lot of safety checks to the backend/offhours, instead of paying for it with every compile.
The compilation model is vastly, vastly, vastly better than languages like C++ and C, though, and it does compile much faster than an equivalent C++ build (doesn't count if you download precompiled binaries of your c++ dependencies)
Is Python a fast language because it barely takes any time to compile the code? No obviously not.
This is important, because most often during development you want fast compilation times more than you want fast code.
But some of it is implementation problems.
But that said I do agree it is pretty fast these days. Significantly faster than C++ and people have tolerated that for decades.
For comparison, C has had, say, 4 versions, and C++ 7 had versions (depending on how you count). But - Java has had 27 main versions and probably more than a 100 if you count minor versions/updates.
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.)
Similar to :
So the user must write the shims instead of rust magically build it. This also mean that ABI changes become visible, and changes to rust not mean worries about ABI.Forgive the naive question on something that's probably been discussed many times over, but could there be a middle ground when it comes to a stable ABI and generics? Something where the person building the library for dynamic linking chooses which explicit monomorphizations they'd like to provide for each public generic function (and type), and the compiler stamps out all combinations of those concrete instances? Could the way these are named and stamped out be standardized so that this could be treated as a stable ABI for non-generics?
It seems to me that it would at least cover distros: they could make a pass over all their Rust code and determine which monomorphizations are needed throughout the distro.
https://github.com/joshtriplett/rfcs/blob/crabi-v1/text/3470...
An actual stable native Rust ABI sounds like a forward compatibility nightmare.
If there's a CVE in tokio, the OS could theoretically publish a patched version of tokio and all apps that depend on that end up using the fixed code.
As it stands now, the OS needs to publish updated versions of all rust apps that depend on tokio.
Yes, in that it's primarily a linux thing as MS has gone the route of saving off basically all dlls for all their OSes for backwards compatibility (though they still backpatch).
No, in that other than Rust and Go (and maybe a few others that emit single binaries, zig?) this is how it works with OS distributed programming language packages. Python, ruby, java, perl, C#, the OS will for all of them control distribute and update the libs independent of the apps that use them.
Also, C/C++ still make up a huge percentage of all apps in pretty much any OS.
Uhmm... No? E.g.:
- Python has long strongly recommended virtual environments.
- Not to talk about JavaScript which of course manage things per project by default.
- I don't remember what was the state of things in .NET Framework, but in modern .NET NuGet packages are distributed as DLLs with your app.
I don't know other ecosystems well but I believe they aren't different.
Stable ABI dramatically improves the problem space there (without necessarily having anything to do with business model).
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.
It might make sense to have a subset Swift-style stable ABI, but that's a huge engineering effort, has lots of overhead and is also likely not worth it IMHO.
Why is that? It seems like that makes min-publish-age much less effective.
Any type (like in TypeScript; Rust doesn't have one) is a set of every possible value; a supertype of all types. Every expression regardless of type can be assigned to a variable of type any.
The opposite is the never type, which is an empty set; no value is of type never. Per set theory, an empty set is a subset of every set, which makes the never type a subtype of all types. An expression of type never can be assigned to every variable regardless of type.
If never type has no values, then how can an expression have never type? Easy: it must never evaluate. Infinite loops, unconditional panics/exceptions, process exit/abort, etc. Also, generics - you can have Vec<!> that's always empty, Result<T,!> that can never be an error, etc.
https://blog.rust-lang.org/2026/11/12/Rust-1.100.0/#never-ty...
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.
Two jokes that are expiring this month
[1]: https://www.youtube.com/watch?v=RFm9ClqlGuo
As this release seems to include breaking changes, shouldn't the major version number have been bumped, as per semver?
Has the Rust book(s) been updated to include the new APIs?
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.)
Is that the raven that says Ni?
https://www.youtube.com/watch?v=bLiXjaPqSyY
By contrast, free software in general, and Rust very much in particular, has cultural norms that things should last a while, rather than immediately being thrown away. I think that's worth preserving.