the two strategies#

Ride the LTS train. Upgrade only on LTS versions, roughly every two years. Vendors support them for years. This is what most enterprises do.

Ride every release. Upgrade every six months. Each step is small.

The instinct is that LTS is the conservative choice. It is worth examining that, because it is not obviously true.

the case against LTS-only#

Bigger jumps. Two years of change absorbed at once, including four releases' worth of deprecations and removals, all discovered in the same week.

Deprecation surprises. Features are deprecated in one release and removed a few later. On the every-release path you see the warning and have six months. On the LTS path the warning and the removal can arrive in the same upgrade.

You are testing a configuration fewer people ran. Ironically, the LTS jump from N to N+8 is a path exercised by fewer teams than each individual step.

Two years of free performance left on the table. GC and JIT work lands continuously.

the case for it#

Vendor support. For some organisations this is contractual and ends the discussion.

Fewer upgrade events. Each one has fixed overhead — testing, coordination, sign-off. Four small upgrades can cost more total effort than one large one, even if each is easier.

Library ecosystem lag. Frameworks target LTS versions first. On a non-LTS release you can be waiting for a dependency.

That last one is the real constraint, and it is the honest reason most teams stay on LTS.

the strategy that gets the benefit of both#

Run your tests on every release; run production on LTS.

Add the latest JDK to your CI matrix as a non-blocking job. It costs a few minutes per build. When something breaks, you find out six months early, in a build, rather than during the upgrade under a deadline.

This is a small change with a large effect on how the LTS jump feels, and it is the single most useful thing a team on the LTS path can do.

the upgrade checklist#

• Check the removal list first, not the feature list. Removed APIs and changed defaults are what break you.
• Run with -Xlint:all and --enable-preview off. Preview features are not a migration target.
• Re-benchmark rather than assuming. GC defaults and JIT behaviour change; usually for the better, occasionally not for your allocation pattern.
• Check your agents. Profilers, APM agents and anything doing bytecode instrumentation are the most common source of upgrade breakage, and they break loudly at startup rather than subtly at runtime.
• Look at what virtual threads did to your pool sizing if you have adopted them. Connection pools sized for a thread-pool world are now the bottleneck.

the general point#

Any dependency with a fixed cadence — Java, Go, Rust, Python, Node, Postgres — presents the same question: small steps often, or large steps rarely.

The answer that keeps being right is small steps often, with the large-step path tested continuously in CI. It converts a scary infrequent event into a boring frequent one, which is the same trick that makes deployment safe.

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.

The predictability is not incidental to Go's success. It is a substantial part of it, and it is worth examining because most projects get this wrong in the other direction.

what a fixed cadence buys#

Planning that does not require guessing. A team can put "upgrade Go" in the calendar twice a year, permanently, and never think about it again. Compare with a project that ships when it is ready: every upgrade is an unscheduled interruption someone has to notice and argue for.

Features that are not held hostage. When the train leaves on a fixed date, an unfinished feature waits for the next one instead of delaying the release. That means no pressure to ship something half-done to make a date, and no feature holding the whole release. Rust's six-week cycle works the same way, and both languages are visibly healthier for it.

A support window you can reason about. Go supports the two most recent releases. That is a rolling twelve months, always, with no announcement needed.

the compatibility promise underneath#

None of the cadence would matter without Go 1's compatibility guarantee: code written against Go 1 continues to compile and run. That has held since 2012.

The combination is what makes Go upgrades routine rather than projects. You are not choosing between "stay on an old version" and "spend a sprint migrating" — the upgrade is a version bump in one file, a test run, and a deploy.

Very few ecosystems can say that. It is the single most underrated thing about the language and it almost never appears in comparisons, because absence of pain is hard to notice.

what to actually do on release day#

Nothing dramatic, which is the point.

1. Read the release notes, specifically the "minor changes to the library" section. That is where behaviour shifts that are technically compatible and practically surprising tend to live.
2. Bump the toolchain line in go.mod and run your tests.
3. Check the vet and linter output. New releases usually teach go vet new checks, and those checks find real bugs in code that has been running for years.
4. Look at the GC and runtime notes if you run anything latency-sensitive. Runtime changes are where the performance surprises are, in both directions.
5. Do not skip versions. Two at a time is fine. Four is where people start having a bad week.

the general lesson#

