Yet another Hacker News

Rust 1.100

54 points mbStavola 2 hours ago 67 comments

ComputerGuru 2 hours ago | parent

It would probably be better to wait for the official release blog post for submission to HN, no?

qchris 2 hours ago | parent

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

NobodyNada 2 hours ago | parent

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

nirinor 2 hours ago | parent

Woohoo, that's a release! My personal favorites:

- 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

karavelov 2 hours ago | parent

Finally, "never" happened

jmyeet 1 hour ago | parent

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

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

JoshTriplett 1 hour ago | parent

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

hbn 59 minutes ago | parent

We got "never" in Rust before GTA6

Two jokes that are expiring this month

pmichaud 2 hours ago | parent

Nice work... but I still yearn for a stable ABI!

orlp 2 hours ago | parent

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

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

Xirdus 1 hour ago | parent

An actual stable native Rust ABI is a prerequisite for distributing libraries as anything other than source code.

redox99 1 hour ago | parent

Why would you want libraries in any other format?

eviks 1 hour ago | parent

Not to waste time and space?

wahern 1 hour ago | parent

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.

SkiFire13 1 hour ago | parent

It's not a strict prerequisite, you can just require the library being distributed to use extern "C".

gspr 1 hour ago | parent

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.

Xirdus 35 minutes ago | parent

Or to put it another way, it is a strict prerequisite and Rust already meets it via extern "C".

afdbcreid 1 hour ago | parent

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.

fallingbananna 1 hour ago | parent

If you can drop the "native" requirement, then Wasm is also a way.

ChadNauseam 1 hour ago | parent

What is the advantage of doing so? Is it for cases where your source code is confidential but you want to sell access to your library?

Svoka 1 hour ago | parent

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

silon42 1 hour ago | parent

So, all Linux will be Gentoo?

gspr 56 minutes ago | parent

Dynamic linking is useful. Not to everyone and not always, but it is.

iknowstuff 1 hour ago | parent

Follow or contribute to efforts on a minimal crABI:

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

aitchnyu 1 hour ago | parent

Couldnt Google. Is it pronounced crabby?

iknowstuff 1 hour ago | parent

Sure is :)

stillpointlab 1 hour ago | parent

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

JoshTriplett 1 hour ago | parent

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

mamcx 8 minutes ago | parent

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.

danhor 24 minutes ago | parent

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.

fallingmeat 2 hours ago | parent

wait other things not named jensen happened today? whoa

nazgulsenpai 2 hours ago | parent

once outlook broke we can't even share jensen memes

lukax 2 hours ago | parent

Awesome timing.

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

weinzierl 1 hour ago | parent

"Awesome timing."

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

steveklabnik 1 hour ago | parent

A monumental release. Thanks to everyone who worked so hard on all of these long-term features that are finally landing.

hobofan 1 hour ago | parent

Thanks to all the maintainers and contributors! That's one of the biggest releases in a long time!

fock 1 hour ago | parent

also humans contributing! Very cool!

fluffiac 1 hour ago | parent

yay never type!!

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?

NobodyNada 1 hour ago | parent

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

n_u 1 hour ago | parent

> Cargo now reports unused dependencies to users, e.g.

> 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

minimaxir 46 minutes ago | parent

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.

jtwaleson 8 minutes ago | parent

Does this remove the need for machete or shear?

Surac 1 hour ago | parent

Still non ABI. Why is ist so hard? what is holding them back. Andy why does it need a unsave keyword? can't they marshal types like other languages?

adamch 1 hour ago | parent

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

galangalalgol 17 minutes ago | parent

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.

ammar_az 1 hour ago | parent

This release is so big that multiple useful stabilized API aren't event mentioned in the blog post like:

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

afdbcreid 1 hour ago | parent

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

ustad 1 hour ago | parent

“Never type” - Feel like I’m stupid for not having a clue what that means.

pkulak 1 hour ago | parent

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.

igravious 49 minutes ago | parent

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 …

anamexis 1 hour ago | parent

The explanation in OP seems pretty solid.

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

LoganDark 58 minutes ago | parent

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.

Xirdus 44 minutes ago | parent

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.

boston_clone 19 minutes ago | parent

Comprehensive yet succinct, and appreciate you tying it to math - that helped solidify the idea.

NooneAtAll5 22 minutes ago | parent

noreturn, basically

KolmogorovComp 1 hour ago | parent

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.

raphlinus 33 minutes ago | parent

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.

jadbox 1 hour ago | parent

Is the compiler any faster now? Compiling takes forever. I'm also tired of always having to do "cargo clean" everyday to clear out 90gb of temp files.

vlovich123 55 minutes ago | parent

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.

jtwaleson 6 minutes ago | parent

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.

steveklabnik 55 minutes ago | parent

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.

throwaway27448 47 minutes ago | parent

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.

epage 45 minutes ago | parent

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

small_model 14 minutes ago | parent

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.

amelius 11 minutes ago | parent

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

0o777 4 minutes ago | parent

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

grommz 7 minutes ago | parent

Feels good to have deleted the last traces of rust from my system, and any project that uses it. Looking at you Matrix.