Category Archives: Rust

Rust Is Tier-1 Language at Microsoft

Posted on by
Reply

I have been following Microsoft’s Rust investment for years, and this week’s update from the Rust Foundation stood out.

Microsoft has classified Rust as a Tier-1 engineering language, placing it alongside C++, C#, and TypeScript for internal development, which means Rust now gets a paved path from local development to production, including secure toolchain builds, developer tooling, and compliance with Microsoft’s Security Development Lifecycle requirements. The centerpiece of this effort is rustc_codegen_utc, a code generation backend for rustc that connects the compiler to MSVC, the native platform compiler for Windows; this places it in the same architectural family as rustc_codegen_llvm and rustc_codegen_cranelift, but it targets the toolchain that Windows and C++ teams already depend on for binary hardening, post-link compliance, hotpatching, and crash-dump analysis.

For engineers who work across hybrid Rust and C++ codebases, this matters because interoperability has historically meant duplicating platform-specific investments for each language separately. With a shared backend, new MSVC features, security capabilities, and diagnostics land on a common foundation, so Rust participates directly in the same engineering lifecycle that C++ has occupied at Microsoft for decades. More than 100 internal repositories already build with rustc_codegen_utc, and the rollout continues weekly, which suggests this is an operational shift in how Windows native software gets built, not a pilot.

The broader signal here is that language interoperability at this scale requires infrastructure investment measured in years, not a single migration project. Teams evaluating Rust adoption on Windows platforms should watch how this backend matures, since it changes the calculus for what a hybrid codebase can achieve without maintaining a parallel toolchain for every platform capability.

Guest Post: Rust Is Tier-1 Language at Microsoft

A Reality Check on Rewriting in Rust

Posted on by

JetBrains published a guest post by the cot.rs maintainers reviewing what actually happened when open source and commercial teams rewrote existing software in Rust, rather than relying on the hype. The findings are more nuanced than the “rewrite it in Rust” slogan suggests, since some performance gains come from Rust specific advantages such as auto vectorization or a concurrency model that makes correct parallel merge sort easier to implement, while other gains come simply from a team rewriting a project from scratch with decades of hindsight and no legacy production constraints. Separating those two causes matters, because a team that attributes a speedup to the language alone may be signing up for a multi year rewrite when a more modest refactor in the existing codebase would have delivered most of the same benefit. (btw, I have ranted here how hard it is to switch to a Rust style of programming)

The failures documented in the post are just as instructive as the wins. Cloudflare shipped an unwrap that took down a request scoring component, sudo-rs echoed a partially typed password back to the terminal after a timeout, and the first CVE in the kernel’s Rust code came from a race condition inside an unsafe block, which is a reminder that memory safety guarantees hold only within the boundaries a team actually enforces. Prisma abandoned its Rust query engine due to skill set gaps and deployment complexity, and Loglog Games left Rust after three years because the language rewarded refactoring more than the fast iteration a game studio needed; both cases show that a rewrite can be technically sound and still fail the organization that undertook it.

This same discipline shows up in Raphael Bauer’s older but still circulating argument for defaulting to PostgreSQL over a specialized database, message queue, or search engine for as long as the workload allows it. The underlying principle in both pieces is the same, even though the technologies are unrelated: reducing the number of moving parts in a system, or the number of languages and services a team must operate, tends to matter more for long term velocity than the theoretical ceiling of any single component. Rust’s own authors reach the same conclusion from the opposite direction, recommending incremental expansion into a codebase rather than a full rewrite, since the projects that succeeded at large scale, such as the Linux kernel and Windows, expanded gradually and kept the surrounding system running throughout.

The broader point for engineering leadership is that technology selection benefits from being evaluated against the operational cost of running it, not against the best case demo of a new tool, and that a decision made for good reasons in 2015 deserves the same scrutiny when reapplied to a system in 2026.

Sources:

  1. https://blog.jetbrains.com/rust/2026/08/10/rewriting-in-rust/
  2. https://www.raphaelbauer.com/posts/postgresql-everything/