If you maintain anything with users — a library, an internal platform, a service other teams build on — the cadence question is worth asking directly: do people know when the next version arrives, and can they plan around it?

"When it's ready" is the honest answer for a side project and a liability for anything load-bearing. A published date, even a slow one, lets everyone downstream stop guessing.

Boring, on a schedule, is a feature.

the on-device strategy, holding#

Apple's position has been consistent and, I think, correct for their situation:

• A small model on device, free, private, offline, exposed to third-party apps through a constrained system API.
• A larger model available for the cases the small one cannot handle.
• Routing handled by the system.
• Privacy as the differentiating property rather than raw capability.

That is not going to win a benchmark comparison and it was never trying to. It is going to win on the axis where Apple competes, which is a coherent product where the default behavior is the one most users want.

For developers, the practical implication has not changed: design features so the small model handles the common case.

Concretely — the 90% that the on-device model can do is free, instant, and works on a plane. The 10% that needs escalation costs money and needs a network. Getting that split right is the engineering, and it is a different skill from prompt design.

the Swift trajectory#

Swift continues its expansion beyond Apple platforms — server-side, embedded, WebAssembly, cross-platform tooling. The concurrency model's strict checking continues to produce a language that catches data races at compile time, which is a genuinely valuable property that the migration cost has made contentious.

The honest state: strict concurrency checking is correct and it is a real migration burden for existing codebases, and the error messages when you get it wrong are still harder to act on than they should be.

Swift is a better language than it gets credit for outside the Apple ecosystem and its adoption outside that ecosystem remains limited, mostly for reasons of tooling gravity rather than language quality.

the platform policy question#

The regulatory pressure on app distribution and payments continues, differently in different jurisdictions, with the result that the rules now vary by region in ways that are genuinely confusing for developers to comply with.

I do not have a clean position on the substance. What I will say is the practical part:

If you ship an app with any monetization, you now have jurisdiction-specific compliance work, and the rules are still moving. Budget for it, watch the changes, and do not assume a policy you read last year is current.

The broader observation, which is not about Apple specifically: the era of one global set of platform rules is over. Every major platform now operates under different obligations in the EU, the US, and several other markets, and that fragmentation is going to increase rather than resolve.

the things worth actually adopting#

Filtering out the keynote, the items that will matter to a working developer:

Anything that reduces app size or launch time. These are the metrics that correlate with retention and they get the least stage time.

Testing and debugging improvements in the toolchain. Consistently the most valuable and least covered part of every WWDC.

Deprecation notices. The most important announcements at any platform conference are the ones about what is going away, and they are never in the keynote. Read the release notes.

the honest assessment#

Apple ships coherent, well-integrated platforms with genuinely good on-device capability and a privacy posture that is a real product differentiator rather than only marketing.

It also operates the developer relationship with less flexibility than any comparable platform, and the regulatory environment is the mechanism by which that is being adjusted rather than any change of heart.

Both of those have been true for a decade and neither is changing this year.

where free-threading actually stands#

The GIL-free build has been officially supported since 3.14. The question was never whether CPython could do it — it demonstrably can — but whether the ecosystem would follow.

What has gone well:

The major numerical and data libraries did the work. NumPy, and the array and dataframe ecosystem around it, ship free-threaded wheels. That was the critical path, because those libraries are the reason a large fraction of Python's CPU-bound workload exists.

Single-threaded performance in the free-threaded build has improved substantially since 3.13. The gap against the default build has narrowed to something most applications would not notice.

Build infrastructure caught up. Producing free-threaded wheels is now a configuration change rather than a project.

What has gone slowly:

The long tail. Thousands of packages with C extensions have not been audited, and most of them will not be until someone hits a problem.

The subtler issue: pure-Python code that was accidentally thread-safe. The GIL made many operations effectively atomic. Code written under that assumption — a dictionary mutated from multiple threads, a counter incremented without a lock — worked by accident. Under free-threading it does not.

Nobody knows how much library code depends on this, because nobody ever had to think about it. It will be discovered one race condition at a time.

the practical guidance#

Do not switch production workloads casually. The performance win only exists for CPU-bound multithreaded work. If your workload is I/O-bound, asyncio was already handling it and free-threading gives you nothing.

Do test your libraries against it. The compatibility work has to happen and it happens when people run into problems and report them. If you maintain a package with a C extension, this is your work to do.

