Everything Is Being Rewritten in Rust. Is It Time You Learned It?

A language you do not write starts showing up in the tools you depend on, then in the job specs, then in the postmortems of companies you respect, and you start wondering whether you are watching a fashion cycle or missing a floor shift. Rust has been generating that feeling since roughly 2019. The difference in 2026 is that the "any day now" claims finally have dates attached. Two questions actually cost you something: has the evidence changed enough to justify the months, and if you do learn it, where does it earn its keep versus the TypeScript you already write well.

What actually happened, with dates

Start with the Linux kernel, because it is the least sentimental community in software and it took the longest to convince. In December 2025, at the Kernel Maintainers Summit, the consensus was that Rust is no longer experimental and is now a core part of the kernel, and Miguel Ojeda posted the patch deleting the "Rust experiment" section from the docs. Greg Kroah-Hartman's read was that Rust drivers are proving far safer than the C equivalents, with fewer of the painful C-to-Rust boundary problems everyone predicted. The Rust Binder driver landed in 6.18, and Dave Airlie has said the graphics subsystem is around a year from refusing new C drivers, though that is a maintainer's stated intent rather than enacted policy, so hold it loosely.

Google published the numbers that make the safety argument concrete. In November 2025 they reported that memory-safety bugs dropped below 20% of Android's total vulnerabilities for the first time, with a memory-safety vulnerability density in Rust roughly a thousand times lower than in their C and C++. The more persuasive part is not the security data at all. It is the delivery data: Rust changes saw around four times fewer rollbacks on medium and large changes, spent about a quarter less time in code review, and needed roughly 20% fewer revisions than the C++ equivalents. That is the claim that survives contact with a CFO, because it is about the change failure rate of a team that ships, not a hypothetical CVE.

Then Cloudflare. In September 2025 they replaced FL1, the NGINX and LuaJIT stack they call the brain of Cloudflare, with FL2 written in Rust: median response time down by ten milliseconds, under half the CPU, less than half the memory. Microsoft has been doing the same quietly at a lower layer. Rust is in shipping Windows today, confirmed not by a press release but by Check Point reverse-engineering win32kbase_rs.sys, and in October 2025 they open-sourced Patina, a from-scratch Rust UEFI boot firmware implementation. The layer under the operating system.

There is also a regulatory clock running. CISA and the FBI's product security guidance asked manufacturers shipping memory-unsafe code to publish a memory-safety roadmap by 1 January 2026, NSA and CISA followed with a joint sheet on memory-safe languages, and the EU Cyber Resilience Act starts biting with vulnerability reporting obligations from 11 September 2026 ahead of the full regime in December 2027. None of that mandates Rust; the CRA mandates outcomes, not languages. What it means is that if you sell into regulated markets, "why is this in C" now has a paper trail attached, and that changes procurement long before it changes any codebase.

The part that matters if you write TypeScript

You do not have to speculate about whether Rust will affect your work, because it already runs underneath almost every command you type.

Vite 8 shipped in March 2026 with Rolldown as the default bundler, so every Vite user is now running a Rust bundler whether they opted in or not, and Rolldown hit 1.0 in May. Next.js 16 made Turbopack the default in October 2025. Oxlint went stable in June 2025 with a demo of Airbnb's 126,000-file repo linting in about seven seconds. Biome 2 pulled off type-aware linting without the TypeScript compiler at all. Node itself strips your types using SWC through the amaro loader, so node file.ts is a Rust program handing bytes to V8. Over in Python, Astral built Ruff and uv into infrastructure the ecosystem now assumes, and OpenAI acquired them in 2026.

The clearest signal is the acquisition on the JavaScript side. In June 2026 Cloudflare bought VoidZero, the company behind Vite, Vitest, Rolldown and Oxc. An infrastructure company bought the JavaScript toolchain, and that toolchain was worth buying because it had been rewritten in a systems language fast enough to make bundling a solved problem rather than a build-time tax. Vite+ went to beta in July 2026, and the interesting thing about it is how little of what it does is JavaScript anymore.

So the honest framing of "should I learn Rust" for a TypeScript engineer is not that Rust is coming for your job. It is that Rust has already taken the layer beneath your job, and the number of people who can debug or extend that layer is much smaller than the number of people affected by it.

The counter-evidence, which is stronger than the hype admits

The single best counter-example is the one nobody in the Rust community enjoys discussing: when Microsoft decided to make the TypeScript compiler ten times faster, they ported it to Go, not Rust. Anders Hejlsberg's reasoning was that the compiler's data structures are heavily cyclic and fight the ownership model, so Rust would have meant a multi-year rewrite producing subtly different semantics, while Go allowed a largely mechanical port in about a year. That decision generalises. The constraint was not performance and it was not safety. It was that single ownership with a borrow checker enforcing it is a poor fit for graph-shaped data that points at itself. The most important tool in the TypeScript ecosystem picked Go at the same moment the rest of that ecosystem was picking Rust, and both were correct for their own reasons.

Rust's own community reports the friction honestly too. The 2025 State of Rust survey put resource usage and compile times at the top of the productivity problem list, async complexity second, the learning curve third. The dedicated compiler performance survey found around 45% of people who stopped using Rust cited compile times among their reasons. That is the main reason people quit.

