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.

the trap#

Five years of support sounds generous, so the upgrade never makes the roadmap. Then one of two things happens:

You reach end of life and have to do four or five major versions at once, under time pressure, with an accumulated set of behaviour changes nobody has read about.

You quietly lose years of free improvement. Postgres releases carry substantial planner, vacuum and I/O work every single year. A database three versions behind is slower than it needs to be, on hardware you are already paying for.

The teams that find upgrades painful are always the ones who defer them. The teams that upgrade every year find it boring, because one version of behaviour change is a changelog and four versions is a project.

what to actually do#

Read one document: the release notes' incompatibilities section. Not the feature list — the "Migration to Version N" section at the top. It is usually under a page and it is the only part that can hurt you.

Test on a copy of production, at production size. Restore a real dump, run your application's test suite against it, and run your slowest queries. Planner changes are the main source of surprise, and they only show up with real statistics and real data volume.

Check your extensions first. This is the most common blocker. Every extension must have a build for the target version, and if you depend on something niche, verify before you plan anything else.

Use logical replication for anything where downtime matters. Replicate old to new, let it catch up, cut over. pg_upgrade --link is fast and requires a maintenance window; logical replication is more setup and needs seconds.

Run ANALYZE immediately after. Modern pg_upgrade carries statistics across, which removed the classic post-upgrade outage where a statistics-free database planned everything terribly. Verify it happened rather than assuming.

the operational habit worth adopting#

Put it in the calendar: evaluate in October, upgrade in the first quarter.

That gives the release a few point versions to settle, keeps you at most one version behind, and turns the whole thing into a scheduled chore rather than an emergency. The same pattern works for any dependency with an annual cadence, and the calendar entry is what makes it happen — nobody ever gets around to it otherwise.

the version everyone is actually on#

Run this and find out where you really are:

SELECT version();
SELECT name, setting FROM pg_settings WHERE name IN
  ('server_version_num', 'shared_buffers', 'effective_cache_size',
   'work_mem', 'max_connections', 'effective_io_concurrency');

While you are there: max_connections is almost certainly too high and effective_io_concurrency is almost certainly too low for SSD storage. Both defaults date from an era of different hardware, and both are one-line changes with measurable effects.

The upgrade is the boring part. The settings nobody has revisited since the database was provisioned are usually the bigger win.

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.

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.

That was not true three years ago and it is a meaningful simplification.

the workflow#

{
  "compilerOptions": {
    "erasableSyntaxOnly": true,
    "verbatimModuleSyntax": true,
    "module": "nodenext",
    "strict": true,
    "noEmit": true
  }
}

node --test          # test runner, built in
node --watch app.ts  # dev, with reload, running TypeScript directly
npx tsc              # typecheck only, in CI
node app.ts          # production

No bundler. No transpiler in the runtime path. No ts-node. No nodemon. No dotenv. No test framework. No node-fetch.

The erasableSyntaxOnly flag is what makes it safe: it rejects any TypeScript syntax that cannot be removed by whitespace substitution — enums, namespaces with runtime values, parameter properties — so your source is guaranteed to run under type stripping.

what got absorbed, cumulatively#

Over the last several major versions Node has taken into the runtime:

Every one of those is a dependency removed, which is a supply chain surface removed, an upgrade treadmill removed, and a postinstall script removed.

For a small service, a fresh project's dependency count is now dramatically lower than it would have been in 2022. That is the most important consequence and it is rarely framed that way.

the division of labor that makes sense#

Typechecking belongs in CI and your editor. Not in the production runtime hot path. tsc --noEmit in CI, language server in your editor, type stripping at runtime.

A type error will happily run under stripping and fail at runtime. That is the correct trade — you check types where checking is cheap and run where running should be fast — and it requires that CI actually gates on the typecheck. If it does not, you have given up types.

Bundling is still right for some things. If you deploy to a serverless platform where cold start scales with file count, bundling helps. If you ship to browsers, obviously. For a long-running server process, it buys you nothing.

what is still missing#

Decorators. They are not erasable — they generate runtime code. If your framework depends on decorator-based dependency injection or routing, you need a transform. Several major frameworks are in this category, and it is the single most common blocker for adopting the no-build workflow.

Path aliases. @/components/foo requires resolution mapping. Node supports imports in package.json with the # prefix, which works and requires changing your import style.

Anything in your build that is not TypeScript. CSS modules, GraphQL documents, asset imports. If your build does more than strip types, you still have a build.

the migration advice#

If you are on Node 22 or earlier, plan the move. Check:

• Base image compatibility — minimum glibc and macOS versions have moved.
• Deprecated APIs that now throw rather than warn.
• Native modules, which need a rebuild.

