Why Rust is different, with Alice Ryhl

The Pragmatic Engineer (Gergely Orosz, host) · email · 2026 Reader 🖥️

Code Quality Feedback Loops Rust (Programming Language)Software Design Fundamentals Test-Driven Development

Rust earns its growing adoption not by adding features but by systematically engineering away whole classes of programmer mistakes — null, uninitialized memory, unhandled errors, stale documentation, memory-unsafety, non-exhaustive matches — through a type system, ownership/borrow checker, and a governance and tooling culture (RFCs, editions, Cargo, doc-tests) that treats reliability as a composite property rather than a single feature.

practical · mixed — A practical podcast conversation — its load-bearing claim is 'you should consider Rust for reliability/performance-critical code.' Form is mixed: expository explanations of language mechanics interleave with argumentative pitches (vs TypeScript, vs C++), narrative anecdotes (Minecraft origin, Linus on Cargo, kernel maintainer summit), and meta-discussion of how the Rust project governs itself.

Structure

Part	Role
Origin and personal entry into Rust (Minecraft, Rust Users Forum, Tokio maintainer)	context — establishes guest credibility and frames the conversation as practitioner-led rather than vendor pitch
The 'when it compiles, it works' pitch and comparison to TypeScript	central argument for Rust as a backend reliability language
Pitch from C++: memory safety as elimination of a security-vulnerability class	stronger variant of the reliability argument, with explicit threat-model framing (root via UID overwrite)
Mechanics: ownership, references, borrow checker, Arc, unsafe	expository — explains how the reliability guarantees are actually produced
Ecosystem: Cargo, crates, maturity by domain (backend yes, frontend no)	evidence for adoption and developer experience
Governance: teams without a BDFL, RFC process, FCP, editions	argument that Rust's institutional design is also reliability-oriented (backwards-compat guarantee, structured deliberation)
Rust in the Linux kernel — no longer experimental as of Dec 2025	external validation / milestone narrative
AI and Rust: compiler feedback as a leash for agents, AI for kernel code review	speculative extension — Rust's structural feedback loops may suit AI-assisted development
Learning Rust: the Rust Book, Rustlings, building a project	closing practical recommendations

Key terms

memory safety
A guarantee that, absent the use of `unsafe`, no program — however badly written — can exhibit the class of bugs (use-after-free, out-of-bounds reads, double-free, data races on memory) that typically become security vulnerabilities.
ownership
Each value has exactly one owner; assignment moves ownership and invalidates the previous binding, so destructors run exactly once at end of scope without a garbage collector.
borrow checker Rust (Programming Language)
Compile-time analysis ensuring that references (borrows) do not outlive their referent and that mutable and shared borrows do not overlap — one writer xor any number of readers, scoped per function.
unsafe
An escape hatch that unlocks a small set of additional operations (raw pointer deref, calling `unsafe fn`); it does NOT disable the borrow checker, and is intended to be wrapped in a safe API whose internal invariants the author has hand-verified.
edition
A per-crate opt-in language version (2015, 2018, 2021, 2024, ...) that permits breaking syntactic or semantic changes while preserving interoperability across editions in the same build.
RFC / FCP / ACP / MCP
A graded set of decision-making artifacts: RFC for large language changes (motivation, guide-level explanation, reference-level explanation, rationale, alternatives, prior art, future possibilities); FCP (Final Comment Period) is the team's voting protocol with a two-week timer; ACP is the lighter library-API change proposal; MCP is the compiler team's 'major change proposal.'
Tokio
The de facto async runtime for Rust; analogous to the JavaScript event loop but multi-threaded — a queue of tasks scheduled across multiple worker threads.
Cargo / crate
Cargo is Rust's unified tool for build, test, dependency fetch, doc generation, and benchmarking; a crate is a package; dependencies are local to a project (no global install).
doc-test Test-Driven Development
Code examples written inside `///` documentation comments are automatically compiled and run as tests; if the underlying code changes incompatibly, the documentation example fails the build.
match / exhaustiveness
Rust's `switch` analogue requires every enum variant to be handled (or an explicit catch-all); adding a new variant later forces the compiler to flag every site needing update.
Result and `?`
Errors are returned as values via the `Result` enum; the `?` operator propagates errors explicitly; forgetting to handle a Result is a compile error.
in-place initialization
The ability to construct a value at a known final memory address so it cannot be moved afterward — needed by the Linux kernel and a current work-in-progress language feature Alice is championing.