Do use it for the workloads it is for. Data processing, image and signal processing, simulation, anything numeric that currently uses multiprocessing and pays serialization and memory-duplication costs.

The migration from multiprocessing to threads for those workloads is frequently dramatic — not just faster, but simpler, because you delete the serialization layer.

the other thing in 3.15#

Subinterpreters continue maturing. concurrent.interpreters gives you isolated interpreter instances in one process, with much lower overhead than processes and much stronger isolation than threads.

This is the underrated option. For a workload where you want parallelism and do not want shared mutable state — which is most workloads — subinterpreters give you the process model's safety at closer to the thread model's cost.

It is the right default for a lot of the cases people currently reach for multiprocessing for, and it does not require any of the thread-safety auditing that free-threading does.

Error messages continue improving, which has been a multi-release trend and has made Python meaningfully friendlier for people learning it.

the assessment#

Python is executing a decade-long project to stop being single-threaded, and it is doing it without breaking the ecosystem, on an opt-in basis, with a fallback.

That is the right way to do it and it is slower than anyone wants. The alternative — a hard break, a Python 4 — would have been faster and would have cost the community what Python 3 cost it, which nobody has the appetite for.

Ask again in three years. The trajectory is good and the destination is not in doubt; only the timeline is.

what it is#

Destructuring and dispatch in one construct: match a value against a shape, bind its parts to names, and branch on which shape matched.

Java:

String describe(Shape s) {
    return switch (s) {
        case Circle c when c.radius() > 100 -> "big circle";
        case Circle c                        -> "circle r=" + c.radius();
        case Rect(int w, int h) when w == h  -> "square " + w;
        case Rect(int w, int h)              -> "rect " + w + "x" + h;
    };
}

Python:

match command.split():
    case ["move", direction]:
        move(direction)
    case ["take", *items] if items:
        for item in items: take(item)
    case _:
        unknown()

Both are doing the same thing: testing structure, extracting components, and binding them, in one expression.

why it matters more than it looks#

Exhaustiveness checking. This is the actual payoff and it is easy to miss.

If your type system knows the complete set of possible shapes — a sealed hierarchy in Java, a union type in TypeScript, an enum in Rust — the compiler can verify that your match handles all of them.

Which means: add a new case to your data model, and the compiler tells you every place that needs updating.

That is a qualitatively different maintenance experience. Without it, adding a new variant means grepping for every switch statement and hoping. With it, the build fails until you have handled it everywhere.

This is the single largest practical benefit of algebraic data types and most discussion of pattern matching skips it entirely in favor of syntax.

It replaces the visitor pattern. An entire design pattern existed because object-oriented languages could not dispatch on structure. That pattern is a significant amount of ceremony — an interface, an accept method on every node, a visitor implementation — to express what pattern matching says in five lines.

If you have a visitor in your codebase and your language now has pattern matching, you can delete a lot of code.

It makes illegal states harder to express. Combined with sum types, you can model "this is one of exactly these things" and have the compiler enforce it, rather than a class with six nullable fields where only certain combinations are valid.

the caveats#

Python's match is not exhaustiveness-checked. It is a runtime construct. Without a sealed type system there is nothing to check against. Type checkers can do some of this with Literal and Union types and it is not enforced by the language.

That makes Python's version considerably less valuable than Java's or Rust's — it is nicer destructuring syntax rather than a correctness tool.

Capture semantics surprise people. In Python, a bare name in a pattern binds, it does not compare. This is the number one confusion:

match color:
    case RED:      # binds `color` to RED — matches everything!
        ...
    case Color.RED:  # this compares
        ...

A dotted name compares. A bare name binds. Everybody gets this wrong once.

Overuse. Pattern matching is satisfying and it is possible to write a match statement where an if would be clearer. If you are matching on one condition, use an if.

the trend it is part of#

Pattern matching is one of several ideas migrating from functional languages into the mainstream, along with immutability by default, expression-oriented syntax, Option/Result types instead of null and exceptions, and real sum types.

Each of these took decades to cross over. The reason is not that the ideas were unknown — it is that mainstream languages have compatibility obligations that make adding a feature to an existing type system extraordinarily hard, and it takes a generation of language designers who grew up with the ideas to do the work.

The next ones in the queue, visibly: effect systems, better concurrency abstractions in the type system, and some form of ownership tracking outside of Rust.

