Rust in 2026: why big tech is rewriting C++ - and when you should

When I started writing Rust six or seven years ago, people joked that I would have no friends left in programming. The joke had a point. Rust was the language everyone admired in surveys and almost nobody was paid to write. (It still is the most admired: in the 2025 Stack Overflow survey it topped that list for the tenth year running, with 72%.) My own question was more serious than the jokes: would Rust ever be adopted widely? Rewriting legacy software takes enormous time and money, and “the new language is safer” has never been enough on its own to make a company pay for it.

In 2026 that question has an answer. Microsoft, Cloudflare, Meta and GitHub are moving parts of their systems to Rust, and AI has made large migrations more feasible than I imagined back then. I saw the direction early, but I was lucky with the timing. This post is about what changed, what the big migrations actually teach - and how to decide whether any of it applies to your system.

Why I chose Rust - and why the sceptics were right

The case for Rust was clear from the start. It gives you the performance of C and C++ without a garbage collector, and its compiler rules out whole classes of bugs - use-after-free, buffer overflows, data races - before the code ever runs. Those are not exotic bugs. In large C and C++ codebases they are the root cause of most serious security fixes, year after year. A language that removes them at compile time is not a style preference; it is a different cost curve for owning software.

The sceptics were right about the cost, though. A rewrite of a working system is a project with no new features to show for months. The ecosystem was young, the learning curve was real, and hiring was hard. Every CTO I spoke to agreed Rust was better and then, quite rationally, did nothing. Being right about a technology is cheap. Being right about when an industry can afford to adopt it is the hard part.

What changed: Microsoft, Cloudflare, Meta and GitHub

Microsoft has shipped Rust inside the Windows 11 kernel since 2023 - the GDI region code inwin32kbase_rs.sys - and at the end of 2025 Distinguished Engineer Galen Hunt described a goal of eliminating C and C++ from Microsoft’s largest codebases by 2030, using AI and algorithms together - with a north star of “1 engineer, 1 month, 1 million lines of code”. He later clarified that this is a research effort to build migration tooling, not a plan to rewrite Windows overnight. That nuance matters, but so does the direction: the company with one of the largest C++ estates on earth is investing in leaving it.

Cloudflare rebuilt the core proxy that sits in front of millions of websites in Rust. The new system, FL2, made customer sites up to 25% faster and runs on less than half the CPU and memory of the platform it replaced - largely because it no longer shuffles data between layers written in C, Lua and Rust.

Meta made Rust an officially supported server-side language in 2022, has since moved parts of the core messaging library shared by Messenger, Facebook and Instagram from C to Rust, and rewrote WhatsApp’s media-handling library: 160,000 lines of C++ became 90,000 lines of Rust, tests included. In 2026 it also ported the React Compiler to Rust for faster builds. GitHub built its code search engine, Blackbird, from scratch in Rust; it searches almost 45 million repositories.

None of these companies rewrote everything. Every one of them started with the part of the system where the cost of not changing was highest.

That is the real lesson of the big migrations, and it is more useful than the headlines. They are not stories of heroic rewrites. They are stories of targeted ones: a proxy on the hot path, a messaging layer with memory-safety history, a search engine that had to be fast. The same pattern works at any scale - it is the strangler approach we describe in legacy modernisation without the big rewrite, applied to a language change.

AI changed the economics of migration

What I did not foresee in 2019 was AI. The expensive part of a migration used to be the mechanical translation: thousands of functions rewritten by hand, line by line, by engineers who would rather be building something new. Today AI tools do much of that first pass. In our own work they are good at translating self-contained modules, generating the test scaffolding that proves behaviour is unchanged, and explaining old code nobody remembers writing.

They are still weak at the parts that decide whether a migration succeeds: drawing the boundaries between old and new code, designing ownership in a way that does not fight the borrow checker, and reviewing theunsafeblocks where Rust’s guarantees stop. So the cost has moved rather than disappeared - from typing to judgement. That shift is exactly what turns a migration from a multi-year bet into a series of projects of a few weeks each, each one paying for itself.

Should you migrate to Rust? A framework for deciding

For most companies the honest answer is “some of it, eventually”. Go through your system module by module and sort each one into one of two columns.

Then migrate the top of the first column one module at a time. Put the new Rust code behind the same interface the old code had - a C ABI through FFI, or a separate service - run both side by side, and switch traffic only when the tests and production metrics agree. If a module does not pay back, stop there; you have lost weeks, not a year. And if the case for Rust rests only on the fact that it is popular, that is not a case. The same discipline applies to any technology choice, which is why we wrote about boring technology as a luxury good. Ten years after 1.0, Rust has quietly become one of those boring choices.

The lesson: don’t follow the hype

If there is one thing seven years of Rust taught me, it is this: don’t follow the hype - think about the problems the industry will need to solve years from now. Memory safety, energy and cloud cost, systems that have to be maintained for decades by teams that keep changing: those problems were visible in 2019 and they are only bigger now. The technology that solves them was always going to win; the only question was when it would become affordable.

The same question is worth asking about your own roadmap. Which problem in your system will be expensive in five years - and what would it cost to start on it now, one module at a time?

Frequently asked questions

And yes, I made some Rust friends along the way. A little late, but they got here. If you are weighing a migration, here is how we approach Rust development and C/C++ migration.