1. There is no launch event, the release notes are a list, and by tomorrow

nobody will be discussing it.

That is the interesting part.

what a metronome produces#

Features ship when they are ready, not when a date needs filling. A fixed train with frequent departures means nothing is ever rushed to make a release — it just goes in the next one, six weeks later. Compare with an annual release, where missing the window costs a year and the pressure to ship something half-finished is enormous.

No release is a big deal, so no release is risky. Upgrading across six weeks of change is routine. Upgrading across a year of change is a project. The frequency is what keeps each step small enough to be boring.

Continuous improvement is invisible and enormous. Any single Rust release looks minor. The five-year delta is a different language: async in traits, let chains, const generics, a rewritten trait solver, dramatically better error messages, a linker that made everyone's builds faster without anyone opting in.

Nobody experienced that as an upgrade. It arrived six weeks at a time.

the part that makes it work#

The cadence alone would not be enough. What makes it safe is the stability guarantee: code that compiled on stable keeps compiling. Breaking changes go through editions — opt-in, per-crate, with automated migration, on a multi-year cycle.

So the six-week train carries only additions and fixes. The scary changes ride a different, much slower vehicle, and you choose when to board.

That separation is the actual design insight, and it is the thing most projects miss when they copy the cadence without the guarantee.

what to do on release day#

The same short list, every time:

1. Update and run your tests. rustup update stable. This is almost always uneventful, which is the point.
2. Read the release notes for stabilised APIs. This is where you find the std function that lets you delete a dependency or an unsafe block.
3. Run cargo clippy. New releases teach clippy new lints, and those lints find real bugs in code that has been compiling for years.
4. Check cargo build --timings occasionally. Compiler performance work lands continuously and you will never notice it unless you look.

the transferable lesson#

If you maintain anything other people depend on, the two-track structure is worth stealing regardless of your language:

• A frequent, predictable, purely-additive train that is always safe to board.
• A separate, rare, opt-in mechanism for the changes that break things, with tooling to migrate.

Most projects have neither — they ship when they ship, and breaking changes arrive mixed into ordinary releases. That combination is what makes upgrades scary, and upgrades being scary is what leaves everyone three versions behind.

Rust's release notes are boring because the interesting decisions were made about process, once, a decade ago.

Rather than enumerate, it is worth asking what "finished" would look like and how close this is.

what got finished#

The list of "this obviously should work and does not" items has genuinely shrunk. Trait upcasting, let chains, RPIT capture, anonymous pipes, const in more places, SIMD intrinsics, async closures. Each of those was a multi-year open question and each is now just how the language works.

That is the signature of a language moving from the growth phase into the maintenance phase, and it is a good place to be. The compiler is faster than it was. The error messages remain the best in the industry. The tooling story — cargo, clippy, rustfmt, rust-analyzer — is coherent in a way that most languages never achieve.

what is left, honestly#

Async. Still the sharpest edge. Async traits work. Async closures work. What does not work smoothly: cancellation semantics that do not surprise you, async drop, Send bound propagation through generic async code, and the absence of a standard executor interface which fragments the ecosystem.

The Pin API remains the piece of Rust that experienced engineers most often describe as genuinely confusing, and the ergonomic improvements have been incremental.

This is the area where Rust is meaningfully harder than it needs to be, and where a new user is most likely to conclude the language is too complicated. It matters because async is how you write network services, and network services are most of software.

Const generic expressions. [T; N * 2] still needs nightly. The blocker is real — deciding when two type-level expressions are equal is undecidable in general and the team will not ship a rule they cannot explain.

GUI. Ten-plus years, several serious projects, no consensus. Partly a Rust problem: the borrow checker's relationship with the retained-mode widget tree that every traditional GUI framework uses is genuinely awkward. Partly not a Rust problem: cross-platform GUI is unsolved everywhere.

Compile times. Better every year. Still slower than Go. Structurally will remain so, because monomorphization and the optimization Rust performs are not free and are the reason the output is fast.

the adoption picture, unsentimentally#

