Google and Microsoft are adopting Rust for selected low-level software because it offers fine-grained control and systems-level performance while preventing many memory-safety errors in safe Rust. Neither company says it is replacing all existing C and C++ software: Google describes gradual adoption alongside hardening legacy code, and Microsoft says Rust is already used in some critical Azure infrastructure.
Why choose Rust for low-level software?
Systems software often needs direct control over memory and predictable performance. C and C++ provide that control, but mistakes such as out-of-bounds access and use-after-free can lead to memory-corruption vulnerabilities. Microsoft’s Security Response Center (MSRC) argued in 2019 that safe Rust can provide C/C++-like performance and control while making many such errors impossible to express unless code explicitly opts into unsafe.
That distinction matters: Rust’s advantage is not that it eliminates every security problem, but that its safe subset shifts many memory-safety checks into the language and compiler. MSRC estimated that roughly 70% of the security issues it assigned CVEs were memory-safety issues. That was Microsoft’s estimate in 2019—not a current measurement or a universal share of all vulnerabilities. Microsoft MSRC’s 2019 discussion also acknowledged that unsafe Rust, C++ interoperability, and compatibility with existing tools require careful engineering.
How Google is reducing memory-safety risk
New development and existing code
Google’s October 2024 strategy is gradual rather than a wholesale rewrite. The company aims to use memory-safe languages for new development and expand Rust across server, application, and embedded environments. It expects some mature, stable C++ code to remain for the foreseeable future, while improving the safety of existing C/C++ through hardening and exploit mitigations. In Android, Google said Rust was already used in parts of the network, firmware, and graphics stacks.
#1 Best Overall
Google reported that Android memory-safety vulnerabilities fell from more than 220 in 2019 to a projected 36 by the end of 2024. Those are Google’s reported count and projection; they are not an independently audited measure, and Google did not attribute the entire reduction to Rust alone. The company describes memory-safe languages as one part of a broader security strategy. Google’s October 2024 strategy explains that combined approach.
Rust in Android development
Google’s later Android engineering account describes Rust support in the Linux 6.12 kernel, a first production Rust driver, firmware work, Rust code in security-critical apps, and Rust-based parsers in Chromium. It also reports internal workflow comparisons for Android platform changes: similarly sized Rust changes had about 20% fewer revisions and about 25% less code-review time than C++ changes. For medium and large changes, Google reported an approximately four-times-lower rollback rate for Rust.
Rank #2
These figures come from Google’s first-party Android platform developers and comparisons covering 2023–2025, as described in its 2025/2026 post. They are company-reported workflow metrics, not independent trials or guarantees for other teams; Google also acknowledges the difficulty of cross-language comparisons. Google’s Android Rust account provides the scope and context.
A modem-firmware example
In April 2026, Google described integrating a Rust DNS parser into Pixel 10 modem firmware. The team selected the open-source hickory-proto crate, which Google said had more than 75% test coverage, and added no_std support for the bare-metal environment. Google’s rationale was specific: modem firmware has a significant remote attack surface, and DNS parsing processes untrusted input. Memory-safe parsing can reduce the chance that a memory-corruption bug in this component becomes an entry point, but does not establish that the modem or phone is immune to other vulnerabilities. Google’s Pixel 10 modem post describes the implementation.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallRank #3
What Microsoft is doing with Rust
Systems programming and Azure
Microsoft’s argument for Rust centers on workloads that need speed and low-level control without accepting the same exposure to memory errors in safe code. The company has also said it is using Rust in production: Jeffrey Cooperstein, Partner Software Architect, Azure Security, wrote in a 2023 Azure post, “While we are not able to rewrite everything in Rust overnight, we’ve already adopted Rust in some of the most critical components of Azure’s infrastructure.” That statement establishes use in some Azure components, not a migration of Azure as a whole. Microsoft’s Azure post gives the adoption context.
Support for the Rust ecosystem
Microsoft said it donated USD 1 million to the Rust Foundation in December 2023 and described support for Alpha-Omega open-source security work in a March 2024 post. That funding supports the broader security and language ecosystem; it is not evidence that a particular Windows or Azure product was rewritten. Microsoft’s 2024 security initiative post describes the contribution.
Is Rust safer than C++—and what does that guarantee?
For memory safety, safe Rust provides a meaningful language-level advantage: it prevents many classes of memory misuse without relying solely on developer discipline. MSRC described safe Rust this way in 2019: “Unless explicitly opted-out of through usage of the “unsafe” keyword, Rust is completely memory safe, meaning that the issues we illustrated in the previous post are impossible to express.” The qualification is essential. Rust allows explicitly marked unsafe code, and systems projects may need it for low-level operations or interoperability; that code needs appropriate review and controls.
Memory safety is one security property, not a blanket security guarantee. Rust does not by itself prevent logic errors, insecure design, authorization mistakes, or every other vulnerability class. Google’s approach—adding Rust where it fits while hardening and mitigating risk in existing code—reflects that boundary.
Are Google and Microsoft rewriting Android or Windows in Rust?
No. Google describes adding Rust to selected Android components and choosing memory-safe languages for new development, not replacing all Android C/C++ code. Microsoft has described Rust use in some critical Azure infrastructure and argued for its use in systems programming, but the cited statements do not claim that Windows or all of Azure is being rewritten. Both companies recognize that mature code, compatibility requirements, and migration effort make wholesale replacement impractical.
What are the trade-offs of adopting Rust in established codebases?
Introducing Rust into a large C/C++ project is an engineering migration, not a drop-in switch. Microsoft has identified interoperability with C++, unsafe-code governance, and existing-tool compatibility as challenges. Teams also need the skills and review practices to maintain Rust alongside legacy languages. Google’s plan to add Rust to new or suitable components while hardening stable older code avoids treating a rewrite as the only route to lower risk.
Quick Recap
- Where Rust fits: new components and security-sensitive parsers or drivers that need low-level control.
- What remains necessary: careful review of unsafe code, secure design, testing, and defenses for legacy C/C++.
- What the reported results show: company-specific deployments and internal metrics, not a universal performance or security guarantee for every organization.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
