Bryan Cantrill, CTO of Oxide Computer, spent the 1990s and 2000s writing operating-system kernel code in C, mostly at Sun, while the rest of the industry built languages to make developers’ lives easier. In this Rust NYC talk he argues that much of that era’s convenience was an unacknowledged trade: easier for the developer, harder for whoever ran the software in production. Rust reversed the trade. The second half applies the same lens to LLMs, which he thinks are excellent at Rust for the same reasons, and dangerous for a reason most people haven’t named.

Before Rust: developer ease paid for by the operator

Slide: “Before Rust” listing dynamic typing, M:N threading, garbage collection, exceptions, ORM and RPC as constructs that traded production behaviour for development ease

His list of examples is deliberately provocative: garbage collection, dynamic typing, M:N threading, exceptions, ORMs and RPC. Each one lowered the cognitive load on the developer, and each one showed up later as emergent behaviour in production. GC pauses, and closures that keep objects alive so that “the garbage collector is now a heap scanner”. Typos in property names that should have been compile errors but surface at runtime. Developers who never found out their ORM calls were database queries. RPC, which he calls “almost tautologically a bad idea” because it disguises a network hop as a function call. He’s careful to say these are fine for many kinds of software. His complaint is about infrastructure, the software other software is built on.

Abstraction, leaks and exploding complexity

Slide: when abstractions leak, accidental complexity in one component can become essential complexity in another

Abstraction is the core of software work, and a good one is invisible: people don’t know they’ve been abstracted. Bad ones leak, and a leaky abstraction tuned for development puts the cost on the operator. Here he uses Fred Brooks’s split between essential and accidental complexity, with one addition. Complexity doesn’t just add up; it can explode. Accidental complexity in one layer becomes essential complexity for every layer that has to work with it. His example is UEFI firmware: ARM didn’t need to copy it, but adopted it because something everyone has starts to feel non-negotiable.

Slide: a taxonomy of systems: constructed, revolutionary, accreted and rebellious

He reuses a taxonomy from an earlier TalosCon talk, with two axes: complex to simple, and engineered (deliberate) to emergent (reactive). That gives four kinds of system:

  • Constructed systems are big, deliberate and complex, like IBM’s System/360 in The Mythical Man-Month.
  • Rebellious systems react by throwing things out, like Unix after Multics. They fail when something they discarded turns out to have been load-bearing.
  • Accreted systems are emergent and complicated. This is where most systems end up, and what we call technical debt. Some are “born accreted”.
  • Revolutionary systems come from a small group with focused time that changes the abstraction rather than just shrinking it. Most programming languages start here.

The “revolutionary’s paradox” is that revolutionary systems drift toward accretion. Java began as a revolt against C++, J2EE became its own mess, and Rails was in turn a reaction to Java. Python started as a teaching language and now sits somewhere between constructed and accreted. Cantrill’s explanation is that decisions optimised for the developer during development become baggage once the system is used as a foundation for twenty years. Cassandra’s GC tuning is his current pain.

The Rust revolution: artifact first

Slide: Graydon Hoare quote describing Rust as a tool for building other infrastructure

He suggests reading a language’s founding documents to learn how it makes decisions. (JavaScript has none, which he says tells you something.) For Rust he uses Graydon Hoare’s reflection on ten years of stable Rust:

“Programming languages are a type of technical infrastructure: specifically, they are tools. Rust is a tool for building other infrastructure.”

Early Rust had both green threads and garbage collection, which Cantrill remembers feeling like “a message in a bottle from the civilization that had been started on the remote island that the island was burning to the ground.” Then Rust removed both. Removing GC produced the ownership model; removing green threads, and mostly keeping exceptions out, followed from the same infrastructure-first culture.

Slide: Rust optimised for the artifact first and then, within those constraints, the developer experience

That’s the bargain. Rust moves cognitive load back onto the developer (you have to think about who owns what), and in return gives safety. His proof came from his first serious Rust project. He wrote it naively, just trying to get it to compile, and it ran faster than his carefully tuned C. The reason was a B-tree. In Rust you use BTreeMap without thinking about it. In C, a B-tree is “bringing firearms to a preschool”, because nodes move in memory and with no ownership tracking the library contract becomes a pile of callbacks, so most C programmers use AVL or red-black trees instead. The ownership model makes a faster abstraction usable. He adds that refactoring Rust that compiles “probably works”, which changes whether refactoring is worth the risk.

Into the LLM age

Slide: Rust’s steep learning curve is a strength for LLMs because compilation gives ample feedback

Cantrill points to the late-2025 inflection (Claude Opus 4.5 and GPT-5.1, citing Simon Willison) as the moment LLMs became undeniably good at writing code. For Rust that has surprising effects. The steep learning curve, Rust’s supposed weakness, becomes a strength, because a compiler that rejects incorrect code gives a model a lot of feedback. The crate ecosystem gives a solid base for generated code to build on. And the output is fast and memory-safe. If anything, he says, Rust has become “too appealing” a target.