Won decisively: systems programming, CLI tooling, JavaScript build tooling, cryptography implementations, embedded, WebAssembly targets, kernel drivers in both Linux and Windows.

Winning slowly: backend services, where Go's simplicity and compile speed are a real competitor and where the async ergonomics cost is felt daily.

Not winning and probably will not: application development, data science, scripting. Different constraints, different right answers.

That is a good outcome. A language does not need to win everything, and the places Rust won are the places where memory safety bugs were causing the most damage.

the thing to appreciate#

Eleven years of six-week releases and no broken stable program. Three editions with automated migration and no ecosystem split. A governance structure that has survived real disagreements in public.

For a language that has changed as much as Rust has, that stability record is the actual achievement, and it is the reason people are willing to put infrastructure on it. Features are cheap. Trust is not.

for someone deciding whether to learn it in 2026#

If you write systems software, networking infrastructure, embedded code, or anything where a memory safety bug is a security incident: yes, and you probably already know that.

If you write web applications: the async ergonomics are the thing you will fight, and Go or a good typed scripting language will make you more productive faster. Learn Rust anyway, eventually, because understanding ownership makes you better in every language.

If you tried it in 2021 and bounced off the compile times or the error messages: try again. Both are substantially different now.

Rather than enumerate this release, here is the year.

what landed in 2025#

Rust 2024 edition (1.85, February). RPIT lifetime capture, unsafe attributes, tail expression temporary scope, gen reserved. The largest edition so far and the migration was mostly mechanical.

Trait upcasting (1.86, April). Eight years open. Deleted a category of boilerplate from every plugin system in the ecosystem.

Anonymous pipes in std (1.87, May), on the tenth anniversary of 1.0.

Let chains (1.88, June). The single most requested ergonomic improvement, unblocked by the edition's scope changes.

x86 SIMD stabilizations (1.89, August). Removed a real competitive disadvantage against C++ for numerical work.

LLD as the default linker on Linux (1.90, September). Build times improved for everyone, most of whom did not notice a release note.

Continuous const expansion across every release, moving more computation to compile time.

the shape of the year#

No single dramatic feature. A lot of things that had been open for years finally closing.

That is what a language looks like when it has passed the phase of adding capability and entered the phase of finishing what it started. The backlog of "this should work and does not" is getting shorter.

what is still open#

Async. Async traits work but the ergonomics around lifetimes, Send bounds, and cancellation remain the sharpest edges in the language. Async closures landed this year and help. The full story — async drop, better cancellation semantics, a standard executor interface — is still ahead.

Const generic expressions. [T; N * 2] still requires nightly. The blocker is the type-equality question and it is genuinely hard.

GUI. Ten years of effort, several promising projects, no consensus. This is partly a Rust problem and mostly the fact that cross-platform GUI is unsolved everywhere.

Compile times. Better every year, still slower than Go, probably always will be for structural reasons.

the adoption picture#

Rust in 2025 is: the default for new systems software, a significant and growing presence in the Linux and Windows kernels, the implementation language for most new JavaScript tooling, and increasingly common in infrastructure that used to be Go or C++.

It is not the default for application development and shows no sign of becoming so. That is fine. It was never the goal and the systems niche is where the memory-safety bugs were.

the thing worth appreciating#

Rust ships every six weeks and has never broken a stable program. There has been no Python 3. There has been no C++11-style decade-long adoption lag.

For a language that has changed as much as Rust has in ten years, that is a remarkable engineering and governance achievement, and it is the reason people are willing to build load-bearing infrastructure in it.

Boring release notes are the reward for getting the hard part right.

the pattern#

A large fraction of Rust's per-release API additions exist to let you delete an unsafe block.

Some recent examples across the last year of releases:

• HashMap::get_disjoint_mut — previously required unsafe or a clumsy dance.
• <[T]>::as_chunks — previously a transmute or a manual loop with unchecked indexing.
• Vec::extract_if — previously either an allocation or unsafe in-place work.
• std::io::pipe — previously platform-specific unsafe FFI.
• Const-stabilized functions across the library — previously a lazy_static or a build script.