Propositions

explicitcorroboratedRust's distinctive value is the combination — memory safety, no GC, low-level usability, type system, exhaustive matching, explicit errors — rather than any single feature.conf: high
refines ←Presentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase · p6 — Where the Rust/Alice Ryhl doc frames Rust's advantage as a compound feature-set (memory safety + no GC + type system etc.), this talk narrows the practical adoption question to a specific, scoped decision procedure: which source language and which functions are actually worth touching.
supports ←AI-Enabled Security Researchers Discover How a Crafted Video Can Provide Attackers Access to Your PC · p11 — Names what a memory-safe migration would actually buy — Rust's composite of memory safety, no GC, and a type system that catches these classes of bugs — context this article's brief closing mention gestures at but doesn't spell out.
explicitWhen Rust code compiles, it works — in a strong-enough sense to change how engineers approach refactoring (drive the compiler errors to zero and you have updated every call site).conf: high
explicitMost small mistakes in C/C++ are not just bugs but security vulnerabilities; Rust eliminates that class entirely outside of `unsafe`.conf: high
explicitdevelopedRust's hardest learning curve is data-structure design, not syntax — the borrow checker forces tree-or-DAG shapes and rejects naive cyclic graphs.conf: high
extends ←Cloudflare Cuts 100 TB of Memory from 1.1.1.1 DNS Cache · p5 — Cloudflare's concrete enum-boxing/locality tradeoff is a production instance of the data-structure-design difficulty Alice Ryhl describes as Rust's real learning curve (the borrow checker and allocation model pushing problems back into struct/enum design).
explicitFighting the borrow checker is usually a signal to redesign the struct, not the function — i.e. the language pushes problems back into design.conf: high
explicit`unsafe` does not disable safety; it grants a small additional set of operations whose preconditions the programmer assumes responsibility for, ideally wrapped in a safe API.conf: high
explicitDocumentation drifts because nothing enforces it; making examples into tests is the first credible solution to a decade-old industry problem.conf: high
explicitRust governs without a benevolent dictator — language change requires team sign-off via RFC + Final Comment Period, with concerns acting as veto-pauses.conf: high
explicitEditions let Rust make breaking syntactic/semantic changes without breaking the ecosystem because crates of different editions interoperate inside one build.conf: high
explicitcorroboratedRust is now a category — 'reliable AND performant' — that previously did not exist as a single language choice.conf: high
supports ←Cloudflare Cuts 100 TB of Memory from 1.1.1.1 DNS Cache · p6 — Cloudflare's measured throughput/latency/footprint wins are concrete evidence for Ryhl's claim that Rust now occupies a 'reliable AND performant' category previously unavailable as a single language choice.
explicitcorroboratedRust may be unusually well-suited to AI-assisted coding because the compiler's rich feedback gives agents an objective, automatable corrector.conf: medium
supports ←Harness engineering for coding agent users · p10 — Both claim rich type-system/compiler feedback is what makes a codebase correctable by agents — Böckeler's 'harnessability' names the property Ryhl attributes to Rust.
implicitReliability is not one property but a composite (memory safety + explicit errors + exhaustive match + null-freedom + initialized-before-use + checked deserialization + doc-tests + ...).conf: high
implicitThe economic case for Rust is the cost of incidents, not the cost of typing — 'waking up at night' is the unit of value Alice anchors to.conf: high
implicitRust's design philosophy is empirical-corrective: look at recurring failure modes across languages, then make each one a compile-time error.conf: high
implicitAdopting Rust requires an organizational shift in where 'design effort' is spent — upstream into types and data structures rather than downstream into runtime defense and incident response.conf: high
implicitCargo's centralized fetch-and-run model imports the npm-style supply-chain risk that Linus rejects, but the Rust community has not yet shown it can handle that risk better than npm has.conf: medium
implicitBackwards compatibility is treated as a near-sacred constraint — strong enough to drive the invention of editions rather than allow a Python-2-to-3 break.conf: high
implicitGovernance without a BDFL is only viable because the language's design ethic (exhaustiveness, explicit failure, concern-as-pause) is already replicated in the process — i.e. the RFC template is the language's design ethic applied to itself.conf: medium
explicitRust is unsuitable for the frontend; the WebAssembly path has not closed the gap with TypeScript.conf: high

