Nobody's coming to clean up after you

In Part 1, most of Rust felt like Scala with different keywords. match, Option, trait, generics — familiar enough to wonder what all the fuss was about. But I left one thing unexplained: the & in fn area(s: &Shape). I pointed out that a Rust dev would write it that way, and moved on.

What I didn’t mention is that for my first few weeks with Rust, I’d read about ownership and borrowing, I’d seen the rules — but I wasn’t confident I was applying them right. I’d add a & here, a .clone() there, and the code would compile, but I couldn’t always tell you why it worked. At some point something clicked — and behind all that syntax noise, there was really just one concept Scala had never required me to think about: ownership. Who holds this value right now? What happens to it when I pass it to a function? And with no garbage collector to fall back on — who’s responsible for cleaning it up?

The one fact everything hangs from

Every language that allocates memory has to pick a strategy for cleaning it up:

In Scala, the garbage collector handles it. You allocate objects, pass them around, and at some point — eventually — the GC notices nobody’s holding a reference anymore and cleans up. It works. You pay for it in pauses, in unpredictable latency, in memory overhead, but you never think about when something gets freed.

Rust doesn’t have a garbage collector. So that question needs an answer. And the answer fits in three rules:

The thing that made this click for me was thinking about it in terms of Cats Effect’s Resource:

1
// Rule 1: exactly one bracket manages each resource
2
val program = for {
3
  pool   <- Resource.make(createPool)(_.shutdown)
4
  // Rule 3: flatMap transfers the resource to the next bracket
5
  client <- Resource.make(httpClient(pool))(_.close)
6
} yield client
7
// Rule 2: when the scope exits, resources are released
8
// in reverse order — deterministically, not "eventually"

1
{
2
    // Rule 1: exactly one owner per value
3
    let pool = create_pool(4);
4
    // Rule 3: lend to functions (borrow) or give away (move)
5
    let client = http_client(&pool);
6
    // use client...
7
}
8
// Rule 2: dropped in reverse order — deterministically, not "eventually"
9
// client dropped, then pool dropped

Except in Rust, every value works this way — not just the ones you remembered to wrap in Resource. It’s baked in, without opting-in.

Three rules, one owner, deterministic cleanup. Sounds simple enough. But then you write let b = a and discover what “exactly one owner” actually means in practice.

Move: you used up the shape just to measure it

In Scala, val b = a gives you a second handle to the same object. Both stay live. The GC sorts it out. In Rust, let b = a is an ownership transfer — a is gone.

1
val a = List(1, 2, 3)
2
val b = a
3
// b and a point to the same object — both still usable
4
println(a.length) // 3
5
println(b.length) // 3
6
// GC frees when neither is reachable

1
let a = vec![1, 2, 3];
2
let b = a;
3
// ownership MOVES to b — a is now invalid
4
println!("{}", a.len());  // value used after move
5
println!("{}", b.len()); // 3

The why is straightforward: without a garbage collector, two owners of one Vec means two attempts to free it when they go out of scope. A double-free. Rust’s fix is blunt — one owner, period. After let b = a, there’s only b.

Remember area from Part 1? When the function takes a Shape by value, it takes ownership:

1
fn area(s: Shape) -> f64 {
2
    match s {
3
        Shape::Circle { radius } => std::f64::consts::PI * radius * radius,
4
        Shape::Rectangle { width, height } => width * height,
5
    }
6
} // s is dropped here
7

8
let shape = Shape::Circle { radius: 5.0 };
9
let a = area(shape);
10
println!("{:?}", shape);  // shape was consumed

You passed the shape to area, and now it’s gone. You used it up just to measure it.

Not everything moves, though. Simple types that don’t own heap resources — integers, floats, booleans — implement the Copy trait, so let b = a copies the bits and both stay valid. Our Circle { radius: f64 } is all copyable data. But imagine adding a Polygon { vertices: Vec<Point> } — Vec owns heap memory, so the whole enum can’t be Copy anymore. Same syntax, different behavior, decided entirely by what the type owns.

When clone feels like the wrong answer

So you can’t use a value after moving it. The first thing you reach for, and the one I actually reached for — is .clone():

1
let shape = Shape::Polygon {
2
    vertices: vec![
3
        Point { x: 0.0, y: 0.0 },
4
        Point { x: 4.0, y: 0.0 },
5
        Point { x: 4.0, y: 3.0 },
6
        // ...imagine a thousand more
7
    ],
8
};
9
let a = area(shape.clone()); // clone the shape, move the clone
10
println!("{:?}", shape);     // original is still here