And memory safety is not the same as security. Check Point found an out-of-bounds access in the Rust GDI region code inside the Windows kernel where the bounds check did exactly what Rust promises, caught the overflow, and panicked, turning potential memory corruption into a kernel-level denial of service. Rust did its job and the outcome was still a blue screen. Google's own post notes a 2025 buffer overflow near their AVIF decoder as evidence that hardened allocators still matter. You are not buying the absence of vulnerabilities, you are trading a class of exploitable corruption bugs for a smaller class of availability bugs. That trade is good, but describe it accurately when you pitch it.

Are you ready, and what does ready even mean

Readiness is not about years of experience, it is about whether you have ever had to care where a value lives. If your mental model of a program is objects that exist somewhere and a garbage collector that deals with it, the borrow checker will feel like an arbitrary bureaucrat for several weeks, and that is exactly where most people bounce off. If you have debugged a memory leak from a retained closure or reasoned about whether a buffer is copied or referenced, you have already done the hard conceptual work and Rust mostly makes that reasoning explicit and checkable.

The practical test is narrower. Can you name a thing you have shipped where the runtime was the problem, rather than the design being the problem? A CLI everyone waits on, a hot request path where you are paying for the garbage collector's opinions, a data transform long enough that people batch it overnight. If nothing comes to mind, you are not blocked on Rust, and learning it will be a hobby. That is a fine reason, just not a career one.

Budget honestly. JetBrains reported in February 2026 that 26% of Rust users use it in professional projects while 52% describe themselves as currently learning it. A lot more people are learning Rust than are being paid for it, and the gap is where the compile-time complaints come from.

Where Rust actually earns it

Rust is worth reaching for when the cost of a runtime is unacceptable and the cost of a rewrite is affordable. That window is narrower than the enthusiasm suggests, and it has a few reliable shapes.

Developer tooling is the obvious one. Linters, bundlers, formatters and package managers are startup-dominated, embarrassingly parallel, and run thousands of times a day per developer, so a 50x improvement compounds into hours of reclaimed attention per engineer per week. That is why Oxc, Biome, Rolldown, Turbopack, Rspack, Ruff and uv all landed in the same few years.

Second is anything at the edge of a machine boundary: proxies, network data planes, per-request middleware, media pipelines, anywhere you multiply a small per-unit cost by an enormous unit count. Cloudflare's halved CPU and memory numbers are the reference case, and what makes them impressive is not raw speed, it is that they removed the runtime's memory floor entirely.

Third is anywhere unsafe code was previously the only option, which is kernel, firmware and driver work, and where the regulatory pressure is aimed. Safety-critical work has quietly become viable rather than aspirational: Ferrocene is a qualified toolchain for automotive and industrial standards, there is a Safety-Critical Rust Consortium at the Rust Foundation, and the project published a guide to shipping Rust in safety-critical contexts in January 2026.

Fourth is WebAssembly, where Rust's lack of a runtime means small modules without shipping a garbage collector to the browser, which is why compute-heavy code that used to be impossible in a web app is now a wasm module with a thin TypeScript wrapper.

Where I would stay in TypeScript, and it is most places

For the majority of the work I do, the constraint is not execution speed.

Product surfaces where requirements change weekly belong in TypeScript, because the cost that dominates there is the cost of changing your mind, and Rust makes changing your mind expensive on purpose. Restructuring who owns what in a Rust codebase is real work in a way that reshaping an interface in TypeScript is not, and that rigidity is a feature when your invariants are settled and a tax when they are not.

Anything I/O-bound belongs in TypeScript too, and this is the one people get wrong most often. If your service spends 95% of its time waiting on Postgres or an upstream API, rewriting it in Rust optimises the 5%, and Amdahl will send you the bill. I have watched people propose Rust rewrites for services whose flame graphs were basically a flat line labelled "waiting". Fix the query.

Anything where the team is the bottleneck belongs in TypeScript. If you have four engineers and one of them knows Rust, a Rust service is a bus-factor-of-one dressed up as an architecture decision. Glue code and the vast surface of a normal web app belong in TypeScript because that is where the ecosystem is, and a language whose libraries you have to write yourself is slower in every dimension that is not execution.

The version I would defend in a design review is that Rust is not a replacement for TypeScript, it is a replacement for the parts of your system where you were about to reach for C, or accept a runtime cost you cannot afford. Cloudflare did not rewrite their dashboard. They rewrote the proxy.

So, is it time

Learning Rust as a bet on the job market is a weak trade. The professional demand is real but concentrated in infrastructure, systems and tooling roles, and a general web engineer picking it up to hedge will spend six months reaching a level of competence they cannot deploy anywhere near their actual work.

Learning it to understand the layer your work now sits on is a much stronger trade, and cheaper than it sounds, because you do not need to be a Rust engineer to read Rust. Opening the Oxc source when your linter does something strange, following a Rolldown issue thread, evaluating whether a proposed rewrite is aimed at a real bottleneck: all of that is reachable in weeks rather than months, and it is the sort of thing that separates a senior engineer from a staff engineer in a technical decision.

What I would not do is treat this as the end of TypeScript, because nothing in the evidence points there. It points at a stack that is stratifying: a systems layer steadily becoming memory-safe under regulatory and security pressure, and a product layer where iteration speed still wins. The interesting career position is not on one side of that line. It is being one of the few people who can see both, and who can tell the difference between a workload that needs a systems language and a slow query someone has not looked at yet.

If you enjoyed this, I write a weekly newsletter for senior engineers thinking about architecture, infrastructure, and the move toward staff and principal roles. You can subscribe here.