None of these are exciting individually. Cumulatively they are the mechanism by which the amount of unsafe code in the average Rust program keeps going down.

why this matters more than features#

The value proposition of Rust is memory safety without a garbage collector. Every unsafe block is a hole in that guarantee — a place where the compiler stops checking and a human is asserting correctness.

Studies of real-world Rust code consistently find that most unsafe usage falls into a small number of patterns, and that a majority of those patterns exist because the safe standard library did not offer the operation.

So the library team's strategy is: find the patterns, provide safe equivalents, watch the unsafe count fall. It works, and it is measurable.

The remaining unsafe concentrates in the places where it belongs — FFI, hardware interaction, and hand-optimized data structures — where it is reviewed by people who know what they are doing, in crates that are audited.

the const story specifically#

Const stabilization is the other steady drip. Every release moves more functions into const fn, meaning they can run at compile time.

The practical effect is that more computation moves from runtime to compile time, and more static data can be computed rather than hand-written. Lookup tables, parsed configuration, precomputed constants — all of it can now be expressed as code that runs during compilation.

const TABLE: [u32; 256] = {
    let mut t = [0u32; 256];
    let mut i = 0;
    while i < 256 { t[i] = crc_entry(i as u8); i += 1; }
    t
};

That would have required a build script or a generated file a few years ago.

the honest limitations#

Const generics still cannot do arithmetic in type position without nightly. Async in traits works but has sharp edges around lifetimes and Send bounds. The GUI ecosystem remains unsettled after a decade of attempts.

None of those are getting fixed this release, or probably next release. Rust's development model trades speed for not making mistakes it cannot undo, and the consequence is that the hard problems stay open for a long time.

That is a defensible trade for a language with a stability guarantee, and it is genuinely frustrating if you are blocked on one of them.

the meta-observation#

If you want to evaluate a language's health, do not look at its feature announcements. Look at whether the amount of dangerous code required to do ordinary things is going up or down.

By that measure Rust is doing better than almost anything else, and it is doing it in increments so small that nobody writes headlines about them.

why linking matters#

For a large Rust binary, linking is frequently the dominant cost of an incremental build. You change one line, the compiler recompiles one crate quickly, and then the linker spends several seconds stitching together a hundred megabytes of object files and debug information.

GNU ld is old, single-threaded in the parts that matter, and was designed for a different era of binary sizes. lld is parallel, substantially faster, and has been production-ready for years — it is the default on several other platforms already.

Reported improvements vary by project, with the largest gains on debug builds of large dependency trees. Two to five times faster linking is a common range. If your edit-compile-run loop is four seconds and linking was two of them, you feel this every single time.

how to check#

cargo build --timings

Opens an HTML report showing where time went, including link time as a distinct phase. Most people have never looked at this and are surprised by what it says.

If you were already opting into lld or mold via .cargo/config.toml, nothing changes for you. If you were not — which is most people, because the configuration was obscure and required knowing it existed — you get the improvement for free on upgrade.

the general lesson#

Defaults are the most impactful thing a toolchain ships.

A faster linker has been available for years. Anyone could have configured it. The instructions were in a blog post. Almost nobody did, because it required knowing the option existed, knowing it was safe, and caring enough to edit a config file.

Changing the default delivers the improvement to everyone at once. That is worth more than a decade of documentation.

This generalizes. If you maintain a tool and you find yourself writing documentation explaining how to enable a better behavior, ask whether the better behavior should be the default. The answer is usually yes, and the reason it is not is usually caution about breaking a small number of unusual setups — which is a real concern that should be handled with a flag to opt out, not a flag to opt in.

the rest of 1.90#

• Cargo workspace publishing — cargo publish --workspace publishes multiple interdependent crates in the correct order. Anyone maintaining a multi-crate project has written a shell script for this. Now you can delete it.
• Demoted target tiers for several less-used platforms.
• x86_64-apple-darwin demoted to tier 2 with host tools still provided, which reflects where Apple hardware has actually gone.
• The usual const stabilizations and API additions.

the trend line#

