I don't write Rust at work. I wrote a post in February about coming to it from TypeScript, and everything in that post is still true, and it is still the case that every line of Rust I've written lives in something nobody but me depends on. Side projects, small tools, a parser I rewrote twice for no reason.
So I am precisely the person this week's news is supposed to land on. Two announcements, three days apart, both of which mean some version of "you can take Rust seriously now." My week did not change at all. I want to argue that this is the correct outcome and not a disappointment.
What actually landed
On 10 September, Victor Ciura, a principal engineer on Microsoft's Rust tooling team, published a guest post on the Rust Foundation blog announcing that Rust now "sits among C++, C#, and TypeScript as one of the best-supported languages for internal development at Microsoft." The substance is not the label. It's rustc_codegen_utc, an alternative codegen backend for rustc that connects the compiler to UTC, the MSVC backend. Same architectural family as rustc_codegen_llvm and rustc_codegen_gcc, plugged into the same interface, pointed at a different place.
The post says it has been production-ready since early 2026, self-hosted since Rust 1.90, and that more than a hundred Microsoft repositories build with it today. The reasons given are ABI compatibility, binary hardening, hotpatch servicing, crash-dump analysis, cross-language inlining and sample profile-guided optimization across the Rust/C++ boundary. That is a list of things nobody gets excited about and every large Windows codebase requires.
Two days earlier, NVIDIA announced CUDA Rust: GPU kernels written in Rust and compiled natively to PTX rather than wrapped around code from somewhere else. Two tracks, matching CUDA's own two models. cutile-rs runs on stable Rust 1.89 and up, is published on crates.io, and is already in HuggingFace's Grout inference engine and in mistral.rs. cuda-oxide, the SIMT track, is early alpha and needs a pinned nightly toolchain. NVIDIA says both are early-stage and neither is production-ready, which is more candour than announcements of this kind usually contain.
Hacker News gave the Microsoft post 518 comments and the NVIDIA post 322. Both showed up on heise's developer feed the same week. The reaction I kept running into, in various tones, was some version of: fine, but whose language is it now?
The unglamorous ending was the goal
I think that question has the story backwards.
Rust's stated ambition, for as long as I've been paying attention, was to replace C and C++ in the places where memory safety failures are expensive. Not to be a nicer place to write a CLI. Not to be a better TypeScript. To go where C++ lives — kernels, drivers, firmware, hypervisors, codecs, GPU kernels — and displace it there.
You cannot do that from the outside. C++ on Windows is not a language, it is a thirty-year accretion of toolchain: an ABI, a debugger format, a servicing pipeline, a compliance process, a set of hardening flags that some security review will ask about. A language that wants to take C++'s place in that environment has exactly two options. It can reimplement all of it in parallel, forever, always a version behind. Or it can plug into the backend that already does it.
Microsoft built the second thing. Read the motivation in their own words and it's an argument about not maintaining two of everything: connecting rustc to UTC lets Rust "build on the same platform investment, with perfect compatibility out of the box, rather than requiring a parallel implementation of every Windows-specific capability."
That is what replacing C++ actually looks like when it stops being a slogan. It looks like a codegen backend and a compliance checklist.
The NVIDIA announcement is the same shape one layer down. The interesting part isn't that Rust reached the GPU — rust-gpu, rust-cuda and CubeCL got there first, and NVIDIA's post says so. It's what the safety argument buys once it's there. Passing a kernel's output buffer in as one of its own inputs doesn't compile:
The same rule that stops me aliasing a Vec in a side project stops a thousand GPU threads racing on the same address. Data races on a GPU are the canonical bug that passes every test and fails in production. The borrow checker didn't get a new feature; it got a new place to apply.
The evidence that it was a real claim
I want to separate two things that get conflated: a language getting popular, and a language's central claim turning out to be true. The second is the one worth caring about, and it has evidence that doesn't come from vendors announcing their own strategy.
Google's Android team has published its numbers annually. The 2025 update reports memory safety vulnerabilities falling below 20% of Android's total for the first time, down from 76% six years earlier. With roughly five million lines of Rust in the platform and one pre-release near-miss found, they estimate a vulnerability density more than a thousand times lower than their C and C++ code. The part I find harder to argue with is the process data: Rust changes have about a 4x lower rollback rate than similarly sized C++ changes, spend roughly 25% less time in code review, and need about 20% fewer revisions.
That's not adoption enthusiasm. That's a memory safety argument surviving contact with a large, old, mixed codebase, and then turning out to be cheaper too. Microsoft building a backend so Rust can meet Windows engineering requirements is a rational response to that, not a capture.
What it changes for me
Nothing, and I think that's the point.
"Tier-1 at Microsoft" is not a fact about my life. It's a fact about Windows engineering, and it's addressed to people whose security review asks whether a binary is hotpatchable. CUDA Rust is addressed to people writing inference kernels. I am neither. My Rust is still a hobby, and the honest version of my position is that I have never had to defend a Rust choice to anyone.
But infrastructure is exactly the thing you stop noticing. Nobody celebrates that their HTTP client speaks TLS. The week a language becomes boring enough that its news is about codegen backends rather than about whether it's ready, it has arrived somewhere. Wanting it to still feel like a movement is wanting it to still be small.
Where I might be wrong
Three places, and the first is the serious one.
Institutional adoption is not the same as institutional support, and the people who maintain Rust are not Microsoft employees. The 2025 State of Rust survey, from 7,156 responses, reports that respondents' biggest ongoing worries are the language growing more complex and support for developers and maintainers — and the survey team closes that section with a direct request to companies using Rust to fund the project and the crate authors they depend on. Adoption at this scale increases the load on unpaid maintainers before it increases their income. I wrote in August that every dependency is a person you have never met, and "won" is a strange word for an outcome where more people depend on the same unfunded volunteers.
Second, "won" is premature on the technical facts I just cited. NVIDIA says plainly that neither project is production-ready and that the SIMT track needs a pinned nightly. A tier-1 designation covering a hundred repositories is real, and it is not the same as Rust being the default at Microsoft, which it is not.
Third, I may be dismissing the ownership question too easily by calling it nostalgia. A codegen backend maintained by one vendor, on which that vendor's internal Rust depends, is leverage — not today, but it's the kind of thing that only looks like leverage in hindsight. My honest answer is that I don't know how to price that risk, and "the alternative was staying small" is a rhetorical move, not an argument. Someone who has shipped Rust in production for five years will have a better sense of it than I do.
Sources
- Guest Post: Rust Is Tier-1 Language at Microsoft — Microsoft's own announcement, 10 September 2026, with the technical detail on
rustc_codegen_utc, its production-ready date, and the hundred-plus repositories currently building with it. - Introducing CUDA Rust: Two Tracks for Writing GPU Kernels — NVIDIA's announcement, 8 September 2026, source of the two tracks, the toolchain requirements, the aliasing compile error, and the explicit statement that neither project is production-ready.
- Rust in Android: move fast and fix things — Google's 2025 Android data: memory safety vulnerabilities below 20%, the vulnerability-density estimate, and the rollback, review-time and revision comparisons against C++.
- 2025 State of Rust Survey Results — 7,156 responses; the source for what the community currently worries about and for the survey team's request that companies fund maintainers.
- Hacker News discussion of the Microsoft post and of the NVIDIA post — where the "whose language is it now" reaction played out, and the reason I think that reaction deserves an answer rather than a dismissal.