The three machines

Here is the organising idea of this course, and it is not one you will find in The Book.

Rust does not have one execution model. It has three, and they answer different questions. Most of the time someone is confused about Rust, they are running the wrong machine in their head.

Machine 1 — the runtime machine

This is the one you already expect a language to have. It answers:

• Where does this value live — stack, heap, or inside another value?
• What does this line actually cost?
• When is this memory released, and who releases it?

Rust’s runtime machine is unusual mostly for being knowable. There is no garbage collector deciding things later, and no hidden allocation. A value has one owner; when the owner’s scope ends, the value is dropped. Every allocation is visible in the source.

This is why people say Rust is predictable. It is not a claim about speed. It is a claim that you can answer “when is this freed?” by reading.

Machine 2 — the compile-time machine

This is the one that has no equivalent in JavaScript, and only a weak one in Java and Go. It answers a completely different question: what does rustc know, and what will it therefore refuse?

It has two halves that people constantly confuse:

The borrow checker is a static analysis over your function’s control-flow graph. It computes, for each reference, the set of program points where that reference must still be valid, and then checks that nothing invalidates it during that set. That set is what a lifetime actually is. Hold that thought — it is the single most misunderstood idea in Rust and it gets a whole lesson (2.3).

The trait solver is a second evaluator. When you write T: Display + Send, you are writing constraints for a small logic engine that runs before your program does. It picks implementations, resolves associated types, and then monomorphisation generates a separate concrete copy of your function for every type you used it with.

That last part deserves emphasis, because it is where TypeScript intuition misleads badly.

Machine 3 — the social machine

The third machine is not in the language specification at all, and it is the one most courses skip entirely. It answers: what is this code’s author signalling?

When you read Arc<Mutex<Vec<Job>>>, the language tells you it is an atomically reference-counted pointer to a mutex containing a vector. The social machine tells you something more useful: this is shared mutable state across threads, the author expects contention to be low, and a reviewer will ask whether a channel would have been better.

When you see a struct with a private field of type PhantomData<*const ()>, the language says “zero-sized marker”. The social machine says “the author is deliberately making this type not Send”.

For your stated goal — discussing Rust with Rust programmers — machine 3 is not optional garnish. It is most of the conversation. Part 6 is dedicated to it.

The diagnostic question

This frame earns its keep when you are stuck. Ask: which machine am I asking about?

A worked example of the confusion. A newcomer writes:

let first = &v[0];
v.push(4);
println!("{first}");

…and gets an error. They ask “why does Rust think this is unsafe? Nothing is freed here.” That question mixes machines. The runtime machine is not the one complaining. The compile-time machine noticed that first must stay valid across the push, and push takes &mut v, and those two cannot overlap. The compiler is not predicting a crash — it is enforcing a rule about references that happens to also prevent a crash.

Getting this distinction right is what separates “Rust is fighting me” from “I know which of Rust’s two brains I am arguing with”.

Pretest — one question per part

Now the part you will not enjoy.

Below are six questions, one from each remaining part of the course. You have not been taught any of it. Do not look anything up. Do not open the Playground. Guess, commit, and rate your confidence honestly.

This feels pointless. It is not. Being tested on material before studying it measurably improves how much you learn from the later study — including for the items you answer wrong. The effect is called pretesting, and the leading explanation is that a failed retrieval attempt marks the gap, so that when the real answer arrives it lands somewhere prepared rather than sliding past.

The wrong answers you are about to give are doing work.

fn main() {
    let a = [1u8, 2, 3, 4];
    let b = vec![1u8, 2, 3, 4];
    println!("{} {}", size_of_val(&a), size_of_val(&b));
}

fn main() {
    let mut v = vec![1, 2, 3];
    let first = &v[0];
    v.push(4);
    println!("{first}");
}

fn show<T: std::fmt::Display>(x: T) { println!("{x}"); }

fn main() {
    show(1u8);
    show("hi");
    show(2.5f64);
}

async fn work() { println!("working"); }

fn main() {
    let fut = work();
    println!("done");
}

Check Calibration now to see your baseline. Come back to it after Part 2 and after Part 4. The number that matters is not your accuracy — it is the distance between your confidence and your accuracy.

Next: 1.1 — Values, places, and bindings, where we replace the model that failed you in 0.1.