warming up your workspace

The borrow checker, explained by fighting it

Typed languages are quietly winning. TypeScript is now the most-used language on GitHub, and as AI writes more of our code, the value of a compiler that catches mistakes before they run goes up, not down. Rust is the sharp end of that trend: a language whose compiler refuses to ship a whole category of bugs. The price of admission is the borrow checker, the thing nearly everyone bounces off in week one.

The fastest way to understand it is not to read the rules. It is to write the code that breaks them and read what the compiler says, because each error is pointing at a real bug.

The one idea: ownership

In Rust, every value has exactly one owner, a single variable responsible for it. When the owner goes out of scope, the value is freed. No garbage collector, no manual free. The compiler knows, at compile time, exactly when every value dies.

Everything else, moves and borrows, exists to keep that one-owner rule true while still letting you actually use your data.

Fight #1: a move

Assigning a value transfers ownership. Watch:

let s1 = String::from("hello");
let s2 = s1;          // ownership of the string moves from s1 to s2
println!("{s1}");     // error[E0382]: borrow of moved value: `s1`

Coming from Python or Java, this looks absurd. Didn't I just copy a reference? No: Rust moved ownership into s2, and now s1 is empty. If both could use the string, both would try to free it when they went out of scope, and you'd get a double-free, a classic memory-corruption bug. The compiler is preventing it at compile time.

The fixes show you the choices Rust is making explicit:

let s2 = s1.clone();  // make a real second copy; now both own their own string

Or, far more common, don't take ownership at all, borrow it.

Fight #2: borrowing

A borrow is a reference: access to a value without owning it. You write &value. The owner keeps owning; you just get to look.

fn length(s: &String) -> usize {
    s.len()
}

let s = String::from("hello");
let n = length(&s);   // length borrows s, doesn't take it
println!("{s} is {n}"); // s is still ours, still valid

Borrowing is how you pass data around without the move dance. But borrows come with the rule that is the actual heart of the borrow checker.

The rule: shared XOR mutable

At any given time, for a given value, you can have either:

  • any number of immutable borrows (&T), readers, or
  • exactly one mutable borrow (&mut T), a single writer.

Never both at once. Many readers or one writer, never readers and a writer together. Break it and the compiler stops you:

let mut v = vec![1, 2, 3];
let first = &v[0];     // immutable borrow: a reader
v.push(4);             // error[E0502]: cannot borrow `v` as mutable
                       // because it is also borrowed as immutable
println!("{first}");

This error is the borrow checker earning its keep. v.push(4) might need to grow the vector, which can reallocate its backing memory somewhere new, which would leave first pointing at freed memory: a use-after-free, a dangling pointer, the bug behind an enormous share of security vulnerabilities. In C++ this compiles and occasionally corrupts at runtime. In Rust it simply does not build.

The fix is to not hold a reader across a write:

let mut v = vec![1, 2, 3];
v.push(4);              // mutate first, while nobody is reading
let first = &v[0];      // now borrow
println!("{first}");    // fine

The rule is smarter than it looks: NLL

A borrow doesn't last until the end of the block, it lasts until its last use. This is "non-lexical lifetimes," and it makes the checker far less annoying than the rules first suggest:

let mut x = 5;
let r1 = &x;
let r2 = &x;
println!("{r1} {r2}");  // last use of r1 and r2 is here
let m = &mut x;         // OK: the shared borrows are already done
*m += 1;
println!("{x}");        // 6

r1 and r2 are two readers at once, which is allowed. They are finished by the println!, so when &mut x asks to be the single writer, no readers are live and the compiler is satisfied. The "shared XOR mutable" rule is enforced over time, not over scope.

Why this is worth the fight

Every error above maps to a specific bug other languages let you ship:

  • Move errors prevent double frees.
  • "Cannot borrow as mutable" prevents iterator invalidation and use-after-free.
  • "Borrowed value does not live long enough" (the lifetime errors that come next) prevent dangling references.

These are not stylistic nags. They are the memory-safety bugs that account for a large fraction of the security vulnerabilities patched every month across the industry. Rust moves the discovery of those bugs from "3 a.m. production incident" to "red squiggle in your editor." That is the entire pitch, and it is why the language keeps climbing despite the learning curve.

The trick to learning it is to stop treating the errors as obstacles and start reading them as a code reviewer who has caught a real problem. Write the broken version on purpose, read the complaint, fix it, and the rules stop being arbitrary, they become the shape of code that cannot corrupt memory. If you want to build that intuition the only way it sticks, by writing Rust until the checker stops surprising you, that is the Rust track on IWTLP, ownership and borrowing first, because everything else is built on it.