Arguments

You should choose Rust for any backend or systems context where the cost of a production incident exceeds the cost of slower initial development. strength: high

Explicit premises:

Rust eliminates null-dereference bugs (Hoare's billion-dollar mistake) at compile time.
Rust forces explicit error handling via Result and `?`; forgetting to handle is a compile error.
Rust eliminates the memory-safety bug class outside `unsafe`.
Doc-tests prevent documentation rot.
Exhaustive `match` prevents missed-case bugs across refactors.

Implicit premises:

The marginal cost of more typing and tighter compiler discipline is small compared to the marginal cost of waking up at night.
Most production bugs in conventional backend stacks are exactly the bug-classes Rust eliminates.
Engineers and organizations can absorb the borrow-checker learning curve within a reasonable horizon.
Reliability compounds: each eliminated bug class disproportionately reduces total incident load.

Inferences:

Organizations whose dominant incident costs are NOT memory/null/error-handling bugs (e.g. logic bugs, integration bugs, ML/ops bugs) will see a smaller Rust ROI.
If LLM-assisted coding becomes dominant, Rust's compile-time check surface becomes a key part of the agent feedback loop, increasing its value further.

Rust's true learning friction is not syntax but the obligation to design data structures up-front. strength: high

Explicit premises:

Cyclic references are rejected by default; the borrow checker assumes tree/DAG ownership.
Newcomers typically respond to compiler errors by editing code rather than restructuring data.
Most fights with the borrow checker dissolve once the struct is redesigned (often via Arc/Rc, lifetimes, or message-passing).

Implicit premises:

Many widely-taught design idioms (parent-pointer trees, observer patterns, shared-mutable graphs) are anti-patterns Rust forces you to recognize as such.
Engineers from GC languages have not been required to think about ownership topology and therefore have not developed the muscle.
Investing in up-front design pays for itself in eliminated runtime bugs — but only if the engineer treats compiler errors as design feedback, not noise.

Inferences:

Rust adoption succeeds in organizations that can sustain a design-heavy onboarding period and fails in organizations that demand immediate feature velocity from new hires.
Rust may be a forcing function for the very 'first principles' design thinking Kjetil values — types and data structures as the locus of design effort.

Rust's growing popularity is best explained by it occupying a previously-empty category (reliable + performant + low-level usable) rather than by any single innovation. strength: high

Explicit premises:

It does not have a garbage collector and is usable in low-level contexts (kernel, firmware).
It provides higher reliability guarantees than typical GC-ed backend languages.
It is now in the Linux kernel (no longer experimental as of Dec 2025) and being considered for Git, CPython, QEMU.

Implicit premises:

Before Rust, choosing 'reliable' meant accepting GC and higher latency, and choosing 'performant + low-level' meant accepting C/C++ memory-unsafety.
There is a real, latent market for software that is BOTH — driven by post-Snowden, post-CrowdStrike, regulator-pressured threat models.
Categories beat features: language adoption is dominated by 'what kind of language is this?' not 'what features does it have?'

Inferences:

Languages that try to compete with Rust on individual features (Go on ergonomics, C++ on perf, Zig on simplicity) will not be sufficient if the category requirement is the conjunction.
Government memory-safety mandates (US DoD and others Alice alludes to) act as a one-way ratchet for Rust adoption in regulated domains.

Rust's governance is part of its product — the RFC + FCP + editions machinery is a deliberate replication of the language's design ethic at the organizational level. strength: medium

Explicit premises:

Decisions require team sign-off; no BDFL.
RFCs require motivation, guide-level explanation, reference-level explanation, rationale, alternatives, prior art, future possibilities.
FCPs grant any team member a 'concern' that pauses the timer indefinitely.
Editions allow breaking changes without breaking existing code.

Implicit premises:

The same exhaustive-case discipline that prevents bugs in code prevents irreversible design mistakes in the language.
Backwards compatibility is treated as a property to engineer for, not a constraint to lament — so the institution invents new mechanisms (editions) rather than break users.
A language ecosystem's reliability is bounded by the reliability of its decision-making process.

Inferences:

Communities adopting Rust inherit not just a technology but a governance template — one well-suited to teams who already prize structured deliberation.
This template is plausibly transferrable to other long-lived shared codebases that need to evolve without breaking downstream consumers.

Rust + LLM-agent coding may be uniquely complementary because the compiler is the most legible, automatable feedback channel available to an agent. strength: low

Explicit premises:

Alice refactors by 'fixing what the compiler says' — the same loop an agent can run.
AI bots at the Linux maintainer summit produced 'really impressive' kernel reviews.
Alice used an agent to write a benchmark she would otherwise have skipped.

Implicit premises:

Agents are most reliable when their environment provides cheap, deterministic, high-resolution feedback (tests + compiler + linters).
In dynamic languages, the agent must rely on tests it writes itself; in Rust, the type system supplies an enormous bank of free 'tests' before any test is written.
Therefore the productivity ceiling for agentic coding rises faster in strongly-typed, exhaustively-checked languages than in dynamic ones.

Inferences:

If true, Rust adoption may accelerate beyond what reliability-arguments alone predict, because organizations that AI-codify will rationally prefer the language with the best agent leash.
Conversely, this argues against Rust's frontend exclusion: if WebAssembly + Rust gets a good agent loop, the frontend story could flip in a few years.

Narratives

Alice got into programming by trying to write a Minecraft mod, which led her to Java; she then spent years on the Rust Users Forum (10,000+ posts answering questions), drifted into the Tokio Discord, started fixing documentation on questions she answered, and became a Tokio maintainer.
→ Implicit argument that Rust's community-as-curriculum (forum + fixing-docs-as-you-learn) is a productive pipeline; also normalizes the long onboarding curve.
The kernel exploit pattern: an attacker frees an object, the slab reuses that memory for a task_struct (a process descriptor), then zeros are written to memory — including the UID field — and the attacker is now root.
→ Concretizes the abstract claim 'memory safety bugs are usually security vulnerabilities'; turns 'reliability' into a specific, frightening cost-of-incident image.
At a Linux Plumbers Conference social event, Linus showed up only at the very end. Alice introduced herself as a Rust contributor, and Linus immediately told her he dislikes Cargo because it downloads code from the internet and runs it — and he refuses to trust any package manager other than his distribution's.
→ Implicit critique of the npm-style supply-chain risk model that Rust has inherited; foreshadows the segment on package vulnerabilities; also signals the cultural distance Rust had to cross to enter the kernel.
Year over year at Linux Plumbers Conference, Rust's status shifted: 'oh that's a nice little thing you have there' became 'we have Rust code in our subsystem' became, in December 2025 at the kernel maintainer summit, 'Rust is no longer experimental in the kernel.'
→ External-validation narrative for the unity claim; supports the proposition that Rust is winning on reliability merit in a notoriously conservative community.
Alice had a binder commit that needed a benchmark; instead of writing one she asked an AI agent, which found an existing benchmark, modified it cleverly, ran it, and wrote a Python script to analyze the output and produce a table.
→ Supports the claim that agents complement Rust development by automating undesired side-work; also makes the implicit point that without the agent, the benchmark might not have been done at all — i.e. agents lift the floor of engineering rigor.
Alice asked an agent to add Rust flags to a kernel makefile; it added them to the Rust side but silently ignored a set of flags being passed on the C side 'for a reason.'
→ Counter-anecdote: agents lack the 'why are these flags here?' meta-reasoning, which is exactly the kind of design-level judgment Rust pushes humans toward.
Refactoring story: 'I just fix the compiler errors until the compiler stops shouting. Once I've done that, I've updated every place I need to update.'
→ Concretizes the 'when it compiles, it works' thesis; the same loop is then offered as the mechanism by which agents might productively use Rust.

Questions addressed

✅ Why is Rust different from other modern languages?
Because it systematically engineers out recurring failure modes at compile time and combines that with no-GC low-level usability — a previously-empty category.
✅ What is the pitch for Rust if I write TypeScript today?
Use it for backend reliability: no null, explicit errors, exhaustive match, initialized-before-use, doc-tests, checked deserialization via Serde.
✅ What is the pitch for Rust if I write C++ today?
Memory safety eliminates the dominant class of security vulnerabilities; unsafe is an opt-in scalpel, not the default knife.
✅ What trips up newcomers, and what makes Rust click?
Newcomers fight the borrow checker by editing functions; it clicks when they accept that the answer is usually to redesign the struct.
✅ How does Rust govern itself without a BDFL?
Through team sign-off, RFCs with a strict template, FCPs with concern-as-veto, and editions that decouple change from break.
✅ Where is the Rust ecosystem mature vs immature?
Mature: backend, CLI, embedded, kernel. Immature: frontend (WebAssembly path has not closed the gap).
⭕ Is Cargo's centralized supply-chain model a liability?
Alice concedes it's 'a hard problem,' admits an Alice-key compromise could ship a malicious Tokio, and offers no concrete defense beyond 'we've had fewer problems than npm.'
⭕ Does Rust complement AI-assisted coding?
Gergely floats the hypothesis; Alice agrees in principle and offers anecdotes (Linus-praised review bots, her own benchmark) but the question is not closed.
⭕ What is the right ratio of company-paid Rust work vs volunteer work, and how does that compare to Linux?
Alice says Rust is doing 'pretty well' but is nowhere near Linux's ~80% corporate-paid contributor ratio. The implications for long-term sustainability are not discussed.
⭕ What categories of bug does Rust NOT prevent?
Implied by 'when it compiles it works ... has to be in quotes' but never enumerated. Logic bugs, integration bugs, distributed-systems bugs, mis-modeled domains — none discussed.

Gaps

incompleteNo honest accounting of Rust's cost side: longer compile times, larger binaries, slower greenfield velocity, hiring scarcity, training cost. The pitch is one-sided ('reliability good, what's not to like?') and the listener gets no calibration for when Rust would be the wrong choice.
Read next: Pair with practitioner postmortems on Rust adoption: Discord's switch from Go to Rust (and where they kept Go), Cloudflare on Pingora migration costs, Microsoft Azure's Rust adoption metrics, or any 'we tried Rust and went back' essay.
closed byPresentation: Accelerating Performance by Incrementally Integrating Rust Into Existing Codebase — That gap flags the Rust/Alice-Ryhl conversation's one-sided pitch and its missing honest cost accounting for adopting Rust. This talk supplies exactly that from a practitioner doing a real (if smaller-scope) Rust adoption: named, concrete costs — deployment complexity from shipping native binaries, developer-environment complexity (compilers or matched binaries per dev machine, or maintaining duplicate implementations), and residual bug risk — plus a worked example where the rewrite's output didn't match the original. It is not the requested postmortem-with-metrics (no hiring/training/compile-time data), but it is the honest, non-hype-driven cost accounting the other extraction found missing.
incompleteThe category of bug Rust does NOT prevent is left implicit. Logic bugs, mis-modeled domains, distributed-systems race conditions across services, mis-handled business invariants — these are arguably the dominant cost in modern backends, and Rust's compile-time machinery does not touch them. Yet the conversation rhetorically positions Rust as 'reliable' full stop.
Read next: Read Hillel Wayne on formal methods and where types stop helping; Rich Hickey 'Simple Made Easy' on complexity that types don't catch; recent work on property-based testing (Hegel/Hypothesis — sponsor of this very episode, interestingly).
incompleteThe organizational shift Rust demands is gestured at ('change the struct, not the code') but never made explicit. Adopting Rust seriously means moving design effort upstream — into types and ownership topology — which has real implications for who designs, when, and how PRs are reviewed. The conversation treats this as a personal learning curve when it is plausibly a team-process redesign.
Read next: Read Kent Beck on where in the design timeline to invest effort (Tidy First?), Yourdon & Constantine on coupling/cohesion as the unit of design, and Ousterhout's 'A Philosophy of Software Design' on deep modules — then ask: in a Rust shop, who owns ownership decisions, and when?
incompleteThe cost-of-incidents argument is anchored to a Western, large-company threat model ('don't get woken up at night,' 'don't ship a CVE,' 'don't lose root'). It would be much stronger framed against actual cost-curve data: how much do memory-safety CVEs cost on average, what fraction of Google/Microsoft/AWS incident postmortems involve memory bugs, what's the marginal Rust dev-hour cost per prevented incident? Alice alludes to '~70% of Microsoft/Google bugs are memory bugs' folklore without citing.
Read next: Read the Microsoft Security Response Center memory-safety report (the source of the 70% figure), Google's Android memory-safety post-Rust adoption data, the CISA secure-by-design memo, and the US DoD/NSA memory-safety guidance Alice alludes to.
incompleteThe Cargo/npm risk parallel is acknowledged and immediately dropped. Given the kernel's explicit rejection of fetch-and-run package management (Linus's anecdote), Rust's strategy for supply-chain integrity is load-bearing for any organization considering it for security-sensitive code — yet the episode offers nothing beyond 'it's a hard problem.'
Read next: Read crates.io's threat model docs, the Cargo audit/cargo-vet tooling, Linux distributions' approaches to vendoring Rust crates, and recent academic work on the npm/PyPI/crates supply-chain attack surface.
incompleteThe Rust-and-AI thesis ('compiler-as-leash for agents') is asserted but not pressure-tested. Crucially absent: what happens when the agent reaches for `unsafe` to satisfy the compiler? What happens when the agent's chosen data structure is the wrong one and the compiler keeps approving — but at the cost of forcing Arc<Mutex<...>> everywhere? The compiler can't catch 'this struct shape was a bad idea.'
Read next: Look for empirical evaluations of AI coding agents in Rust vs in Go/TypeScript (recent benchmarks from Anthropic/OpenAI/SWE-bench-Rust), and pair with vibe-coding critiques like Steve Yegge / Gene Kim — exactly what Kjetil is already reading.
uninformedGergely floats 'is Rust uniquely good for agents because of compiler feedback?' and neither speaker has data; Alice has 'tried to use them' but is 'still learning.' This is a place where the conversation would have benefited from a third voice with measured agent-on-Rust experience.
Read next: Recent reports/benchmarks on agentic coding by language (e.g. METR/Anthropic, Cursor postmortems, the Aider language-success-rate leaderboard) would directly fill this.
illogicalThe phrase 'when it compiles, it works' is acknowledged-in-quotes but then deployed as if it were literally true (Alice's refactoring anecdote, Gergely's monologue). This conflates 'no bugs in the bug-classes Rust catches' with 'no bugs at all.' For an audience of senior engineers, the difference matters and the slippage is rhetorically convenient.
Read next: Read any survey on bug-class distributions in production systems; pair with Brian Goetz / Bjarne Stroustrup commentary on the limits of static typing.

Why Rust is different, with Alice Ryhl

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents