Alice Ryhl explains Rust’s strengths in safety, evolution, and systems work

Android as the adoption signal

Alice Ryhl is interesting because she sits right where theory turns into product. She is a core maintainer of Tokio, part of Google’s Android Rust team, and has worked with Rust since 2015. That combination makes her less like a language evangelist and more like a field guide to what Rust looks like once it is asked to shoulder real production pressure.

The story here is not that Rust is elegant on paper. It is that Android, one of the largest software platforms in the world, is treating Rust as part of the answer to a concrete security problem. That is the signal worth watching: Rust is no longer just winning admiration in systems circles, it is winning trust inside an operating system ecosystem that has to care about build times, interoperability, and the cost of change.

Safety without the garbage collector tradeoff

Ryhl’s case for Rust starts with a simple but unusually powerful bargain: memory safety without garbage collection. For systems programmers, that matters because it changes the default failure mode. Instead of letting pointer bugs linger until runtime, Rust pushes a huge class of mistakes into compile-time errors, which is exactly the kind of pressure large codebases need when they are trying to keep reliability from eroding over years of growth.

That same compiler discipline is what makes refactoring feel different in Rust. When code changes ripple through the tree, the compiler acts like a brutally honest assistant, surfacing breakage early instead of letting incompatibilities leak into production. In a platform as sprawling as Android, that is more than a language feature, it is an operational advantage.

Evolution that does not force a flag day

Rust’s edition system is central to why Ryhl’s comments land with so much weight. The Rust project now recognizes four editions, 2015, 2018, 2021, and 2024, and the system exists to let the language introduce backward-incompatible changes without breaking older code unless projects opt into a newer edition. That is a rare kind of promise in systems software: progress without demanding that everyone migrate at once.

The newest edition, Rust 2024, was stabilized in Rust 1.85.0 in February 2025. That matters because it shows Rust still has room to evolve aggressively while preserving the social contract that makes large-scale adoption possible. For teams weighing whether to standardize on Rust, editions are not just a syntax policy, they are a governance tool that makes long-term maintenance less frightening.

What Google’s Android numbers say about the bet

Google has put hard numbers behind the memory-safety argument, and they are the reason Rust keeps showing up in Android planning discussions. In September 2024, Google said memory-safety issues accounted for 76% of Android vulnerabilities in 2019, but only 24% in 2024. It also said that share continues to decline as more new code is written in memory-safe languages.

That same arc shows up in Google’s broader language strategy. In March 2024, Google said it was considering a gradual transition toward memory-safe languages such as Java, Go, and Rust. In February 2024, it emphasized that Rust and C++ interoperability would be a key accelerator, naming tools such as cxx, autocxx, bindgen, cbindgen, diplomat, and crubit. And in December 2023, Google said Rust adoption in Android had grown fast enough that speeding up the Rust toolchain became important for reducing build-time costs.

For Rust practitioners, that cluster of facts is the real lesson. Adoption at this level is never just about choosing a safer language. It is about making the whole stack workable, from interop and compilation speed to the way teams phase in new code without freezing the rest of the system.

The frontier is still rough, especially in the kernel

Ryhl’s perspective also overlaps with one of Rust’s most closely watched experiments: the Linux kernel. Kernel documentation still says Rust support is experimental and that there are currently no in-tree Rust drivers or modules intended for production use. That is a useful reminder that Rust’s momentum is real without being complete.

The work in Rust for Linux is still about building abstractions and infrastructure that can survive kernel-level scrutiny. Miguel Ojeda and others have helped push that effort forward, but the kernel remains a place where the language’s promises have to be earned incrementally. In other words, Rust is not being adopted there because it is fashionable. It is being tested because the costs of memory bugs are high enough that even a partial answer is worth pursuing.

What systems teams can reuse from Android’s playbook

Ryhl’s interview is especially valuable because it makes Rust’s strengths feel less abstract and more actionable. If you are building with Rust, Android’s experience suggests a few practical lessons:

• Use the compiler as a refactoring partner, not just a checker. The payoff is not only fewer bugs, but safer long-term change.

• Treat editions as a migration strategy. They let a language move forward without forcing every codebase to absorb breakage at once.

• Plan for interoperability early. The Google tools named around Rust and C++ show that adoption usually depends on bridges, not clean-room rewrites.

• Measure the operational cost of safety. Google’s build-speed push shows that a secure language still has to fit real build pipelines and developer workflows.

That is why Ryhl matters in this moment. She is talking about Rust from inside both the language world and one of the biggest production platforms on earth, where safety has to coexist with evolution, compatibility, and speed. The Android story does not prove Rust is perfect, but it does show something more useful: Rust is already changing how a massive system decides what is safe enough to ship.