He spends a few minutes on DHH, who gave a Rails World keynote about vibe-coding everything in Rust while calling Rust’s code ugly and making a point of not reading it. Cantrill’s objection is that this takes Rust’s benefits while dismissing the work that produced them. DHH credits Rust’s performance, but that comes from things like BTreeMap, which come from the ownership model.

The peril: LLMs aren’t lazy

Slide: “Laziness lost”: simple abstractions come from the human need to comprehend systems, and LLMs lack the virtue of laziness

This is the main argument of the talk. Larry Wall listed laziness as one of a programmer’s three virtues (Oxide named its embedded OS, Hubris, partly after another). Our need to fit a system in our heads is what pushes us toward simple, first-principles abstractions. His trigonometry example: if you know that cos²x + sin²x = 1 you can derive the rest during the exam. LLMs don’t have that limitation. They love work, so they lean toward the complicated. If you tell one to be lazy it apologises and then works very hard at being lazy, or, as he puts it, starts “10,000 agents” on hammock-driven development.

Slide: “Management consultancy”: LLMs are incentivised to work, which breeds dependency rather than completion

It gets worse because LLMs are, implicitly or explicitly, built for engagement. He compares them to management consultants who always want to be back on Monday, and to slot machines (“have you spent nine hours in a casino?”). Left to themselves, they’ll keep producing work instead of abstraction. In the slide’s words, they “cannot become the revolutions that they have benefited from”.

Slide: Steve Yegge quote on Gas Town falling apart because the model never converged

His cautionary tale is Gas Town, Steve Yegge’s agentic “software factory” (written in Go), whose author said he never looked at the code. On the slide, Yegge says the model picked up a “just two more things” tic that kept it from ever converging. It kept wanting to work on Gas Town itself, and the project effectively burned down. Cantrill’s comparison is two LLMs on a phone call that can’t figure out how to hang up, while the meter runs.

Rust in the LLM age: use them, but learn Rust

Slide: LLMs are extraordinarily powerful, but they are a tool; newcomers to Rust should learn Rust

He isn’t arguing for abstinence. He calls LLMs “off the charts good at comprehension” and says asking questions of your own codebase is the most underrated use, partly because the answers are easy to verify. Oxide’s Rain Paharia doesn’t let an LLM write her code comments: if she can’t write the comment herself, she doesn’t understand the code yet. He says LLM help with formal verification has turned program proving from “a distant moon” into something practical. His summary is that LLMs should improve our ability to create abstractions, not replace it. Newcomers shouldn’t fall into learned helplessness, needing an LLM to explain what an LLM wrote. Learn Rust, and use the LLM as a tutor to do it.

In the Q&A he calls LLMs clearly additive “but it needs discipline”. He recommends Oxide’s public RFD 576 on using LLMs, and explains why Oxide requires its published writing to be human-authored (checked with the Pangram detector): LLM prose has such low information density that “your brain holds the ejection handle”. Asked which Rust features he’d remove, he names async cancellation safety, saying the arguments for not worrying about it sound like the arguments C programmers make about memory safety. He recommends Rain’s RustConf talk on it.

Key takeaways

  1. Much of the developer convenience of the 1990s and 2000s (GC, dynamic typing, ORMs, RPC, M:N threading) was paid for by whoever operated the software in production. That matters most for infrastructure.
  2. Accidental complexity compounds. A leaky abstraction in one layer becomes essential complexity for every layer built on it.
  3. Revolutionary systems tend to drift toward accretion. Rust has resisted by treating “a tool for building infrastructure” as a hard constraint: it removed GC and green threads and mostly kept exceptions out.
  4. Rust’s ownership model enables faster abstractions, not only safer ones. A BTreeMap is routine in Rust and painful in C.
  5. The compiler feedback that makes Rust hard for people to learn makes it a good target for LLMs, and the crate ecosystem gives generated code a solid base.
  6. LLMs lack the laziness that pushes people toward simple abstractions, and their bias toward engagement means they rarely stop. Gas Town shows where that leads.
  7. Use LLMs for comprehension and for tightly scoped tasks, write your own comments to make sure you understand the code, and learn the language instead of depending on the model.

Source

  • Talk: “Code Matters: Reflections on Rust in the LLM Age”
  • Speaker: Bryan Cantrill, CTO, Oxide Computer Company
  • Event: Rust NYC meetup (uploaded by Rust East Coast), November 2026
  • Duration: 1 hour 31 minutes (about 73 minutes of talk, then Q&A)
  • Video: https://www.youtube.com/watch?v=5D7QPOIZ7gY
  • Further reading from the talk: Rich Hickey, Simple Made Easy (2011); Fred Brooks, No Silver Bullet (1986); Oxide RFD 576, Using LLMs at Oxide