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

There is a specific kind of anxiety that hits senior engineers every few years. 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 a lot of the "any day now" claims finally have dates attached to them.

So this is worth doing properly. Not "is Rust good", which is a boring question with a boring answer, but the two questions that 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 with the note that the experiment is done. Greg Kroah-Hartman's read was that Rust drivers are proving far safer than the C equivalents and that the painful C-to-Rust boundary problems everyone predicted showed up less than expected. The Rust Binder driver landed in 6.18, Android 16 devices on the 6.12 kernel already run a Rust ashmem module, and Dave Airlie has said the graphics subsystem is around a year from refusing new C drivers. That last one is a maintainer's stated intent rather than enacted policy, and it gets misreported constantly, so hold it loosely.

Google published the numbers that make the safety argument concrete rather than theoretical. In November 2025 they reported that memory-safety bugs dropped below 20% of Android's total vulnerabilities for the first time, alongside a memory-safety vulnerability density in Rust roughly a thousand times lower than in their C and C++. The part of that post I find more persuasive 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 not about preventing a hypothetical CVE, it is about the change failure rate of a team that ships.

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, across a rewrite involving more than a hundred engineers and over 130 modules. 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 Microsoft open-sourced Patina, a from-scratch Rust UEFI boot firmware implementation. Firmware. The layer under the operating system.

There is also a regulatory clock running, which is the part most engineers ignore and most staff engineers should not. 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 in June 2025, 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, and anyone telling you Brussels has banned C is selling something. What it does mean is that if you sell software into regulated markets, "why is this in C" has become a question with a paper trail attached, and that changes procurement long before it changes any codebase.

The part that matters if you write TypeScript

Here is the thing that should land hardest for anyone whose day job is JavaScript. 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, which means 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 for development and production back in October 2025. Oxlint went stable in June 2025 with hundreds of ESLint rules and 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 TypeScript 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, with Evan You's team moving into their emerging technology group and a million dollars committed to the Vite ecosystem fund. An infrastructure company bought the JavaScript toolchain, and the reason that toolchain was worth buying is that 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 as a single package wrapping Vite, Vitest, Oxlint, Oxfmt, Rolldown and tsdown, 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, extend or contribute to that layer is much smaller than the number of people affected by it.

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

If the argument were one-sided I would not bother writing it up. It is not.

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 from scratch producing a compiler with subtly different semantics, while Go allowed a largely mechanical port with identical behaviour in about a year. Sit with the shape of that decision, because it generalises. The constraint was not performance and it was not safety. It was that Rust's core idea, single ownership with a borrow checker enforcing it, is a poor fit for graph-shaped data that points at itself, and no amount of enthusiasm changes that. 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, published March 2026, put resource usage and compile times at the top of the productivity problem list, async complexity second, and the learning curve third, with a recurring concern that the language is growing more complex. The dedicated compiler performance survey found around 45% of people who stopped using Rust cited compile times among their reasons. That is not a rounding error. That is the main reason people quit.

And memory safety is not the same as security, which the Check Point research demonstrates nicely. They 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 a 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 acknowledges a related limit, noting 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, and that trade is good, but describe it accurately when you pitch it.

Are you ready, and what does ready even mean

Readiness for Rust 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 most people who bounce off Rust bounce off exactly there. If you have debugged a memory leak from a retained closure, reasoned about whether a buffer is copied or referenced, or thought carefully about the lifetime of something across an async boundary, you have already done the hard conceptual work and Rust is mostly going to make that reasoning explicit and checkable.

The practical readiness test I would use 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 that runs long enough that people batch it overnight. If nothing comes to mind, you are not blocked on Rust, you are blocked on something else, and learning Rust will feel like a hobby because that is what it will be. That is a fine reason to learn it, 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, with roughly 30% having started within the previous month. That ratio tells you something real about the funnel: 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 is a narrower window than the enthusiasm suggests, and it has a few reliable shapes.

Developer tooling is the obvious one, and the one most likely to be relevant to a TypeScript engineer. Linters, bundlers, formatters, parsers 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. The economics there are simply better than anywhere else in the stack.

Anything at the edge of a machine boundary is the second shape: proxies, network data planes, per-request middleware, media pipelines, anything where you multiply a small per-unit cost by an enormous unit count. Cloudflare's halved CPU and memory numbers are the reference case, and the reason they are 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 where the kernel, firmware and driver work sits, and where the regulatory pressure is aimed. Related to that, 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. If you work in automotive, medical or industrial software, this is no longer a research topic.

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

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

I write TypeScript for a living and I am not planning to stop, because 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, and this is the trade-off I see teams misjudge more than any other. And glue code, integration layers and the vast surface of a normal web app belong in TypeScript because they are where the ecosystem is, and because a language whose libraries you have to write yourself is slower in every dimension that is not execution.

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

So, is it time

For most engineers reading this, the useful answer is not yes or no, it is that the question changed shape. Learning Rust as a bet on the job market is a weak trade, because the professional demand is real but concentrated in infrastructure, systems and tooling roles, and a general web engineer picking up Rust to hedge will spend six months to reach a level of competence they cannot deploy anywhere near their actual work.

Learning it because you want to understand the layer your work now sits on is a much stronger trade, and it is cheaper than it sounds, because you do not need to be a Rust engineer to read Rust. Being able to open the Oxc source when your linter does something strange, follow a Rolldown issue thread, or evaluate whether the Rust rewrite someone is proposing is aimed at a real bottleneck, all of that is reachable in weeks rather than months, and it is exactly 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. The evidence points at a stack that is stratifying: a systems layer that is steadily becoming memory-safe under regulatory and security pressure, and a product layer where iteration speed still wins and always will. 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.