Will Crichton on Making Rust More Understandable

Will Crichton, an assistant professor at Brown University, presents several years of research on making Rust accessible to novices and experts. He describes Rust as combining systems programming’s efficient, predictable resource use with functional programming’s expressive abstractions and correctness.

Crichton values Rust because critical infrastructure has long depended on systems languages such as C and C++, whose complexity makes memory and thread safety difficult at scale. He also dislikes the myth that systems programming is reserved for a rare kind of exceptionally capable programmer.

Rust remains complex: learners may have to understand both pointers and memory layout and concepts such as higher-order functions and algebraic data types. Surveys and studies identify complexity as a major adoption barrier. His goal is not to weaken the language, but to help people learn it and work effectively in complex codebases.

Crichton wants developer tools grounded in human-centered design and theories of cognition, tested against real outcomes. He introduces three open-source projects: ownership visualization for learners, trait debugging and program slicing for working with complex code.

He begins with memory safety. In a C++ example, a pointer refers to an element in a vector. Appending another element reallocates the vector and leaves that pointer referring to invalid memory; dereferencing it can read invalid data.

An equivalent Rust program is rejected at compile time. The immutable or shared reference to the element conflicts with a mutable, unique borrow needed to push onto the vector. Ownership and borrowing are central to Rust’s safety guarantees, but developers often report them as difficult to learn.

The researchers hypothesized that teaching ownership as a growing list of prohibitions gives learners an overly ad hoc mental model. They wanted a constructive model that lets people reason line by line about the state the compiler tracks, including in programs that compile successfully.

Their permissions model gives a variable read, write and own permissions. Initializing a vector grants all three. Creating an immutable reference requires read access and removes write and own permissions from the vector for the reference’s active lifetime; the reference and the data accessed through it have distinct permissions.

Once the reference is no longer used, the vector regains write and own permissions, allowing a later push. The visualizer makes these otherwise invisible changes visible. The team formalized the model as an extension of the borrow checker and built Aquascope to generate diagrams automatically.

Crichton contrasts Aquascope with diagrams focused primarily on lifetime lines. His team’s research led it to emphasize how borrows change permissions, how permissions attach to variables, and how they extend to fields. The difference comes from distinct hypotheses about what learners find difficult.

To investigate, the researchers collected common ownership questions from Stack Overflow and asked 36 Rust developers to reason about their code. Participants often could not explain the memory-safety issue the compiler prevented, or assumed they were wrong when the compiler rejected a valid program.

The team combined compile-time permission diagrams with a tool showing abstracted runtime stack and heap state. It embedded both in a rewritten ownership chapter in a fork of the Rust Book. A visualization alone, Crichton says, is not a complete pedagogy.

The public book included multiple-choice questions derived from the earlier study. Readers of the new chapter scored nine percentage points higher on average than readers of the baseline chapter. Crichton calls this limited initial evidence of improved learning, and says roughly 150,000 people had used the book over three years.

He argues that a science of human-centered programming should start from observed struggles and evaluate more than whether users say they like a tool. The relevant question is whether the tool improves an outcome such as answering questions correctly.

The second project, Argus, helps developers understand trait errors. Crichton introduces traits with a simplified ToString example: a trait specifies a function, a type can implement it, and generic implementations can require their component types to implement it too.

A generic print function requires each item to implement the trait. The compiler’s trait solver checks an implementation for a pair and then checks the requirements for its components. If a component lacks the implementation, the resulting diagnostic identifies a failed bound and provides context.

A good diagnostic tries to identify the problem, provide context and suggest a fix. Yet even a tiny example can produce an error longer than a screen. A Diesel SQL example catches an incorrect table insertion but produces an enormous diagnostic, including a note that a full type name has been written to a file.

Crichton treats this as an information-visualization problem. Argus extracts the trait inference tree from the compiler and lets a developer explore it interactively, hiding details until requested. A top-down view follows requirements from the original bound; a bottom-up view starts at failed leaves.

He demonstrates a Bevy game-framework example where a developer forgets a required wrapper around a resource. The compiler catches the invalid system but cannot easily choose among competing possible implementations to identify the intended one, leaving a large, unhelpful error.

Argus’s bottom-up view lists candidate failures, including the missing SystemParam implementation for the problematic type. Users can inspect other failures, hover for qualified paths, jump to definitions or follow the top-down inference. The goal is to expose useful detail without displaying everything at once.