Give it ten years.

what a type system buys#

Errors found before running. The obvious one. A type error is a bug that cannot reach production, and the earlier a bug is found the cheaper it is.

Documentation that cannot rot. A signature is documentation the compiler checks. Comments lie; types cannot.

Refactoring confidence. Rename a field, and the compiler enumerates every place that breaks. In a dynamic language you grep and hope.

Editor intelligence. Completion, go-to-definition, and find-references are functions of type information. The difference in tooling quality between typed and untyped codebases is enormous and underweighted in these arguments.

Machine-checked verification. The one that got more valuable recently. If generated code has to pass a typechecker, that is verification you did not have to do by reading.

what it costs#

Expressiveness constraints. Some correct programs are rejected. Every type system rejects programs that would have worked, and the more powerful the system, the more elaborate the workarounds for the cases it cannot express.

Ceremony. Type annotations, generic parameters, explicit conversions, interface declarations. Real typing overhead on the keyboard and real reading overhead on the page.

Compile time. Typechecking is work. In a large codebase with a sophisticated type system, it can be a lot of work.

A learning curve that is genuinely steep at the top end. Higher-kinded types, variance, existentials, effect systems. These are powerful and they are also the reason some codebases are unapproachable.

the honest heuristic#

Script under 200 lines that you will run once: dynamic. The type system's benefit does not have time to accrue.

Anything with more than one author: static. The documentation and refactoring benefits scale directly with the number of people who need to understand code they did not write.

Anything that will live more than a year: static. You are the other author, in eight months, with no memory.

Library or API consumed by others: static, and be maximally explicit. Your types are the contract.

Exploratory data work: dynamic, usually. The shapes change constantly and the consequence of an error is a wrong number in a notebook, which you will see.

Anything where a bug is expensive: the strongest type system you can afford, and consider a language with real algebraic data types so you can make illegal states unrepresentable.

the gradual typing reality#

Most of the interesting action is in gradual systems — TypeScript, Python's type hints, Ruby's type tooling, PHP's declarations.

These are genuinely useful and they have a specific failure mode worth naming: the guarantees are only as strong as the least-typed part of the path.

A TypeScript codebase with any scattered through it, or with hand-written type declarations for an untyped dependency that are subtly wrong, provides confidence that is not backed by anything. That is worse than no types, because you trust it.

The practical discipline:

• Turn on strict mode. strict: true in TypeScript, strict in mypy. The non-strict modes permit exactly the holes that make the system unreliable.
• Ban any at the boundary. Runtime validation at every point where external data enters — API responses, user input, environment variables, database rows. A parsed-and-validated type is a guarantee; a cast is a wish.

// this is a lie
const user = await res.json() as User;

// this is a guarantee
const user = UserSchema.parse(await res.json());

• Type the boundaries first. Interior code benefits less. External interfaces benefit most.

the thing that changed#

Type systems got more valuable in the last two years for a reason that has nothing to do with the traditional arguments.

If a substantial share of your code is generated, then every constraint the compiler can check is verification you do not have to perform by reading. And reading is now the bottleneck.

A generated function that typechecks against a well-specified interface has already been verified against one important class of error. A generated function in an untyped language has been verified against nothing.

That is a genuinely new argument and it has moved teams that were unmoved by twenty years of the old ones.

the design decision that defines it#

Go's compatibility promise is stronger than almost any language's: code written against Go 1 continues to compile and run. That has held since 2012.

Combined with a deliberate resistance to adding features, the effect is that Go code from 2015 reads like Go code from today. There is one way to do most things. There is no dialect. There is no "modern Go" versus "legacy Go."

For a language used to write infrastructure that must be maintained for a decade by rotating teams, that property is worth more than any individual feature.

what the criticism gets right#

Error handling is verbose. if err != nil is a large share of the lines in a lot of Go code. The proposals to fix it have all been rejected, repeatedly, and the reasoning — that explicit error handling at every call site is a feature, not a bug — is coherent and is genuinely annoying to live with.

Generics arrived late and are limited. No sum types. No method type parameters. The type inference gives up in cases where you expect it to work. Generics in Go are useful and they are clearly a retrofit.

The nil interface trap. A nil pointer stored in an interface produces a non-nil interface. This bites everyone once and it is a genuine wart.