Rust's reputation for slow compilation is the single most cited objection to adopting it, and it has been steadily addressed for years: incremental compilation, parallel front-end work, the new trait solver, better caching, and now the linker.

Compile times are meaningfully better than they were three years ago and still slower than Go. That gap is partly fundamental — monomorphization and the amount of optimization Rust does are not free — and partly still addressable.

Anyone who tried Rust in 2021 and bounced off the build times should try again. The numbers are different now.

fn frobnicate<const N: usize>(arr: [u8; N]) -> [u8; N] { /* ... */ }

let data = [1, 2, 3, 4];
let out: [u8; _] = frobnicate(data);   // N inferred as 4

Previously you either wrote the number, which duplicated information the compiler already had, or restructured to avoid needing it. Small change, removes a real papercut, and it composes well with the growing amount of const-generic code in the ecosystem.

the SIMD stabilizations#

A large batch of x86 intrinsics stabilized, including AVX-512 families. This matters for a specific and growing population: people writing hand-tuned kernels in Rust for compression, encoding, cryptography, and increasingly ML inference.

Before this, using these intrinsics required nightly. Which meant that a production library wanting AVX-512 paths had to either require nightly — a non-starter for most consumers — or drop to C via FFI.

That was a genuine competitive disadvantage against C++ for numerical work and it is now mostly gone.

The pattern for using them safely:

if is_x86_feature_detected!("avx512f") {
    unsafe { fast_path_avx512(data) }
} else if is_x86_feature_detected!("avx2") {
    unsafe { fast_path_avx2(data) }
} else {
    scalar_path(data)
}

Runtime detection, multiple implementations, scalar fallback. Tedious and correct. std::simd remains unstable for the portable abstraction, which is the thing most people actually want and which continues to take a long time.

also in the release#

• unsafe attributes get more coverage, continuing the 2024 edition direction.
• Result::flatten stabilizes. Small and frequently wanted.
• Cargo now supports --compile-time-deps for building only what is needed for procedural macros and build scripts, which speeds up some tooling workflows meaningfully.
• i686 targets raise their baseline CPU requirement, which will affect approximately nobody and will affect them a lot.

the const generics arc, for context#

Const generics were stabilized in a minimal form in Rust 1.51, four years ago. Since then the feature has been growing capability incrementally: first only integers, then inference improvements, then better error messages, now this.

The full feature — const generic expressions, where you can write [T; N * 2] — is still unstable and has been "coming soon" for a long time. The blocker is that arbitrary const expressions in type position require deciding when two type-level expressions are equal, which is undecidable in general and requires drawing a careful line.

Rust's approach to this has consistently been: ship the decidable subset, leave the hard part open, do not paint yourself into a corner. It is slow and it has not produced an unsound type system, which is more than several languages with similar features can say.

the feature#

You can now chain let bindings with boolean conditions in if and while:

if let Some(user) = session.user()
    && user.is_admin()
    && let Ok(perms) = load_permissions(user.id)
    && perms.contains(Permission::Delete)
{
    delete_record(id)?;
}

Before this you wrote the pyramid:

if let Some(user) = session.user() {
    if user.is_admin() {
        if let Ok(perms) = load_permissions(user.id) {
            if perms.contains(Permission::Delete) {
                delete_record(id)?;
            }
        }
    }
}

Or you restructured with early returns and helper functions, which is often better anyway but was not always applicable — particularly inside a match arm or a loop body where you cannot return.

the edition caveat#

Let chains require the 2024 edition. This is not arbitrary: the tail-expression temporary scope changes in 2024 are what make the drop semantics of a chained let well-defined. In earlier editions the temporaries created in the chain would live too long and the borrow behavior would be surprising in ways that could not be fixed without a breaking change.

This is a nice demonstration of what editions are actually for. A feature was blocked for years on a semantic problem; the edition boundary let them fix the semantics; the feature shipped.

the rest of the release#

Naked functions. #[unsafe(naked)] with a naked_asm! body produces a function with no compiler-generated prologue or epilogue. You need this for interrupt handlers, syscall entry points, and context switching. Previously it required an external crate with fragile assumptions.

