Orientation: Rust makes the compiler keep the contract

The C++ track ended on a bargain: undefined behavior is the price of zero overhead, and the contract — never break these rules — is kept by nothing but the programmer's promise. The Go track answered a different question (what does complexity cost a team?) and kept the contract with a run-time system instead. This series asks the third question: could the compiler keep the contract, at C++'s price? Before any syntax, one claim: Rust is what you get when you take that question seriously and follow its consequences one forced step at a time. This lesson states the promise, shows why the design space collapses, installs a five-question habit, and draws the 23-lesson chain in which every lesson solves exactly the problem the previous one created.

1 · Three answers to one problem

The C++ track's last lesson made a claim worth rereading: undefined behavior is not a defect in the standard, it is the mechanism by which zero overhead is implemented. The compiler may assume you never break a short list of rules — never index out of bounds, never touch freed memory, never race — so it emits no check that would guard against you doing so. You keep your half of the contract by discipline, by review, by running sanitizers in test. If you break it, the standard owes you nothing at all.

Any language that lets you touch memory has to decide who keeps that contract. There are only three candidates: the programmer, the run-time system, and the compiler. The three language tracks in this library are the three answers. ("Run-time system" here means whatever runs beside the program to enforce the contract: a collector, a scheduler, checks inserted everywhere. Code the compiler emits that enforces nothing, such as the bookkeeping for a panic's unwinding in Lesson 10, is not one.)

Nothing here says one column is right. It says they are three different places to spend the same scarce thing: someone's attention. C++ spends the programmer's. Go spends the machine's. Rust spends the compiler's — and yours, up front, learning to write programs the compiler can verify. Whether that is a good trade is a question about your project. What this series can do is show you exactly what the trade is, by deriving the language from the promise instead of listing its features.

2 · The promise and the budget

Two sentences define the whole design. Everything else in this series is a consequence of holding both at once.

Read the promise as a statement about programs, not about programmers: it does not say your code is correct, it says your code cannot be undefined. The distinction is the whole point. A wrong answer is a bug you can find with a test; undefined behavior is a bug the language has agreed not to describe — it can corrupt unrelated memory, be exploited, and vanish when you add a print statement (the C++ track's Lesson 19 showed the optimizer deleting a null check that came after the bug).

Here is the smallest program that shows what "the compiler keeps the contract" feels like. It takes a name for the first element of a vector, then grows the vector — which may move its buffer — then uses the name. In C++ this compiles, runs, and is undefined behavior. In Rust:

fn main() {
    let mut v = vec![1, 2, 3];
    let first = &v[0];      // a name for the first element
    v.push(4);              // may reallocate: moves the buffer
    println!("{first}");    // ...then uses the stale name
}

error[E0502]: cannot borrow `v` as mutable because it is also borrowed as immutable
 --> src/main.rs:4:5
  |
3 |     let first = &v[0];
  |                  - immutable borrow occurs here
4 |     v.push(4);
  |     ^^^^^^^^^ mutable borrow occurs here
5 |     println!("{first}");
  |                ----- immutable borrow later used here

Both sentences are now on the table. Which designs can keep the first without breaking the second?

3 · Why the design space collapses

You can argue that the promise and the budget together force the design. Not by decree — by elimination. The C++ track's catalog of undefined behavior has seven families (out-of-bounds access, use-after-free, signed overflow, uninitialized reads, null dereference, data races, type punning). For each, ask: which mechanisms can actually rule it out, and what do they cost?

Now make the choice yourself. The slider is your run-time budget; the button says whether the safety must be a guarantee (the promise) or a hope (C++). A filled dot means "this mechanism really does rule that family out"; it turns hollow when your constraints forbid paying for it. The bottom row counts how many designs are left for each family. Start at the top of the budget and drag down.

// A mechanism rules a family out iff it fits the budget, guarantees that family,
// and (when a guarantee is required) is not "trust the programmer".
function eligible(m, f) {
  if (m.cost > st.budget) return false;
  if (m.id === 'trust') return !st.guar;
  return m.g.indexOf(f) >= 0;
}
// per family: the eligible mechanisms; 0 = no design, 1 = forced.
function options(f) { return MECH.filter(function (m) { return eligible(m, f); }); }

What you should have found. With the guarantee required and the budget at "cheap checks", the readout lists five families with exactly one design left. Three have a cheap one: a local rule for signed overflow and for type punning, a compare for out-of-bounds access. The other two — use-after-free / dangling and data race — are left with a static proof about which names can reach which memory, and when. Not because someone preferred it, but because the alternatives cost a collector (which the budget forbids, and which does not help with races anyway), a counter per access (which the budget forbids for every access), or the sanitizers' slowdown (roughly 2–10× in the C++ track). Drop the budget to zero and a different family goes red — out-of-bounds access — and that is the honest concession: even Rust's promise costs one compare per checked index. Everything the promise needs beyond that is free of run-time cost, because it happens before the program runs.

The two families that collapse are not arbitrary. Every other family is a problem with a single operation — this index, this read, this cast — and a local rule can rule it out. These two are problems with a relationship between two names over time: one name frees or changes a place while another name still expects it to be there. No local rule can see that. The next lesson makes it precise, and the rest of the series is the machinery that makes it checkable without a run-time system. First, though, a habit that finds such relationships in any line of code.

4 · The habit: five questions for any line of code

The C++ track installed five questions about cost; the Go track installed five about complexity. This one installs five about proof. By the end you will ask them reflexively, in any language, and usually know the answer:

None of these is Rust-specific. They are what a careful reviewer asks of any C++ pointer, any Go channel, any Java shared list. Rust is the language that makes you answer them in the source, checked by a machine — which is how they become reflex. The order in which the series answers them is its spine.

5 · The 23-lesson spine is a derivation, not a topic list

Each lesson opens with the problem the previous one created and closes by creating the next. That relay is written down: the sentence that ends lesson N is the same sentence that begins lesson N+1, and the series index shows all of them in one table. The six movements: state the promise (I); derive the ownership-and-borrowing law that keeps it (II); build types that carry proofs, so abstraction does not cost the guarantee (III); handle the cases where one owner is not enough (IV); mark the boundary where a human takes over from the checker (V); and ship it, with an honest bill (VI).

Before the first step, price the destination: what thinking this way buys, and what it costs.

6 · What it buys, what it costs

7 · Misconceptions to drop now

Checkpoint exercise

Where this points next

We have a promise, a budget, and the argument that together they leave only compile time for the proof. But "compile time" is not yet a design: a compiler can reject only what it can recognize, and "undefined behavior" is a long, heterogeneous list. Lesson 01 does the work that turns the slogan into a specification. It takes the seven families apart, shows that most yield to a small local rule, and shows that the two dangerous ones are really the same bug in different clothes — one law about names and places. Once you can state that law in a sentence, the rest of the series is how to make a machine check it. First, then: what exactly must be ruled out, and what does each rule need to know?

Interview prompts

• State Rust's safety promise and its cost budget, and say what each one rules out. (§2 — safe code has no undefined behavior; no garbage collector, no run-time system, no hidden cost. Together they exclude designs that pay for safety at run time.)
• Why does removing the garbage collector and heavy run-time checking force a compile-time analysis for use-after-free and data races? (§3 — every other mechanism that guarantees those families needs a collector, a per-access counter or sanitizer-style instrumentation (roughly 2–10× in the C++ track), all outside the budget; a GC does not address races at all.)
• How do C++, Go and Rust differ in who keeps the safety contract? (§1 — C++: the programmer, by promise; Go: the run-time system, by checks and a collector; Rust: the compiler, by proof at build time.)
• What does safe Rust not prevent? (§2 — deadlocks, leaks, overflow to a wrong-but-defined answer, logic errors; and the promise is conditional on the soundness of the unsafe code it relies on.)
• Why is the bounds check the "honest concession" in Rust's zero-overhead claim? (§3 — no free mechanism can guarantee an index is in range, so the promise costs one compare per checked index.)
• Name the five questions the series trains you to ask of any line of code. (§4 — who owns it and when does it end; who else can reach it, shared or exclusive, for how long; what does the signature promise; is it proven or checked and at what price; where does the proof stop.)
• What is the anatomy of a borrow-checker error message? (§2 — three points: where a name was created, where a conflicting action happens, and where the name is used afterwards.)

Companion reads: C++ · 19 Undefined behavior (the bargain this lesson starts from), C++ · 05 RAII (why a collector does not end files and locks), and Go · 03 Pointers, the heap and the collector (the run-time system's answer, priced in its own terms).