No sum types. The single most requested feature. Modeling "this is one of three things" in Go requires an interface with unexported methods and a type switch, which is neither exhaustive-checked nor pleasant.

what the criticism gets wrong#

The complaints are almost all about expressiveness, and expressiveness is not the thing Go optimizes for. It optimizes for a large team maintaining a large codebase over a long time, with new people joining constantly.

Under that objective function:

• Verbosity is fine if it makes the code obvious without context.
• Few features is good, because every feature is a dialect someone will write in and someone else will have to read.
• Fast compilation matters enormously, because it determines the feedback loop and therefore how people work.
• A good standard library means fewer dependencies, which means fewer supply chain problems and fewer upgrade treadmills.
• gofmt ended formatting arguments permanently, which saved the industry an incalculable number of hours.

Go is not trying to be a good language for writing clever code. It is trying to be a good language for reading code someone else wrote three years ago while you are on call at 3 a.m.

It is very good at that.

the concurrency story, honestly#

Goroutines and channels were revolutionary in 2012 and are now table stakes. Several languages have equivalent or better models.

What has held up: the scheduler is excellent, the tooling around concurrency — the race detector especially — is best in class, and context for cancellation propagation is a good design that most ecosystems lack an equivalent of.

What has not: channels are overused by people who learned Go from the tour. Most Go code should use a mutex and a plain function call. "Do not communicate by sharing memory; share memory by communicating" is good advice that has produced a lot of unnecessarily channel-based code.

where it wins#

Network services, CLI tools, infrastructure daemons, anything deployed as a single static binary, anything with a large team.

The ecosystem effect is real: a very large fraction of the cloud-native stack is Go. If you work in infrastructure, you will read Go whether or not you write it.

where it does not#

Anything needing precise memory control. Anything numeric or scientific, where the ecosystem is thin and the language does not help. Anything where expressiveness genuinely pays — a compiler, a complex domain model, anything with rich algebraic structure.

the thing worth stealing#

Whatever language you use: Go's compatibility promise, its formatting standardization, and its resistance to feature accumulation are choices, not accidents.

Most projects would benefit from adopting the spirit of all three. Pick one way to do things. Automate the formatting argument out of existence. Say no to the feature that adds a second way to express something that already has one.

That is available to you regardless of your language, and it is most of what makes Go codebases pleasant.

what they are#

A virtual thread is a thread managed by the JVM rather than the operating system. Creating one costs on the order of a few hundred bytes rather than a megabyte of stack. Blocking one parks it and frees the underlying carrier thread rather than blocking an OS thread.

The consequence: you can have millions of them, and blocking is no longer expensive.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    for (var request : requests) {
        executor.submit(() -> handle(request));   // one thread per request, fine
    }
}

why this mattered more than it looked#

The Java ecosystem spent a decade building around the assumption that threads are expensive. That assumption produced:

• Thread pools everywhere, with sizing that nobody understood.
• Reactive programming frameworks, with their entirely separate ecosystem of types, operators, and debugging misery.
• CompletableFuture chains that are unreadable after three composed steps.
• Stack traces that told you nothing because the actual work happened on a different thread than the code you wrote.

All of that complexity existed to avoid blocking. Virtual threads make blocking cheap, which removes the reason for all of it.

The single biggest practical win is debugging. A virtual thread's stack trace is the actual call stack of the actual logical operation. Compare that to a reactive pipeline, where the stack trace is the scheduler and the real causal chain is reconstructed by squinting at operator names.

Teams that migrated report this as the thing they did not expect and would not give up.

the pitfalls that are real#

Pinning. A virtual thread inside a synchronized block cannot unmount from its carrier thread — it pins it. If that code then blocks, you have consumed an OS thread for the duration, and with a small carrier pool you can deadlock.

The fix is ReentrantLock instead of synchronized. Later JDK releases reduced the pinning cases substantially; library code you do not control can still do it.

Detect it:

-Djdk.tracePinnedThreads=full

Run that in a load test before you go to production. Every migration finds something.

ThreadLocal at scale. A ThreadLocal with a million threads is a million copies. Libraries that cache expensive objects per-thread — some serializers, some date formatters, some connection helpers — become a memory problem.

Scoped values are the intended replacement and are the right answer for request-scoped context.

