Ownership: One Rule That Replaces the Garbage Collector

Heap memory has to be released, and every language picks one of three answers.

Manual. The programmer calls free. Fast and predictable, and the source of the defect classes that dominate security reporting: use-after-free, double free, leaks. About 70% of the CVEs Microsoft assigned between 2006 and 2018 were memory safety issues, according to work by Matt Miller of the Microsoft Security Response Center presented in 2019, and Google has reported a comparable proportion for Chromium.

Garbage collection. A runtime determines when nothing references a value and reclaims it. Safe and convenient, at the cost of a runtime, unpredictable pauses, and memory overhead.

Ownership. Determine at compile time where each value's life ends, and insert the free there. No runtime, no pauses, and no manual calls.

The third is Rust's answer, and the entire language design follows from making it work. The cost is not paid at runtime; it is paid by the programmer, in the form of a compiler that rejects programs the other two would accept.

The model is stated in three sentences.

Every value has a variable that is its owner. There can be exactly one owner at a time. When the owner goes out of scope, the value is dropped.

The first and third are unremarkable; C++ destructors do the same. The second is the one that changes the language.

A single owner means the compiler always knows exactly one place where a value dies: the end of its owner's scope. There is no need to determine whether anything else still refers to it, because nothing else can own it.

That is what makes the analysis decidable without a runtime. Reference counting asks a question at runtime because the answer depends on execution; ownership makes the answer a property of the source text.

{
    let s = String::from("hello");   // s owns the heap allocation
    println!("{s}");
}                                    // scope ends: drop(s) runs here

The closing brace is a free. The compiler inserted it, and it is in exactly one place.

The single-owner rule forces a consequence that surprises everyone arriving from another language.

let a = String::from("hello");
let b = a;              // ownership MOVES from a to b
println!("{a}");        // compile error: borrow of moved value `a`

Assignment did not copy the string and did not create a second reference to it. It transferred ownership, and a is no longer usable.

The reason is forced. If both a and b owned the same allocation, both scopes would end and both would free it: a double free. The alternatives are to copy the heap data, which is expensive and silent, or to invalidate the source. Rust invalidates.

The same applies to function calls. Passing a value by value moves it, and the caller can no longer use it unless the function gives it back.

Small values stored entirely on the stack are exempt. Integers, booleans, characters and similar implement Copy, so assignment duplicates the bits instead, which is cheap and creates no ownership question.

The distinction is exactly whether the value owns a resource. Bits on the stack are copied; anything owning a heap allocation is moved.

A move is cheap. The three machine words describing the string are copied; the heap buffer is untouched. It costs the same as copying a pointer, which is what people usually expect assignment to do anyway.

The compile-time marking is the interesting half. Nothing is written to memory to record that a is dead. The compiler tracks it statically and refuses to generate code that reads a afterwards.

So the runtime behaviour is identical to a C pointer assignment, and the safety comes entirely from what the compiler refuses to emit. That is the general shape of Rust's guarantees: the checks happen at compile time and the generated code has no checking in it.

This is what the phrase zero-cost abstraction means here. The abstraction is ownership, and it costs nothing at runtime because it does not exist at runtime.

Once moves are understood, the ergonomics question follows: how do you use a value after passing it somewhere?

Three answers, in ascending order of cost.

Return it. The function takes ownership and hands it back. Explicit, free, and clumsy enough that it is rarely the right answer.

fn shout(s: String) -> String { s.to_uppercase() }
let s = shout(s);            // moved in, moved back out

Borrow it. Pass a reference instead, which the next lesson covers in full. This is the normal answer and it is why references exist.

Clone it. Duplicate the heap data explicitly.

let b = a.clone();           // a stays valid; the buffer is duplicated

The design decision worth noticing is that clone is explicit and named. Languages with implicit copy constructors hide allocations inside ordinary-looking assignments, so a performance problem is invisible in the source. In Rust, every heap duplication appears as the word clone, and a profiler pointing at allocation traffic sends you to a greppable token.

Beginners over-use it to silence the compiler, which works and is worth un-learning: a clone added to satisfy the borrow checker usually indicates a borrow that should have been restructured.

Ownership is usually explained with memory, and its reach is wider. The rule is about resources, and memory is one.

A file handle, a socket, a mutex guard and a database connection all need releasing at a defined point, and all of them are owned by a value whose scope determines when.

{
    let f = File::open("data.txt")?;   // f owns the handle
    // ... use f ...
}                                      // closed here, guaranteed

No finally, no defer, no context manager, and no way to forget. The close happens because the value was dropped, and the value was dropped because the scope ended.

This generalises the C++ idiom of tying resource lifetime to object lifetime, with the single-owner rule removing the ways that idiom can go wrong: no dangling handle, no double close, no use after close.

It also explains a pattern that looks odd at first. A mutex guard in Rust is a value whose scope is the critical section, and the lock is released when it drops. Forgetting to unlock is not a bug you can write, because unlocking is not something you do.

The trade is real and worth stating plainly, because the enthusiasm around Rust often skips it.

Some correct programs are rejected. The checker is conservative: it proves safety, so anything it cannot prove is refused. A program you know is fine may not compile, and the lesson What Undecidability Costs Real Tools explains why this is structural rather than a gap to be closed.

Data structures with sharing are harder. A doubly linked list, a graph with back-edges, a tree with parent pointers: all natural in a garbage-collected language and all fighting the single-owner rule. They are written using the tools of the fourth lesson, and they are more work.

There is a learning cliff. The first weeks involve the compiler rejecting code for reasons that are correct and unfamiliar. This is a genuine cost, paid once.

What you get in exchange is a specific and checkable list: no use after free, no double free, no null dereference, no data races, and no runtime or pause to achieve it.

Whether that trade is worth it depends entirely on whether those failure modes matter for what you are building, which is the same question the verification cursus asked about proofs.

The fourth row is the honest one. Rust prevents unsafety, not waste. A reference cycle can still leak, and leaking is considered safe in Rust's sense: it wastes memory without corrupting anything. That surprises people who assume safe means correct.

The last row is the summary. All three models pay; they differ in when. Manual pays during debugging, garbage collection pays during execution, ownership pays during compilation and during the first month of learning.

What the rule cannot yet express is temporary access. Moving a value to read it and moving it back is unusable, so the model needs a way to lend a value without transferring ownership. That is borrowing, and it is where the compiler starts reasoning about time.