Hacker News

> 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.

Dependency cooldowns receiving such a whiplash this year. Earlier everyone was advocating for them because of the supply chain attacks. Now, people are worried because you might miss 0 days if you use them.

Nonetheless, the ability to set and configure it is a welcome feature.

Does this remove the need for machete or shear?

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.

Wow even slices support trim_prefix and trim_suffix

I'm at a loss with the bool toggle method. Why would x = !x not be good enough?

They are mentioned in the blog post, under "Stabilized APIs".

Types and zero cost avstractions.

Plaudits to all involved, as the sermon goes.

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

- Cross-workspace de-duplicating of build-dirs

- Cross-workspace build-dir cache

- Early cut off

Compiler speed is continually being worked on https://nnethercote.github.io/2026/11/04/how-to-speed-up-the...

And the large target directories is also being worked on as well.

Yes, lots of optimization work has it made faster despite gaining new features.

https://perf.rust-lang.org/dashboard.html

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.

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.

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.

There's really a paradox here. Rust claims to be a fast language, but compiling, even without optimizations on, takes ages ...

You might be interested in this: https://news.ycombinator.com/item?id=50458849 - I didn't try it yet, though.

All the big AI companies use Rust so this is probably something they should focus on improving.

What the hell are you doing to produce 90gb of temp files? Is that normal on rust land?

Is the compiler any faster now?

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.

Well, the AI that slops out Rust code won't mind having to wait!

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.

A defer that you can explicitly skip (via `dismiss()`) - I like it, that'd clean up a fair bit of "do this for safety unless successful" Go code that I've encountered. I've built similar things before, sometimes it helps a lot, and often that's in especially gnarly code which generally benefits from any clarity improvement.

Minus Go's defer being function-scoped, of course.

(and what sibling comment mentioned)

Yeah, it's live now so the URL should be changed to: https://blog.rust-lang.org/2026/11/12/Rust-1.100.0/

The official blog post release is now up at https://blog.rust-lang.org/2026/11/12/Rust-1.100.0/

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.)

We have it: unsafe extern "C" { }.

An actual stable native Rust ABI sounds like a forward compatibility nightmare.

Follow or contribute to efforts on a minimal crABI:

https://github.com/joshtriplett/rfcs/blob/crabi-v1/text/3470...

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.

stable ABI sounds great, but anything/everything that reduces build times is what I really want

Why the yearning for prebuilt Rust libraries? Seems like a nightmare which does not need to happen.

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.

The explanation in OP seems pretty solid.

https://blog.rust-lang.org/2026/11/12/Rust-1.100.0/#never-ty...

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 of what you get back from a `panic!` (a value you never actually get back).

If you have a variable x: ! in scope, your code can never be reached.

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.

noreturn, basically

This comes from usability and consistency.

When we added the MSRV aware resolver, we decided to have it not affect `cargo install` because you could get an old version and not notice (especially with how noisy cargo is) when the right answer might be to upgrade.

Somewhat similar for min-publish-age but also we had defined the parent table for these config fields to not affect install.

The change to `--locked` made us feel a little better with this non-ideal circumstance.

The fact that install now uses the lockfile by default, mitigates this, I think.

"Awesome timing."

Wait for the timing of the next release. It will be a Christmas present.

also humans contributing! Very cool!

Looks like it's still being worked on: https://github.com/rust-lang/rfcs/pull/3407

At least from a quick skim of the comments it seems there's still some stuff that needs to be worked on on the LLVM side of things as well.

Edit: This blog (https://trifectatech.org/blog/tail-calls-project-goal/) has a bit more info on current plans for stable tail call support

Those were stabilized in https://github.com/rust-lang/rust/pull/161712, which just barely missed the cutoff date for 1.100 and is on the 1.101 release train.

(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.)

And the running joke that the type is named after its stabilization date can finally be put to rest. :)

One might call this the moment when nothing never occurs [1].

[1]: https://www.youtube.com/watch?v=RFm9ClqlGuo

Rust's three stability caveats are as follows:

"We reserve the right to fix compiler bugs, patch safety holes, and change type inference in ways that may occasionally require new type annotations."

https://blog.rust-lang.org/2014/10/30/Stability/#what-are-th...

The breakage in question here falls under changes to type inference, which are allowed within reason when they're relatively minor, when steps have been taken to mitigate any breakage in the broader ecosystem, and when the compiler has emitted warnings regarding the imminent change during a grace period, all of which have been done here.

They are completely different release processes, for different things. C and C++ are language specifications and Rust is a tool chain. Even comparing against another compiler tool chain like gcc it wouldn't be a 1 to 1 comparison. Rust having 100 minor releases is only a factor of the passage of time.

Last time I checked between a quarter and a third had a patch release, and those are closer to a signal of "a minor release had a problem". When analysing those my conclusion and the time was "for the most part they were needed because some niche feature or platform had a regression that wasn't caught by the suite and a handful of regressions causes by enabling a new feature or updating llvm".

Even Rust Editions are not a good point of comparison because they are also time based and only leveraged by things that would otherwise be breaking changes.

What you could use for direct comparison is accepted Rust RFCs against accepted C++ proposals papers or the equivalent for other languages. Or merged Pull/Merge Request counts for the different tool chains. But that's not perfect either (Rust only supports one language, while GCC several, but it has a package manager, which GCC doesn't).

101 stable Rust minor releases, because 1.0 was a stable release, and many more micro releases incorporating merely urgent bug fixes with no other work.

Even ignoring K&R C there is C89, C99, C11, C17, C23 and C2y is in progress. I don't see any way to squint at that and count four.

It was only added to the registry spec a few releases ago. We can't guarantee that a registry has updated to provide it.

once outlook broke we can't even share jensen memes

You're downvoted but it's a very legitimate question. My main language at work is Rust, I had some expertise with the language (and deep interest for functional programming languages and type theory), but I almost don't read the code nowadays, I just skim though the functions and type definitions. I'm genuinely surprised that there are so many comments commenting the release. I thought most programmers wouldn't care anymore.

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.

because they change the binary layout sometimes, and the benefits have not yet been judged to be worth freezing it.

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.