Automatic cargo cache cleaning. Cargo now garbage-collects unused files in its global cache. If you have been running cargo clean on a cron job or watching ~/.cargo/registry grow to forty gigabytes, that is handled now.

cfg(true) and cfg(false) as boolean literals in configuration predicates. Small, and it removes a genuinely silly workaround people were using.

Cell::update, several const stabilizations, and the usual batch of API additions.

the pattern in Rust's release cadence#

Rust ships every six weeks, forever, with no marketing cycle and no "major release." What that produces is a language that improves continuously in small increments, where any given release seems minor and the five-year delta is enormous.

Compare Rust in 2020 — no async traits, no GATs, no let chains, no let-else, no const generics worth using, a much worse compiler error story — to Rust today. The difference is large and there was never a moment where it happened.

That is a good way to run a language. It is also why "should I learn Rust" gets different answers from people who last tried it at different times, and why the answer today is different from the answer three years ago.

anonymous pipes#

std::io::pipe() gives you a cross-platform anonymous pipe in the standard library:

use std::io::pipe;
use std::process::Command;

let (mut reader, writer) = pipe()?;
let mut child = Command::new("ls")
    .stdout(writer.try_clone()?)
    .stderr(writer)
    .spawn()?;

let mut merged = String::new();
reader.read_to_string(&mut merged)?;
child.wait()?;

Interleaving stdout and stderr into one stream, in order, has been a recurring annoyance requiring either a platform-specific unsafe block or a dependency. Now it is three lines of std.

asm! can jump to Rust#

Inline assembly can now use labels that jump back into Rust code. This is deeply niche and matters enormously to the handful of people writing kernels, bootloaders, and hypervisors in Rust — which, at this point, is a real number of people.

the smaller items#

• Vec::extract_if and LinkedList::extract_if — remove and yield elements matching a predicate, in place, without collecting into a temporary.
• <[T]>::as_chunks — split a slice into fixed-size arrays, safely, with the remainder returned separately. Useful for everything from SIMD prep to parsing.
• i686-pc-windows-gnu demoted to tier 2 without host tools.
• Numerous const fn stabilizations, which continue at a steady drip.

ten years#

Rust 1.0 shipped on 15 May 2015. The stability promise made then has held: code written against 1.0 still compiles, editions handled the syntax evolution without splitting the ecosystem, and there has been no Python 3 moment.

That is the achievement. Not the borrow checker, which is what everybody talks about. The borrow checker is a good idea that several research languages had first. What Rust did that no research language did was ship it with a package manager people liked, a stability guarantee people trusted, and an upgrade path that did not require rewriting anything.

Where it landed in a decade: Linux kernel drivers, Windows kernel components, Android's Bluetooth and media stacks, the core of several CDNs, most new CLI tooling in the JavaScript ecosystem, and a substantial share of new infrastructure software generally.

Where it did not land: application development, mostly. The GUI story is still unsettled after ten years of effort. Async Rust is still the sharpest edge in the language, and the "async traits and lifetime puzzles" complaint from 2020 is only partially resolved.

The honest summary: Rust won the systems niche decisively and did not win general-purpose programming, which is fine, because it was never going to and the systems niche is where the memory-safety bugs were.

Ten more years of the same trajectory and half the internet's infrastructure will be written in it.

the problem it fixes#

Given a supertrait relationship, you could not coerce a trait object of the subtrait to a trait object of the supertrait:

trait Animal { fn name(&self) -> String; }
trait Dog: Animal { fn bark(&self); }

fn describe(a: &dyn Animal) { println!("{}", a.name()); }

fn use_dog(d: &dyn Dog) {
    describe(d);   // ERROR before 1.86
}

The workaround was a manual as_animal(&self) -> &dyn Animal method on every trait, implemented identically in every impl, existing purely to launder a pointer. Anyone building an ECS, a plugin registry, or any kind of heterogeneous object graph has written that boilerplate.

As of 1.86 the coercion just works. The vtable layout was changed so a subtrait's vtable embeds a pointer to the supertrait's, which is why this took eight years — it is a change to the ABI of trait objects, and getting it right without regressing size or dispatch cost required several redesigns.