Unbounded concurrency. Thread pools were an accidental rate limiter. Remove them and you can now issue ten thousand concurrent requests to a downstream service that handles two hundred. You have moved the failure from your service to theirs, which is worse.

You still need bounded concurrency. It just belongs at the resource — a semaphore around the downstream call — rather than as a global thread pool.

Connection pools. Your database connection pool is sized for a thread-pool world. It is now the bottleneck, and the right size is a different calculation. This surprises people.

the migration advice#

Do not rewrite anything. Virtual threads work with the code you have. Switch the executor, run your load tests, look for pinning, size your connection pools, done.

Do not migrate reactive code that works. A well-functioning reactive service should be left alone. The migration cost is real and the benefit is maintainability, which is a slow-compounding return.

Do migrate new services. Writing a new service with virtual threads and plain blocking code is dramatically simpler than the reactive equivalent, and simpler code is the whole point.

the broader lesson#

An enormous amount of accumulated architectural complexity existed to work around one runtime limitation. Removing the limitation made the complexity obsolete overnight — but only for code written after, because nobody rewrites working systems.

That is worth remembering the next time you build elaborate machinery around a platform constraint. Ask how likely the constraint is to persist, and whether the machinery will outlive it.

Usually it will, sitting in your codebase, load-bearing and pointless.

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.

the year in one paragraph#

An open reasoning model under an MIT license repriced the sector in January. Reasoning became a runtime dial rather than a model choice. Coding agents went from research preview to standard tooling in about six months and made code review the bottleneck. The npm ecosystem got a self-propagating worm. Two of the largest infrastructure providers had multi-hour outages caused by config, not code. Python removed the GIL, optionally. Rust shipped its largest edition. The frontier models converged and the competition moved to price and distribution.

the three things that will still matter in 2030#

1. Reasoning as a controllable runtime parameter.

The most durable technical idea of the year. Every provider independently arrived at the same design: the caller decides how much the model thinks, per request.

This is durable because it reflects something true about the problem — the appropriate amount of computation is a property of the task, not the model, and only the caller knows the task. Interfaces that reflect true structure survive. Interfaces that reflect an implementation detail do not.

2. The agent-review bottleneck.

Generation throughput increased dramatically. Verification throughput did not. That gap is the central engineering problem of the next several years, and nobody has a good answer.

Everything downstream follows from it: how teams are structured, what tests are for, what "code review" means, whether we build systems we understand or systems that pass tests. This is not a tooling problem that gets solved with a better diff viewer. It is a fundamental asymmetry between producing and checking, and it shows up in every field where automation outpaced verification.

3. Supply chain trust has no technical fix yet.

Four significant npm incidents this year, escalating in sophistication, ending with a worm. Every one exploited the same structural fact: install-time code execution plus long-lived publishing credentials plus a dependency graph nobody designed.

The controls that work — trusted publishing, no install scripts, version cooldowns, phishing-resistant auth — are known and unevenly adopted. The ecosystems that are structurally safer got that way by design decisions made years ago that cannot be retrofitted cheaply.

This gets worse before it gets better, and it is a solvable problem that we are choosing not to solve at the speed it requires.

the things that felt big and were not#

Model benchmark leapfrogging. Every launch claimed the frontier. The differences were within evaluation noise for most real tasks. The benchmark discourse consumed enormous attention and predicted very little about what was useful.

Agent frameworks. Most of the orchestration layer got absorbed into the models, exactly as function-calling libraries and JSON-repair libraries were absorbed before. The durable layer was never orchestration.

The browser wars, round two. Everyone shipped a Chromium fork with a model in it. That does not diversify the engine landscape; it diversifies the UI on top of one engine.

the things that felt small and were not#

LLD as the default linker in Rust. A default change delivered a build-time improvement to everyone at once that documentation had failed to deliver for years. The general lesson — defaults are the highest-leverage thing a toolchain ships — applies far beyond Rust.

Template strings in Python. A one-character syntax change that makes the safe path as easy as the unsafe one. If library adoption follows, an entire category of injection vulnerability becomes hard to write. Security features that depend on diligence fail; security features enforced by the type system work.

Context editing and memory tools. Unglamorous plumbing that determines whether long agent runs succeed. The context window was never the constraint. Goal retention was.

the thing I want to say going into next year#

The most valuable skill in 2025 was not prompting, and it will not be in 2026 either.

