Microsoft Just Quietly Made Rust a First-Class Citizen
In this article
Bottom line: Microsoft has expanded its approved use of Rust for new systems code across Windows, Azure, and its security-critical infrastructure, moving it toward the same standing historically reserved for C and C++.
The shift follows Microsoft's own admission that roughly 70% of the CVEs it patches each year trace back to memory-safety bugs, the exact class of bug Rust's borrow checker eliminates at compile time.
Windows components like DWM, GDI, and parts of the kernel's font and graphics stack have already been rewritten or are being rewritten in Rust.
If you're still telling junior engineers that "Rust is a niche language for people who like fighting the compiler," you're about three years behind the company that ships the world's most-attacked operating system.
Stop telling people Rust is a hobbyist language for people who enjoy pain. I'm serious.
The same industry that spent a decade mocking Rust evangelists as compiler-fetishists just watched Microsoft — a company with a massive engineering organization touching Windows and Azure — put Rust on equal internal footing with C++.
I've spent twelve years writing systems code, half of it in C++, and I'm telling you: the people who told you Rust was overhyped were wrong, and now there's a paper trail proving it.
The Sacred Cow: "C++ Is Just What You Use for Systems Work"
For thirty years, the pitch was simple. If you wanted to write an operating system kernel, a browser engine, a database storage layer, or a graphics driver, you reached for C or C++.
Everyone agreed on this so thoroughly that it stopped being a decision and became a reflex.
I get why. C++ has decades of tooling, a library ecosystem the size of a small country, and generations of engineers who've internalized its footguns well enough to mostly avoid them.
"Mostly" is doing an enormous amount of work in that sentence, and we'll get to why in a second.
Five years ago, dismissing Rust as academic overkill was a defensible position.
The tooling was rougher, the ecosystem thinner, and the learning curve genuinely brutal — ask anyone who's spent a weekend arguing with the borrow checker over a doubly linked list.
The conventional wisdom wasn't stupid. It was just built for a world that's already gone.
The Evidence: Microsoft's Own Numbers Convicted C++
Here's the part where I stop asserting things and start showing you receipts.
The 70% Admission
Microsoft's own security engineers — most visibly Matt Miller of MSRC, who presented the figure at BlueHat IL 2019, and later reinforced publicly by Mark Russinovich, Azure's CTO — have stated for years that approximately 70% of the CVEs Microsoft assigns each year trace back to memory-safety issues: use-after-free, buffer overflows, null pointer dereferences, the greatest hits of C++ undefined behavior.
That's not a Rust marketing slide. That's Microsoft's own security telemetry, presented at their own conferences, about their own code.
When the company that ships the most widely deployed operating system on Earth tells you seven out of ten of its own security holes come from one specific, well-understood, and solvable category of bug, that's not an opinion.
That's an audit result.
The Kernel Rewrites Aren't Symbolic Anymore
Windows has been shipping Rust in production components for a few years now — GDI's font rasterization path, portions of the kernel's DirectX graphics kernel subsystem, and chunks of the Windows Cloud Files driver have all seen Rust replace C or C++ code.
These aren't toy modules.
These are components that parse untrusted, attacker-controlled input at the kernel level, which is precisely the environment where a single missed bounds check turns into a remote code execution CVE with your name on the advisory.
This mirrors a pattern you're seeing across the industry — WhatsApp rewrote its media handler in Rust and cut tens of thousands of lines of C++ in the process, for the same reason: media parsers sit directly in the blast radius of untrusted data, and that's exactly where memory-safety bugs turn into headlines.
The Org-Chart Tell
Watch what companies fund, not what they say.
Microsoft is a Platinum member of the Rust Foundation, has multiple full-time engineers contributing upstream to rust-analyzer and the compiler itself, and shipped the `windows-rs` crate as an officially maintained, first-party binding to the entire Win32 and COM API surface — not a community side project, an actual Microsoft-owned repository under active internal use.
You don't put full-time headcount on a language's tooling because it's a fun experiment. You put headcount on it because it's now load-bearing infrastructure.
The Real Problem Nobody Talks About
Here's the uncomfortable part, and it's not really about Rust.
The real problem is that the systems programming industry spent thirty years treating memory-unsafety as a skill issue instead of a tooling issue.
Every time a CVE dropped, the response was "the engineer should have been more careful," never "the language made it structurally easy to make this mistake and nearly impossible to catch it before shipping."
That framing wasn't neutral. It was convenient.
It let organizations avoid the much harder conversation about rewriting decades of C++ infrastructure, and it let a certain kind of senior engineer feel superior for having "mastered" a language that was, in retrospect, quietly costing their employer a CVE a month.
Microsoft didn't move to Rust because Rust is trendy.
They moved because the actuarial math on memory-safety bugs finally became impossible to ignore at their scale. When you ship an OS to a billion-plus devices, a 70% reduction in one entire bug class isn't a nice-to-have.
It's the highest-leverage security investment available, full stop, more effective than almost any amount of additional code review or static analysis layered on top of C++.
That's the part that should actually worry C++ shops: this wasn't a language preference. It was a cost-benefit analysis, and C++ lost.
What You Should Actually Do Instead
I'm not telling you to rewrite your production C++ codebase this quarter. That's how you get fired and also how you introduce a hundred new bugs faster than you fixed the old ones.
Here's what actually works, based on what Microsoft and companies like Google and AWS have done successfully:
- New code goes in Rust, old code stays put. Microsoft isn't rewriting all of Windows. They're writing new subsystems in Rust and leaving stable C++ alone unless there's a security or maintenance reason to touch it. That's the boring, correct strategy.
- Target the components that parse untrusted input first. Parsers, codecs, network protocol handlers, file format readers — these are where memory-safety bugs actually become exploitable. Prioritize there before touching your stable internal business logic.
- Invest in interop, not evangelism. The `windows-rs` and `cxx` crates exist because Rust-C++ interop is the actual bottleneck, not developer willingness. Learn the FFI boundary before you write a single line of "greenfield" Rust.
- Budget for the learning curve honestly. Your team will be slower for two to three months. Every team that's done this successfully — Microsoft, Discord, Cloudflare — budgeted for that dip instead of pretending it wouldn't happen.
None of this requires you to become a Rust zealot.
It requires you to read Microsoft's CVE data and ask why your org is still writing greenfield parsers in a language where a single off-by-one still compiles clean and ships to production.
The Uncomfortable Truth
For years, "just be more careful" was an acceptable answer to memory-safety bugs, because the alternative — actually changing languages — felt too expensive to seriously consider.
Microsoft just showed the industry the real cost comparison, and it wasn't close.
How many CVEs does your team need to ship before "we've always used C++" stops being a strategy and starts being an excuse?
What's the actual technical decision at your company that everyone defends out of habit instead of evidence?