the soundness fix#

Also in this release: a long-standing hole around Box<T> in the presence of Deref implementations that could produce aliasing violations under certain generic code. The details are in the release notes and are worth reading if you write unsafe. If you do not write unsafe, this fixed a bug you never knew you could have had.

the small ergonomics#

HashMap::get_disjoint_mut — get mutable references to multiple distinct keys at once, checked at runtime for disjointness:

let [a, b] = map.get_disjoint_mut(["alice", "bob"]);

Previously this required either two lookups with an intermediate remove, or RefCell, or an unsafe block, all to express something that is obviously fine.

{float}::next_down and next_up — the adjacent representable float. Niche, and if you need it you really need it.

Target tier changes — several targets moved up and down the support tiers, as always. Check if you cross-compile to anything unusual.

the pattern#

Rust's stabilization pace on "obvious" features looks glacial from the outside and the reason is almost always the same: the obvious feature interacts with three other features in a way that produces unsoundness, and the team will not ship unsound.

Trait upcasting is a good example. The naive implementation is easy. The implementation that does not break dyn compatibility rules, does not bloat vtables, does not break existing unsafe code that assumed a layout, and composes correctly with associated types took most of a decade.

You can find that frustrating and still prefer it to the alternative.

where Rust for Linux actually is#

The infrastructure has been merged for several cycles. What has been slower is the bindings: the safe Rust abstractions over kernel C APIs that a driver author would actually use. You cannot write a Rust network driver until somebody writes a sound Rust abstraction over the network device API, and doing that correctly requires deep agreement between the Rust folks and the maintainer of the subsystem in question.

That is where the friction is, and it is not primarily technical.

The concern from some longtime maintainers is legitimate and worth stating plainly: if a Rust abstraction wraps a C API, then a change to the C API can break the Rust side, and now the C maintainer is on the hook for a language they did not sign up to learn. Multiply across dozens of subsystems and you have a real maintenance burden distributed to people who did not choose it.

The counter-position, also legitimate: memory safety bugs in drivers are a substantial and ongoing fraction of kernel CVEs, drivers are where most kernel code lives, and drivers are exactly the place where a language with compile-time memory safety pays off most.

Linus's stated position has been consistent — Rust is welcome, the experiment continues, and maintainers are not required to accept Rust in their subsystems but also are not permitted to block it purely on preference. That is a politically difficult line to hold and he has mostly held it.

the technical state#

What exists and works today:

• Kernel allocation, error handling, and the Result-based error propagation.
• Enough abstraction for real drivers — the Android Binder rewrite and the Asahi Linux GPU driver are both substantial Rust codebases running in production on real hardware.
• pin-init, which solves the self-referential-struct problem that makes kernel data structures awkward in safe Rust.

What is still hard:

• The compiler version floor keeps moving, which distributions dislike.
• Rust's story for no_std allocation failure handling required work that only exists because the kernel needed it.
• Architecture coverage. Rust needs an LLVM backend for the target, which rules out several architectures the kernel still supports.

the honest assessment#

This will take longer than advocates hope and will succeed more than skeptics expect. The pattern is already visible: new drivers in Rust where a maintainer is willing, C everywhere else, indefinitely. Nobody is rewriting the VFS.

That is a fine outcome. The goal was never a Rust kernel. It was to stop shipping new memory-safety bugs in the parts of the kernel that get the most new code, and on that specific goal the trajectory is good.

Run cargo fix --edition first. It handles most of it. Here is what it cannot.

the changes that will bite#

RPIT lifetime capture. In edition 2024, -> impl Trait in a free function captures all in-scope lifetime parameters by default, matching what async fn already did. Previously it captured only type parameters, and you had to add a + '_ or a witness parameter to opt in.

This makes the common case work without incantations. It also means some signatures that compiled before now fail borrow checking, because the returned opaque type is now considered to borrow something it did not before. The fix is the new use<..> syntax to state precisely what is captured:

fn parse<'a>(input: &'a str) -> impl Iterator<Item = &'a str> + use<'a> {
    input.split(',')
}

