AI Summary
5 min readRust distinguishes itself from languages like TypeScript and C by using its type system and compiler to eliminate entire categories of common programming mistakes before code runs. Alice Ryhl, a maintainer of the Tokio async runtime and advisor to the Rust language team, describes how these mechanisms work in practice and why they matter for backend services, command-line tools, and systems code such as the Linux kernel.
Compile-time checks that reduce whole classes of errors
Rust prevents several frequent sources of bugs through its type system. There is no null value that can be forgotten; any value that might be absent must be represented explicitly with an Option type, and the compiler requires the programmer to handle both cases. Error handling follows a similar pattern: functions return Result values rather than throwing exceptions, and the ? operator propagates errors while still forcing explicit attention to failure paths. Exhaustive matching on enums ensures that every possible variant is accounted for, so adding a new case later produces a compiler error until all call sites are updated. These rules extend to documentation: comments written with three slashes become tests that the compiler runs, so outdated examples are caught automatically.
Continue reading the full summary in the app — free to try.
Read Full Summary →Free • No credit card required
What you'll learn
- 1 (01:54) **Guest introduction** - Alice Ryhl joins as Google Android Rust engineer, Tokio maintainer, and Rust language team advisor
- 2 (03:20) **What Tokio is** - Async runtime that acts as the standard library equivalent for concurrent Rust code
- 3 (04:31) **Core appeal of Rust** - "When it compiles, it works" through strong type system and compile-time checks
- 4 (07:03) **Pitch from TypeScript** - Rust as reliable backend language that minimizes production wake-ups
- 5 (12:53) **Pitch from C** - Memory safety eliminates entire class of security vulnerabilities
- 6 (17:22) **No garbage collector** - Manual scope-based cleanup enables low-level uses like kernel and firmware
- 7 (19:04) **Learning curve and data structures** - Newcomers struggle most with designing non-cyclic ownership graphs
+ Full timestamped outline available in the app
Show Notes
Brought to You By:
• Antithesis – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages.
• Sentry – application monitoring software considered “not bad” by millions of developers
• Craft Conference: join Gergely, Kent Beck, Hillel Wayne and others at the conference dedicated to the art and science of software delivery craft.
—
Rust is one of the most admired programming languages around – and also one of the hardest to learn. What makes developers stick with it?
In this episode of The Pragmatic Engineer Podcast, I sit down with Alice Ryhl, a software engineer on Google’s Android Rust team, and a core maintainer of Tokio, which is the most widely-used async runtime in Rust.
We discuss what makes Rust different from other languages like TypeScript, Go, and C++, and why so many developers say that “once it compiles, it works.” We go deep into memory safety, ownership, borrowing, unsafe Rust, and Cargo.
We also cover how Rust is governed by RFCs, feature flags, its six-week release cycle, how engineers get paid to work on the language, and also look into how Rust’s use inside the Linux kernel is progressing.
—
Timestamps
(00:00) Intro
(04:09) Tokio: an overview
(05:11) What Alice likes about Rust
(12:48) Rust for TypeScript engineers
(13:51) Moving from C++ to Rust
(14:34) Memory safety
(18:12) Garbage collection tradeoffs
(21:46) Ownership, references, and borrowing
(26:59) Unsafe in Rust
(31:21) Crates and Cargo
(35:55) Language design and RFCs
(43:02) Building new features
(46:30) Editions vs. versions
(49:47) Getting paid to work on Rust
(51:27) Contributing to Rust
(53:03) Rust in the Linux kernel
(55:45) AI use cases for Rust
(1:01:35) Learning Rust
(1:03:54) Book recommendation
—
The Pragmatic Engineer deepdives relevant for this episode:
• The past and future of modern backend practices
• How Kotlin was built with Andrey Breslav