Run the full suite on the new version in CI before switching the default. The upgrade is usually uneventful and "usually" is load-bearing.

the broader observation#

Node's response to competitive pressure from Deno and Bun was to absorb their best ideas rather than to argue about philosophy.

That was correct, it took about four years, and the ecosystem is meaningfully better for it. Competition in developer tooling works, and the incumbent that responds by improving rather than by defending is the one that keeps the position.

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.

what you get in 24 LTS#

The accumulated result of the last two years of Node absorbing its own ecosystem:

• A test runner (node --test) with coverage, mocking, and watch mode.
• TypeScript type stripping, no build step.
• A permission model for filesystem, network, and child process access.
• .env file loading built in.
• A SQLite module in the standard library.
• fetch, WebSocket, URLPattern as globals.
• using declarations for deterministic resource cleanup.
• A watch mode that does not require nodemon.

Every one of those replaced a dependency. That is the whole story of Node's last three years, and it was the correct response to competitive pressure.

where the three landed#

Node won by absorbing. It has the ecosystem, the deployment targets, the enterprise support, and now most of the convenience. Its remaining weaknesses are startup time and the accumulated weight of API decisions from 2010 that cannot be changed.

Deno built the best security model and the most coherent standard library, then spent years walking back the decisions that made adoption hard — first adding npm compatibility, then node_modules, then package.json. It is excellent and it is a niche, and the trademark dispute over "JavaScript" was an unusual way to spend a year.

Bun won on speed and on the package manager. bun install is dramatically faster than npm and a very large number of teams use it for exactly that while running Node in production. That is a real and defensible position — being the best tool for one step of the workflow.

what actually changed for developers#

The competition worked. All three runtimes are much better than Node was in 2021, and Node specifically improved in ways it had resisted for a decade.

That is the argument for competition in developer tooling, and it is worth remembering when a dominant tool seems permanent.

practical guidance#

For a new production service: Node 24 LTS. The ecosystem compatibility and operational maturity dominate, and the convenience gap has closed.

For a CLI or a script: Bun, probably. Startup time and the single-binary story are genuinely better, and the compatibility risk is low for a program you control end to end.

For anything where sandboxing matters: Deno's permission model is the most mature, though Node's is now credible.

For your package manager: Bun or pnpm. npm is fine and it is slower, and the difference on a large install is minutes rather than seconds.

the migration note#

If you are on Node 20, plan the move to 24. Node 22 is a reasonable interim stop and there is no strong reason to linger there.

Things to check:

• Base image compatibility. Node 24 raises minimum glibc and macOS versions.
• Deprecated APIs that now throw rather than warning.
• Native modules. Anything with a compiled component needs a rebuild and possibly an upgrade.

Run your full test suite on 24 in CI before you switch the default. The upgrade is usually uneventful and "usually" is doing work in that sentence.

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.

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 notable bits#

ext4 gains support for concurrent direct I/O writes to the same file when using extent-based allocation without needing exclusive inode locking. For database workloads on ext4 this is a meaningful throughput improvement — the exclusive lock was a real serialization point on write-heavy workloads with many threads hitting one large file.

If you run Postgres or MySQL on ext4 with direct I/O, this is worth benchmarking after you upgrade.

Btrfs continues its steady improvement, including better handling of large folios. XFS got more work on its atomic write support, which is one of those capabilities that unlocks meaningful optimizations in databases that can rely on it — no more double-write buffers if the filesystem can guarantee torn-write protection.

More Rust bindings landed, including additional infrastructure for DRM drivers. The Rust-for-Linux effort continues its subsystem-by-subsystem advance.

Futex improvements for scalability under contention, which matters for any heavily threaded userspace runtime — the JVM, Go's scheduler, and every async runtime with a work-stealing thread pool ultimately bottom out here.

the thing about boring releases#

The Linux kernel ships roughly every nine to ten weeks. It has done so for two decades. Every release contains thousands of commits from over a thousand developers across hundreds of companies who mostly compete with each other.

There is no roadmap document. There is no product manager. There is a maintainer hierarchy, a merge window, a stabilization period, and a release.

It works better than almost any commercially-managed software project on earth, and the reason is worth thinking about: the process optimizes for not regressing above everything else. The famous "we do not break userspace" rule is not politeness, it is the constraint that makes an enormous decentralized project tractable. If the interface contract is inviolable, subsystems can evolve independently without coordination.

That is the actual lesson for people building large systems. Stable interfaces between components are what let you have many independent teams. Every organization that struggles with cross-team coordination is, underneath, struggling with unstable interfaces.

the maintainer question#

Worth noting alongside: the kernel has a succession problem. A meaningful number of critical subsystems are maintained by people who have been doing it for fifteen or twenty years, and the pipeline of replacements is thin.