unsafe attributes. #[no_mangle], #[export_name] and #[link_section] are now written #[unsafe(no_mangle)]. These attributes can violate soundness — no_mangle can collide with a symbol the linker resolves differently — and the language now says so out loud. Mechanical fix, applied by cargo fix.

unsafe extern blocks. Declaring a foreign function is an unsafe assertion about its signature. Now spelled that way.

gen is a reserved keyword. Generator blocks are coming; the keyword is reserved now so it can land without another edition. If you have a variable named gen, rename it. Yes, this affects more code than you would think.

Tail expression temporary scope. Temporaries in the final expression of a block now drop before local variables rather than after. This fixes a class of surprising deadlocks with MutexGuard in a tail position, and changes drop order in ways that could matter if you have Drop impls with side effects.

if let temporary scope. Temporaries in an if let scrutinee now drop at the end of the if let, not at the end of the enclosing statement. Same category: fixes real deadlocks, changes observable drop timing.

Never type fallback. ! now falls back to ! instead of () in more positions. Mostly this makes bad code fail to compile rather than silently doing something odd.

Cargo resolver v3 becomes the default, which is the MSRV-aware resolver from 1.84.

should you migrate#

Yes, but not urgently and not during a crunch. The migration is mostly mechanical; the RPIT changes and the drop-order changes are the two places where you need to actually think.

Do it on a quiet week, run your full test suite, and pay specific attention to anything with a Drop impl that touches shared state. That is where a silently-changed behavior can hide.

the meta-point about editions#

Rust's edition mechanism remains the best answer anyone has shipped to the problem of evolving a language without breaking the world. C++ cannot do this. Python's answer took a decade and cost the community enormously. Rust gets to change syntax and semantics on a six-year cadence, per-crate, with automated migration, and old code keeps compiling forever.

That is a genuinely important piece of language design and it is underrated because it works.

If that sentence meant nothing to you, that is fine and arguably intended. Here is why it matters anyway.

what a trait solver does#

When you write impl Display for MyType, the compiler has to answer questions like: does this impl overlap with another one? Can this generic bound be satisfied? Is this associated type equal to that one? The component answering those questions is the trait solver, and the old one grew organically over a decade of Rust's life. It has known unsoundness holes, it has performance cliffs, and it has behaviors nobody can fully explain including the people who wrote it.

The new solver is a ground-up reimplementation with a proper handling of cycles, coinduction, and caching. Coherence checking — the "do these two impls conflict" question — is the first place it has been switched on by default, because coherence is a relatively contained problem where a regression shows up loudly at compile time rather than quietly at runtime.

what you might actually see#

A very small number of crates will now get errors they did not get before, because the old solver was accepting impls it should not have. That is a fix, not a regression, but it will feel like a regression if it happens to you. The release notes flag it.

Also in this release:

• Strict provenance APIs stabilize. ptr::with_addr, ptr::addr, ptr::map_addr and friends. This is the vocabulary for expressing pointer arithmetic in a way that does not launder provenance through an integer, which matters enormously for Miri, for CHERI-style hardware, and for anyone whose code is going to be checked by a tool smarter than themselves.
• Cargo respects the rust-version field when resolving dependencies. The MSRV-aware resolver will now prefer a dependency version compatible with your declared minimum Rust version instead of picking the newest and detonating. This has been requested for years and quietly fixes a real papercut for anybody supporting older toolchains.

[package]
rust-version = "1.75"   # cargo now actually uses this during resolution

the pattern worth noticing#

Rust's release train has settled into a rhythm where the exciting user-facing features arrive in editions and the intervening six-week releases carry structural work. 1.84 is almost entirely structural. The new solver has been in development for something like three years and is being landed one surface at a time, with the more invasive switch — using it everywhere, not just coherence — still ahead.

That is how you replace a load-bearing component in a language with a stability guarantee. Slowly, in public, with the ability to flip back. It is unglamorous and it is the reason people trust the toolchain.

Rust 2024 edition lands with 1.85 next month, and that one will be noisy.