In a user study, developers using Argus localized trait-error causes about three times faster than with compiler diagnostics alone. Crichton reports encouraging early feedback from library developers and says the free, open-source tool integrates with VS Code.

The third project is program slicing. When trying to understand one part of a complex function, a developer may want to filter out code irrelevant to a particular value. Crichton demonstrates a URL parser: selecting the path variable fades code that cannot affect it and highlights code that can.

The slice can show earlier code that influences the selected value and later code the value may influence. In the example, it also draws attention to an unexpected mutation of the path. Crichton says study participants quickly understood the interaction and missed it when the tool was removed.

Slicing depends on aliasing and mutation. In his Python example, assigning a string from a list to a variable and appending to that variable does not update the list element, while modifying the element directly does. A slicer must understand which values can refer to the same data and which operations change them.

Black-box functions make static analysis harder: their definitions may be unavailable because they are in another language, a closed-source library or a higher-order call. The challenge is to compute slices through such calls while finding real dependencies and avoiding spurious ones.

Rust provides extra information in ownership types. In a vector example, get_mut returns a mutable reference to an element; mutating that reference affects the vector. A shared lifetime in the signature helps the analysis infer a possible alias, and a mutable reference indicates a possible mutation without inspecting the function body.

Crichton distinguishes soundness—finding real dependencies—from precision—reported dependencies being real. The team proves soundness for its formal safe Rust subset, but features such as interior mutability can make the tool miss dependencies. In those cases it may fade code that should remain visible.

To estimate precision, the researchers compared their modular analysis with a version allowed to inspect function definitions across 400,000 lines of real Rust code. The two produced the same answer in 94% of cases in that comparison; a mutable reference, for instance, usually does correspond to a mutation.

Reflecting on AI agents, Crichton prefers thinking about augmentation of programmers rather than simply replacing them. As long as people retain agency and need to understand software, tools must communicate behavior in ways suited to human cognition.

He sees programming-language theory as a way to build tools with precisely understood reliability, including known cases where they succeed or fail. He also argues that tools for learners deserve attention even when a visualization, such as the ownership diagram, does not scale to hundreds of lines.

The space of possible misconceptions is much larger than the set of correct mental models. Crichton would like tools that model those misunderstandings and supply information in context, alongside the debugging and visualization tools commonly designed for experts.

An audience member asks about async Rust, especially interactions among async traits and lifetimes. Crichton says async had overtaken ownership as the hardest topic in the survey he cites. His team has started studying what async systems are for and how mechanisms relate to goals such as cancellation.

For example, runtimes differ on what happens to a spawned task when its parent function returns: it may continue, be canceled or be awaited. Crichton wants to articulate the design space across Rust, Swift, Kotlin and other systems so learners know which questions to ask.

Asked about dynamic languages and gradual typing, Crichton notes a gap between academic theories and practical systems such as TypeScript. Developers under pressure can bypass type checks with Any, potentially accumulating technical debt; strict systems can instead slow the pace at which features ship.

He wants better evidence about the relationship between type-system design, developer productivity and actual bugs. Such questions are difficult to study in a controlled way, but he sees them as important future research rather than settled arguments.

Asked whether these tools could help AI agents, he suggests compiler internals such as a trait inference tree could be exposed in text for a model to use. Conversely, assistants could use richer diagrams and experiments to explain ideas to people rather than relying only on text and code snippets.

An audience member asks how people can progress beyond workarounds such as cloning whenever Rust’s borrow checker complains. Crichton gives an example where a developer clones an object and mutates the clone, then drops it, leaving the original unchanged. A workaround can therefore alter the intended behavior.

He thinks teaching ownership early is valuable because it pervades Rust. A simpler language with a gradual path to ownership could be useful, but defining it is hard: deterministic destruction, for example releasing a mutex through drop, does not translate trivially to garbage collection. He is interested in better-defined gradual approaches.

Finally, Crichton is asked what language tools would help visualization researchers. He criticizes the limits on code overlays in VS Code, where adoption is widespread, and contrasts them with CodeMirror’s flexibility. Argus can use a separate panel and the slicer can fade code, but richer visualizations often require a costly editor fork.

He calls for a more extensible platform for visualizations and code decorations, so researchers can distribute tools and developers need not maintain separate, incompatible editors. He thanks the audience and closes the talk.