This is true of most critical infrastructure software and it does not get attention because it is not an incident until it is. The number of load-bearing open source projects with exactly one active maintainer remains one of the scariest statistics in computing.

If your company depends on the kernel — and it does — funding maintainers is a better use of security budget than most of the things in your security budget.

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 lineup now reads as a clean cost-capability ladder, which is a thing Google has struggled to communicate for two years:

the thinking budget, properly#

Every tier takes a thinking_budget parameter. Setting it to 0 disables reasoning entirely; setting it to -1 lets the model decide.

from google import genai
from google.genai import types

client = genai.Client()
resp = client.models.generate_content(
    model="gemini-2.5-flash",
    contents="Classify this ticket: ...",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_budget=0)
    ),
)

I want to be emphatic about this because it is the single largest cost lever available in a reasoning model and most teams are not touching it.

Thinking tokens are output tokens. They are billed. A classification task that gets 2,000 thinking tokens is paying for reasoning it did not need. Across a million requests that is a very real number.

The practical method:

1. Run your eval set with thinking_budget=0.
2. Run it with 512, 2048, 8192.
3. Plot quality against cost.
4. Pick the knee of the curve.

For most production tasks — extraction, classification, routing, summarization — the curve is flat and the answer is zero or near it. For planning, debugging, and multi-step math, the curve is steep. You cannot guess which without measuring, and measuring takes an hour.

the deprecation note#

Google is deprecating the 1.5 models. If you are still on 1.5 Pro, you have a migration to do, and the behavior differences are real enough that you should re-run your evals rather than assuming a drop-in.

This is going to keep happening. Model deprecation on a roughly annual cadence is now the norm across every provider, and the teams that are handling it well are the ones who wrote their eval harness first.

If you do not have one, the cost of every future model migration is a week of vibes-based testing and a production incident. If you do, it is an afternoon.

the competitive position#

Flash is, at time of writing, the best price-performance point available from any major provider for general work, by a margin that is not close. TPU economics are real.

Pro is competitive at the frontier without clearly leading. That is a much better position than Google was in a year ago, and the volume is going to come from Flash regardless.

the thing to watch#

Google's remaining weakness is developer experience: three overlapping SDKs, a confusing split between AI Studio and Vertex, documentation that assumes GCP familiarity, and a model naming scheme with -preview-05-20 suffixes.

The new unified google-genai SDK is an improvement. It is not yet where the competition is, and for a lot of teams the API ergonomics are what actually decides the default.

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.

what's in it#

V8 13.6. Brings RegExp.escape (finally), Float16Array, Atomics.pause, and explicit resource management — the using declaration:

{
  using file = await open("data.txt");
  // ...
}  // file[Symbol.asyncDispose]() called automatically

That last one is a genuinely useful addition to the language. Deterministic cleanup without try/finally pyramids, and it composes with async.

npm 11. Faster, stricter, and with better handling of the lifecycle-script security surface.

AsyncLocalStorage now defaults to AsyncContextFrame, which is a substantially faster implementation. If you use context propagation for request tracing — and if you have an observability stack, you do — this is a real performance improvement you get for free.

The permission model drops the experimental dashes. --permission instead of --experimental-permission.

node --permission --allow-fs-read=./data --allow-net=api.example.com app.js

URLPattern is global. Undici updated, so fetch behavior tracks the platform more closely.

the direction#

Look at what Node has added over the last three major versions: a test runner, a watch mode, .env file support, a permission model, TypeScript type stripping, a SQLite module, and a full fetch stack.

Every one of those was previously a dependency. jest or mocha. nodemon. dotenv. Nothing, because there was no sandbox. ts-node. better-sqlite3. node-fetch or axios.

Node is absorbing its own ecosystem's most common packages into the runtime. This is a direct response to Deno and Bun, both of which shipped batteries-included from day one and made Node's "small core" philosophy look like an excuse.

I think this is correct and overdue. "Small core, rich ecosystem" was a reasonable position in 2012, when the ecosystem was small and trustworthy. In 2025, when a fresh Express app pulls three hundred transitive dependencies and each one is a supply chain risk, every capability moved into the runtime is one fewer package with a postinstall script.

the migration notes#

• Node 24 requires a newer minimum glibc and macOS version. Check your base images.
• Some deprecated APIs finally throw instead of warning. Run your test suite before you upgrade, not after.
• If you are on 20, plan to go to 24 when it hits LTS in October rather than stopping at 22.

the type stripping question#

Node can now run .ts files by erasing types. It does not typecheck. That is the correct division of labor — typechecking belongs in your editor and your CI, not in your production runtime hot path — but it does mean a type error will happily run and fail at runtime.