It was the ability to tell whether something is correct. That skill was always valuable and it was previously bundled with the ability to produce the thing. The bundle has come apart. Producing is cheap now. Checking is not, and checking is what everything rests on.

Every argument this year about what AI does to engineering eventually reduces to that. The people who are getting enormous leverage out of these tools are, without exception, the people who can tell when the output is wrong.

That is not a comforting conclusion for anyone hoping the tools eliminate the need for expertise. It is the actual state of things, and it is worth building your career around.

See you in January.

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.

free-threading is officially supported#

The GIL-free build, introduced experimentally in 3.13, is now an officially supported configuration. Not the default — you install python3.14t alongside the standard build — but supported, with a commitment to maintain it.

This is the largest change to Python's execution model since the language existed. The global interpreter lock has meant that CPU-bound Python code cannot use multiple cores in one process, which is why every CPU-bound Python program either uses multiprocessing (with its serialization overhead and memory duplication) or drops into C.

python3.14t -c "import sys; print(sys._is_gil_enabled())"
# False

The caveats are real and you should read them before getting excited.

Single-threaded performance in the free-threaded build is slower — the reference counting has to be thread-safe, and that costs. The gap has narrowed a lot between 3.13 and 3.14 and it has not closed.

C extensions must be explicitly compatible. Anything using the C API with assumptions about GIL protection needs auditing. The major numerical and data libraries have been doing this work for two years; the long tail has not.

And the hard part: your Python code is now actually concurrent. Race conditions that the GIL was accidentally preventing are now possible. Code that was "thread-safe" because bytecode operations were effectively atomic may not be. Nobody knows how much library code depends on this implicitly, because nobody has ever had to know.

Do not switch production workloads casually. Do start testing your libraries against it, because the compatibility work has to happen somewhere.

t-strings#

PEP 750 lands. t"..." produces a Template with the static parts and the interpolated values separated, rather than a concatenated string.

from string.templatelib import Template
name = input()
query = t"select * from users where name = {name}"
query.strings   # static segments
query.values    # (name,)

A library receiving a Template can parameterize the SQL, escape by HTML context, or quote for a shell — correctly, because it can still tell the difference between the template and the data.

The value depends entirely on library adoption. Watch the database drivers.

deferred annotation evaluation#

PEP 649. Annotations are no longer evaluated at definition time; they are computed lazily when something asks for them.

def process(items: list[Order]) -> Report:   # Order and Report need not exist yet
    ...

This kills from __future__ import annotations, kills most string-quoted forward references, and fixes the circular import problems that plague any codebase using type hints heavily across modules.

It also makes runtime introspection cheaper for the common case where nobody looks at annotations at all.

the rest#

• Multiple interpreters in the standard library (concurrent.interpreters), giving true isolation with lower overhead than processes.
• A new REPL with syntax highlighting and better multi-line editing.
• except without parentheses for multiple exception types.
• Substantially better error messages, continuing a multi-release trend that has made Python meaningfully friendlier to learn.

the assessment#

Python's response to being slow and single-threaded has, for two decades, been "call C." 3.14 is the release where the language stops accepting that as the answer.

Free-threading plus subinterpreters plus the ongoing specializing-interpreter work is a coherent strategy for making Python a reasonable choice for CPU-bound work. It will take several more releases and a lot of ecosystem effort.

It is genuinely happening, which is more than most people expected five years ago.

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.

the version reset#

Every OS jumps to 26: iOS 26, macOS 26 Tahoe, watchOS 26, tvOS 26, visionOS 26. Year-based, aligned across platforms, matching the model-year convention.

Genuinely good housekeeping. "Requires iOS 17, macOS 14, watchOS 10" was needlessly hard to reason about. Now it is one number.

Liquid Glass#

A system-wide redesign built around translucent, refractive material that reacts to content behind and beneath it. Controls float. Layers have depth. Things bend light.

Reactions split predictably. It is undeniably a strong visual identity and the first genuinely new direction since iOS 7 flattened everything in 2013. It is also, in the first betas, a legibility problem in a lot of contexts — text over a refractive layer over a busy background is exactly the situation typography guidance has warned about for a century.

Apple will iterate through the beta cycle. They always do. Contrast will be raised, blur will be increased, and the shipping version will be about 70% of the demo. That is the normal arc and knowing it saves you from having the argument twice.