It compiles. But think about what just happened: you deep-copied an entire Vec<Point> — potentially thousands of heap-allocated vertices — just to read the shape’s area once.

.clone() is a legitimate tool, but it has to be used wisely — not sprinkled everywhere the compiler yells at you. Before you clone, it’s worth asking: do I actually need a second copy, or do I just need to look at this?

Borrow: how to look without taking

Instead of giving area the shape, you lend it:

1
fn area(s: &Shape) -> f64 {
2
    match s {
3
        Shape::Circle { radius } => std::f64::consts::PI * radius * radius,
4
        Shape::Rectangle { width, height } => width * height,
5
        Shape::Polygon { vertices } => polygon_area(vertices),
6
    }
7
}
8

9
let shape = Shape::Polygon {
10
    vertices: vec![/* ...a thousand points... */],
11
};
12
let a = area(&shape);       // borrow — area just looks
13
println!("{:?}", shape);    // still ours — no clone needed

The & means “borrow”. The function can read the value but can’t own it or mutate it. When area returns, the borrow ends and the caller keeps the original. Nothing got copied, neither allocated. That & from Part 1 finally has a meaning.

Mutable borrows

So we can lend things out without losing them — but what if the borrower needs to change the value? A regular & won’t let you. For that, there’s &mut:

1
fn add_suffix(s: &mut String) {
2
    s.push_str("!");
3
}

Three things must line up: the variable is let mut, the function accepts &mut T, and the call site passes &mut variable. Mutation is visible at every level — the declaration, the signature, and the call.

1
// Scala: mutation is hidden
2
val buf = ListBuffer(1, 2, 3)
3
addItem(buf)
4
// Did addItem change buf?
5
// You can't tell from the call site.

1
// Rust: mutation is explicit
2
let mut buf = vec![1, 2, 3];
3
add_item(&mut buf);
4
// &mut tells you: this call can change buf.
5
// You know just by looking at the call site.

The rule that makes it all work

Now here’s where borrowing gets clever. Rust enforces one strict constraint: at any given time, you can have either any number of &T (shared, read-only) or exactly one &mut T (exclusive, mutable). Never both at the same time.

Sounds familiar? It’s the same shape as a read-write lock — many readers or one writer. It’s not solving the same problem (Rust has RwLock and Mutex for actual thread synchronization), but you already know the mental model. The same pattern applied cleverly at compile time instead of at runtime.

1
let mut s = String::from("hello");
2
let r1 = &s;        // shared borrow
3
let r2 = &s;        // another shared borrow — fine
4
println!("{r1} {r2}");
5
// r1 and r2 are done here
6

7
let r3 = &mut s;    // exclusive borrow — no conflict, r1 and r2 are finished
8
r3.push_str(" world");

1
let mut s = String::from("hello");
2
let r1 = &s;        // shared borrow
3
let r2 = &mut s;    // can't borrow as mutable while a shared borrow is live
4
println!("{r1}");

The question the compiler can’t answer alone

Ownership handles who frees the value. Borrowing handles who can access it. But there’s one question neither can answer on its own:

1
fn longest(a: &str, b: &str) -> &str {
2
    if a.len() >= b.len() { a } else { b }
3
}

Two references come in, one comes out — but the compiler needs to know which one. Does the result follow a’s lifetime or b’s? If a gets dropped while something still holds the result pointing at it, that’s a dangling reference — exactly the kind of bug ownership exists to prevent.

The compiler can’t figure this out alone. It needs you to describe the relationship:

1
fn longest<'a>(a: &'a str, b: &'a str) -> &'a str {
2
    if a.len() >= b.len() { a } else { b }
3
}

That 'a is a lifetime annotation. It says: the result lives only as long as both inputs are valid — constrained by whichever one dies first. It doesn’t extend anything. It describes what’s already true, so the compiler can verify it.

That 'a has been lurking since Part 1. Now at least it’s clear why it exists — figuring out how it actually works is a problem for next time.

So who’s coming to clean up?

Nobody. That’s the whole point.

There’s no free() to write and no GC cycle to wait for — you arrange ownership so the compiler can prove exactly when each value dies, and it inserts the cleanup at the closing brace.

You do pay for it. You change one function signature and suddenly ten others need updating too. Sometimes you just call .clone() because the borrow checker won’t budge and you have actual work to do. What you get back is no garbage collector, no pauses, and memory bugs that the compiler catches before they exist. Coming from Scala (which already has a great compiler) I appreciate that a lot, but it can bite you more than you’d expect, and you’ll have to decide for yourself if it’s a good tradeoff.

Move, borrow, and clone are how you tell the compiler what you intend — and then it holds you to it.