The workflow that makes sense: tsc --noEmit in CI, node app.ts in production, erasableSyntaxOnly set so you cannot accidentally use syntax that requires a transform.

No build step. That is a real ergonomic win and it has been a long time coming.

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.

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.

the context#

Node.js can now strip TypeScript types and run the resulting JavaScript directly. Deno and Bun have done this for a while. The approach is deliberately dumb — it does not typecheck, it does not transform, it replaces type annotations with whitespace and runs what is left.

That works beautifully for the ninety-five percent of TypeScript that is JavaScript plus annotations. It breaks completely for the parts of TypeScript that generate code:

enum Color { Red, Green }           // emits an object at runtime
namespace Utils { export const x = 1 }  // emits an IIFE
class Point {
  constructor(private x: number) {}  // parameter properties emit assignments
}
declare module "foo" {}              // fine, erasable

You cannot erase an enum. There is nothing to erase to; the enum is runtime code wearing type-shaped syntax.

what the flag does#

erasableSyntaxOnly: true makes the compiler reject any construct that cannot be removed by whitespace substitution. Enums, namespaces with runtime values, parameter properties, and old-style import = are all errors.

{
  "compilerOptions": {
    "erasableSyntaxOnly": true,
    "verbatimModuleSyntax": true,
    "module": "nodenext"
  }
}

Turn it on and your TypeScript is guaranteed to run under any type-stripping runtime with no build step at all.

the alternatives to what it bans#

You are losing very little.

Instead of an enum, a const object with a derived union type — which most codebases already prefer because it produces cleaner types and does not have enum's bizarre bidirectional-mapping behavior:

const Color = { Red: "red", Green: "green" } as const;
type Color = typeof Color[keyof typeof Color];  // "red" | "green"

Instead of parameter properties, an explicit assignment. Two extra lines, and the ES class fields proposal made the ergonomics fine anyway.

Instead of namespaces, modules. You should have done this in 2019.

const enum remains available with preserveConstEnums, but the honest advice is to stop using it — it has never played well with isolated module compilation and it never will.

also in 5.8#

• Checked returns for conditional expressions. Return statements whose type is a conditional now get checked against each branch individually rather than against the collapsed union, which catches a real class of bug.
• --module nodenext supports require() of ESM, tracking Node's own change.
• Faster program updates on the editor path, which you will feel in a large monorepo more than any feature.

the direction#

The build step for TypeScript is dissolving. Between type stripping in runtimes, tsc --noEmit as a pure typechecker in CI, and bundlers that handle TypeScript natively, the days of TypeScript-as-a-compile-target are ending.

What remains is TypeScript as a type system layered on JavaScript — which is what it always claimed to be and only recently became true. Set the flag, delete your enums, and stop thinking about the build.

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.

what's new#

A built-in S3 client. Bun.s3 gives you presigned URLs, streaming reads and writes, and it works against any S3-compatible endpoint — R2, MinIO, Backblaze, the actual thing.

import { s3 } from "bun";

const file = s3.file("uploads/report.pdf");
await file.write(pdfBytes, { type: "application/pdf" });
const url = file.presign({ expiresIn: 3600 });

A built-in Postgres client. Bun.sql is a tagged-template SQL interface with connection pooling, prepared statements, and parameter binding that does not require you to think about $1 ordering.

import { sql } from "bun";
const users = await sql`select * from users where team = ${teamId} limit 20`;

Node compatibility as a first-class metric. Bun now publishes its pass rate against Node's own test suite and treats regressions as bugs. That is a much more honest signal than a feature checklist, and the number went up substantially in this cycle.

Text-based lockfile. bun.lock replaces the binary bun.lockb as the default. Reviewable in a pull request, diffable, mergeable. This was the single most common complaint about adopting Bun in a team setting and it is now gone.

the strategic read#

Node's answer to the same problem has been to add capabilities to the runtime incrementally and carefully: a built-in test runner, --watch, a permission model, and now stable-ish TypeScript stripping. Deno's answer was to bundle everything from the start and then spend years walking back the parts of its opinionated design that made adoption hard.

Bun's answer is to bundle everything and be compatible with Node's ecosystem rather than replacing it. That is a harder engineering problem and a much easier sales problem. Nobody has to rewrite anything. You point bun at an existing Express app and it mostly runs.

the honest caveats#

Bun's ecosystem edge cases still bite. Native modules that assume V8 internals will not work, because Bun is JavaScriptCore. Some observability agents assume Node. Long-tail packages that reach into process.binding or undocumented internals will surprise you.

The pattern for adoption in 2025 looks like: use Bun as the package manager and test runner immediately, because those are drop-in and dramatically faster; use the runtime in production when your dependency tree is one you actually understand.

That is not a hedge. That is just what shipping looks like.

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.