For developers: if you use standard controls you get it for free. If you built custom UI, budget real time. Custom navigation bars and tab bars in particular are going to need work.

Foundation Models framework#

Here is the actual news. Apple exposes the on-device model to third-party apps via a Swift API, with guided generation, tool calling, and streaming.

import FoundationModels

@Generable
struct Recipe {
    @Guide(description: "Dish name") var name: String
    @Guide(.count(3...8)) var ingredients: [String]
    var minutes: Int
}

let session = LanguageModelSession()
let recipe = try await session.respond(to: "A quick pasta dish", generating: Recipe.self)

That @Generable macro is the good part. You define a Swift type, the framework constrains decoding so the output is guaranteed to parse into it. No JSON parsing, no retry loop for malformed output, no schema drift between your prompt and your struct. Type safety all the way through.

And it costs nothing per call. No API key, no rate limit, no network, no privacy review. For a small on-device model that is enough for summarization, classification, extraction, and simple generation, that changes the calculus for a huge number of app features that were previously not worth a server bill.

The model is small — roughly 3B parameters — and you should not expect frontier behavior. Expect a good small model that is free and private, and design features that fit that envelope.

Containerization#

A framework for running Linux containers on macOS with each container in its own lightweight VM, open source, with sub-second start times. Docker Desktop on macOS has been a performance complaint for a decade. This is Apple's answer and it is architecturally cleaner: per-container VMs rather than one shared Linux VM.

Xcode 26#

Model integration in the editor with support for multiple providers including Claude, plus a new coding assistant experience. Apple shipping first-party support for a competitor's model inside its own IDE is notable — it means they have concluded the model layer is a component, not a differentiator.

the read#

Consumer-facing, this was a design conference. Developer-facing, it was the conference where Apple's local-first AI strategy finally produced something you can build on.

The strategy is coherent: small models on device, free and private, with the big stuff handled elsewhere. It is not going to win benchmark comparisons and it was never trying to.

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.

This is a small feature with a large security implication.

the problem it solves#

F-strings are wonderful and they are the most common source of injection bugs in modern Python, because they make the wrong thing effortless:

# this is a SQL injection and it looks completely normal
cursor.execute(f"SELECT * FROM users WHERE name = '{name}'")

# so is this, for HTML
return f"<div>{user_bio}</div>"

The f-string evaluates and concatenates before the function ever sees it. By the time execute gets the string, the distinction between the query template and the user data is gone permanently. There is no way for a library to help you.

what t-strings do#

A t-string does not produce a string. It produces a Template containing the static text segments and the interpolations separately:

from string.templatelib import Template

name = "Robert'); DROP TABLE students;--"
t = t"SELECT * FROM users WHERE name = '{name}'"

type(t)          # <class 'string.templatelib.Template'>
t.strings        # ("SELECT * FROM users WHERE name = '", "'")
t.values         # ("Robert'); DROP TABLE students;--",)

Now a library can do the right thing. A SQL driver can turn the static parts into a parameterized query and bind the values. An HTML library can escape each interpolation according to its context — attribute versus text node versus URL — which is something no escaping function can do correctly without knowing where the value landed.

# a hypothetical driver that accepts templates
await conn.execute(t"SELECT * FROM users WHERE name = {name}")
# becomes: SELECT * FROM users WHERE name = $1, with name bound

The syntax is identical to an f-string. Format specs and conversions work. Nesting works. The only difference is the prefix and the type.

why this is the right design#

The alternative approaches all failed for the same reason: they required the developer to do extra work at the call site, and developers under deadline do the easy thing.

t"..." is exactly as easy as f"...". It is one character. And crucially, a function that expects a Template will reject an f-string with a type error — so a library can make the safe path the only path, and the unsafe call site becomes a build failure rather than a pentest finding.

That is the property that makes this work. Security features that depend on diligence do not scale. Security features that are enforced by the type system do.

what to watch#

The value of this feature is entirely downstream: it depends on library authors adopting it. Watch for template support in the major database drivers, the templating engines, the shell-command helpers, and the logging libraries.

If that adoption happens over the next couple of release cycles, a whole category of Python vulnerability quietly stops being writable. If it does not, this is a nice piece of syntax nobody uses.

Bet on adoption. The ergonomics are too good and the security argument is too easy to make to a security team.

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.