Rust for Beginners: Understanding Ownership

Everyone hits the same wall learning Rust. The syntax is unremarkable, the tooling is excellent, and then the compiler rejects a program that is obviously correct, with a message about a value being moved.

Ownership is the reason, and it is the thing Rust exists to do. It is also simpler than the reputation suggests: one rule, three consequences, and a set of compiler messages that mean specific things once you know what they are pointing at.

This is that explanation, aimed at someone who knows another language and has just met the borrow checker.

The problem ownership solves

Every language has to answer one question: when memory is no longer needed, who frees it, and when?

Two existing answers, and their costs

Manual management - C and C++. You allocate, you free. Fast and precise, and it produces the entire catalogue of memory bugs: use-after-free, double-free, leaks, and data races. Decades of tooling exists to catch these after the fact.

Garbage collection - Java, Go, JavaScript, Dart. A runtime tracks what is reachable and frees the rest. Safe and convenient, at the cost of a runtime, memory overhead, and pauses at moments you do not choose.

Rust takes a third option: decide it at compile time. The compiler tracks who owns each value and inserts the cleanup itself. No runtime, no collector, no pauses - and the memory bugs are compile errors rather than production incidents.

The price is that the compiler must be able to prove your program is sound. When it cannot, it refuses. That refusal is the borrow checker, and learning Rust is mostly learning to write proofs it accepts.

The rules

Three rules, and the third causes all the trouble.

1. Every value has exactly one owner

let s = String::from("hello"); // s owns this String

One owner at a time. When the owner goes out of scope, the value is dropped and its memory freed. No ambiguity about who is responsible.

2. Assignment moves ownership

This is the first surprise.

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

In most languages b = a copies a reference and both names work. In Rust, ownership moved: a is no longer valid, because two owners would mean two frees.

It applies to function calls too:

fn consume(s: String) { /* s dropped here */ }
 
let text = String::from("hi");
consume(text);
println!("{}", text);   // error: value moved into `consume`

Simple types - integers, booleans, chars - implement Copy and are duplicated instead of moved, which explains why this never bites with numbers and always bites the first time you pass a String.

3. You may borrow instead of move

Moving ownership for every read would be unusable, so you can borrow a reference:

fn length(s: &String) -> usize { s.len() }   // borrows, does not take
 
let text = String::from("hello");
let n = length(&text);
println!("{} is {} long", text, n);          // still valid

And the rule that generates most borrow-checker errors:

At any time you may have either one mutable reference or any number of immutable references - never both.

let mut s = String::from("hello");
 
let r1 = &s;        // fine
let r2 = &s;        // fine - many readers
let r3 = &mut s;    // error: cannot borrow as mutable
                    // while borrowed as immutable

This looks restrictive until you notice what it eliminates. Two references where one can mutate is exactly the shape of a data race - and of iterator invalidation, and of the aliasing bugs that make C++ hard. Rust rules out the shape, so it does not have to catch the instances.

It pays to be noting the compiler is smarter than the rule suggests: a borrow ends at its last use, not at the end of the block. Code that looks illegal often compiles because the earlier borrow was already finished.

Reading the errors

Rust's error messages are really good, and each common one maps to a specific misunderstanding.

"value borrowed here after move"

You gave the value away and then used it. Three fixes, in order of preference:

Borrow instead - usually right. Change fn f(s: String) to fn f(s: &String) and pass &text.

Clone - honest and sometimes correct. f(text.clone()) costs an allocation and says so. Fine while learning; a smell if it is everywhere.

Return it back - fn f(s: String) -> String hands ownership back. Verbose, occasionally the clearest option.

"cannot borrow as mutable more than once"

You have two mutable references live at once. Usually the fix is scoping - end one borrow before starting the next:

let mut v = vec![1, 2, 3];
 
{
    let first = &mut v[0];
    *first += 1;
}                       // borrow ends here
 
v.push(4);              // now fine

"missing lifetime specifier"

Lifetimes are the third piece, and they alarm people more than they should. A lifetime annotation does not change behaviour - it tells the compiler how long references are expected to be valid, so it can check.

// Which input does the output borrow from? The compiler cannot tell.
fn longest(a: &str, b: &str) -> &str {
    if a.len() > b.len() { a } else { b }
}
 
// 'a says: the result lives as long as the shorter of the two inputs.
fn longest<'a>(a: &'a str, b: &'a str) -> &'a str {
    if a.len() > b.len() { a } else { b }
}

You need these only when the compiler cannot infer the relationship, which is rarer than the syntax's prominence implies. Most functions never mention a lifetime.

When ownership does not fit

Some structures - a graph, a cache with several handles, shared state across threads - do not have a single owner. Rust provides escape hatches, and reaching for them is not defeat:

• Rc<T> - reference counting for shared ownership, single-threaded.
• Arc<T> - the same across threads.
• RefCell<T> - moves the borrow check to runtime, so you can mutate through a shared reference (and panic if you break the rule).
• Arc<Mutex<T>> - the standard shape for shared mutable state across threads.

Beginners often contort a design for days to avoid Rc. If the data actually has shared ownership, model it that way.

Key takeaways

• Ownership is compile-time memory management - no manual free, no garbage collector, no pauses.
• One owner at a time, and the value drops when the owner goes out of scope.
• Assignment and function calls move ownership, unless the type is Copy.
• Borrow with & to read without taking ownership.
• One mutable reference, or many immutable - never both. That rule eliminates data races by construction.
• Borrows end at their last use, so some code compiles that looks like it should not.
• Lifetimes annotate, they do not change behaviour - they let the compiler verify what you already intended.
• Rc, Arc, RefCell exist for real shared ownership. Use them when the data is actually shared.

FAQ

Why not just use .clone() everywhere?

You can, and while learning it is a reasonable crutch. It costs an allocation and a copy each time, which is exactly the overhead Rust exists to avoid. Treat frequent clones as a hint that a borrow would fit better.

Is the borrow checker just being difficult?

Sometimes it rejects code that is actually fine - it must be conservative, since it has to prove safety. But the majority of the time it is pointing at a real aliasing or lifetime problem you had not noticed. Assume the second, check for the first.

How long does it take to stop fighting it?

Most people describe a few weeks of friction, then it recedes. The shift is mental rather than syntactic: you start designing with ownership in mind instead of writing code and negotiating afterwards.

Does ownership make Rust faster than C++?

Not inherently - comparable, in the same class. What it gives you is those speeds with memory safety, which is the trade C++ cannot offer.

Does Rust have null?

No. Absence is Option<T>, which the compiler forces you to handle. The class of bug that null references cause simply does not exist, which is arguably as valuable as the memory story.

Do I need to understand the stack and heap?

Enough to know that fixed-size values live on the stack and are cheap to copy, while growable ones like String and Vec own heap memory - which is precisely what ownership tracks. That much is worth an hour of reading.

Conclusion

Ownership feels like an obstacle because it moves work you are used to doing at runtime - or not doing at all, and paying for later - into the compile step. The compiler is asking questions your language previously let you leave unanswered: who owns this, how long does it live, who else can see it while it changes.

They were always the right questions. Rust is unusual in insisting on the answers before it will build.

Once that clicks, the errors stop reading as obstruction and start reading as review notes from a very literal colleague who has never once been wrong about a use-after-free.

Read more

If you are weighing Rust for a real project, Can Rust and Flutter Work Together? covers what it takes to put a Rust core behind an app UI - and where that boundary costs more than it saves.