Ownership on

Lesson 15: When You're Fighting the Borrow Checker — Restructure, Don't Hack

Tue, 18 Jun 2024 12:38:00 +0000

Every Rust developer has been there. You’re implementing something that feels simple. It works in your head. But the borrow checker says no. You try different approaches. More errors. You start adding .clone() everywhere. You wrap things in Rc<RefCell<...>>. You consider unsafe.

Stop. Take a breath. The borrow checker isn’t wrong — your data flow is confused. And there’s almost always a clean restructuring that makes the error disappear.

This lesson is a field guide. Real patterns that fight the borrow checker, and the restructurings that fix them.

Lesson 14: Pin and Unpin — Why Async Needs Them

Fri, 14 Jun 2024 20:05:00 +0000

Pin is the concept that makes experienced Rust developers pause. Not because it’s inherently complex — it’s actually a pretty small API — but because understanding why it exists requires connecting several ideas: self-referential structs, async/await desugaring, and move semantics.

I struggled with Pin for months. Then I understood what async does under the hood, and Pin suddenly made perfect sense. So that’s how I’m going to explain it.

The Setup: What Async Really Does

When you write an async function:

Lesson 13: Weak References — Breaking Cycles

Mon, 10 Jun 2024 09:15:00 +0000

Reference counting has a fatal flaw: cycles. If A owns B and B owns A, neither reference count hits zero. The memory is leaked — not freed when it should be, not freed ever. In a garbage-collected language, the GC would detect this cycle and clean it up. Rust’s Rc/Arc can’t do that.

Weak references are the solution. And honestly, if you understand why they exist, you understand half of what makes garbage collectors complex.

Lesson 12: Rc and Arc — Shared Ownership

Fri, 07 Jun 2024 17:50:00 +0000

Rust’s ownership model says every value has one owner. But what happens when multiple parts of your program genuinely need to own the same data? Trees with shared nodes. Graphs with cycles. Observer patterns. Caches shared between subsystems.

Single ownership doesn’t fit everything. Rc and Arc are Rust’s answer — reference-counted smart pointers that enable shared ownership with deterministic cleanup.

The Problem: Multiple Owners

// This doesn't work — who owns the shared config?
struct ServiceA {
 config: AppConfig, // owns it
}

struct ServiceB {
 config: AppConfig, // also owns a copy? expensive clone
}

You could pass references, but then you’re dealing with lifetimes everywhere. And if the config needs to outlive any individual service, you need 'static or owned data.

Lesson 11: Interior Mutability — Cell, RefCell, and the Rules

Tue, 04 Jun 2024 11:30:00 +0000

Rust’s borrowing rules say you can’t mutate through a shared reference. Period. Except — sometimes you need to. Caching, reference counting, lazy initialization, mock objects in tests. Legitimate use cases where the “no mutation through &T” rule is too restrictive.

Interior mutability is the escape hatch. It moves the borrow check from compile time to runtime. And yes, it can panic if you get it wrong. That’s the tradeoff.

The Problem: Mutation Through &self

You’re building a struct with a method that logically doesn’t modify the struct’s public state but needs to update some internal bookkeeping:

Lesson 10: Self-Referential Structs — The Problem and Solutions

Sun, 02 Jun 2024 15:40:00 +0000

Every Rust developer eventually tries to build this: a struct that owns some data AND holds a reference into that data. It seems perfectly reasonable. It’s also the single thing Rust refuses to let you do safely — and for very good reasons.

I wasted two days on this in my second month of Rust. Let me save you those two days.

The Desire

You want a struct like this:

Lesson 9: Higher-Ranked Trait Bounds — for<'a> Explained

Fri, 31 May 2024 21:15:00 +0000

If regular lifetime annotations are Rust’s intermediate boss, for<'a> is the final boss. Higher-Ranked Trait Bounds (HRTBs) look terrifying in signatures, but they solve a very specific and real problem.

I avoided understanding HRTBs for over a year. Then I tried to write a function that takes a closure accepting references with any lifetime, and suddenly I had no choice. Let me save you that year.

The Problem

Say you want a function that accepts a closure. The closure takes a &str and returns something:

Lesson 8: 'static — Not What You Think

Wed, 29 May 2024 13:25:00 +0000

'static is the most misunderstood lifetime in Rust. Most people think it means “lives forever” or “global variable.” It kind of does — but also doesn’t. And the way it interacts with trait bounds will surprise you.

I’ve seen experienced Rust developers get this wrong. So don’t feel bad if it’s been confusing.

What ‘static Actually Means

'static means: “this reference is valid for the entire duration of the program.”

Lesson 7: Lifetimes in Structs — References That Live in Types

Mon, 27 May 2024 10:42:00 +0000

Putting a reference inside a struct is where lifetimes go from “mildly confusing” to “wait, what?” for most people. I remember spending an entire afternoon trying to make a struct hold a &str and wondering why the compiler kept yelling at me.

The fundamental tension: structs outlive function calls. References might not. The compiler needs you to prove the reference won’t dangle.

The Problem

// This won't compile
struct Excerpt {
 content: &str,
}

error[E0106]: missing lifetime specifier
 --> src/main.rs:2:14
 |
2 | content: &str,
 | ^ expected named lifetime parameter

Why? Because the compiler needs to know: how long does the thing content points to live? Without that information, it can’t guarantee the reference is valid for the struct’s entire lifetime.

Lesson 6: Lifetime Elision Rules — Why You Usually Don't Write 'a

Sat, 25 May 2024 19:08:00 +0000

If lifetimes are so important, why don’t you see 'a plastered all over most Rust code? Because the compiler is smart enough to figure it out 90% of the time.

Early Rust required explicit lifetime annotations on every function that dealt with references. The community quickly realized that the same patterns showed up over and over. So the Rust team codified those patterns into “elision rules” — three rules that let the compiler infer lifetimes automatically.

Lesson 5: Lifetime Annotations — Teaching the Compiler Relationships

Thu, 23 May 2024 08:55:00 +0000

Lifetime annotations are where most people’s Rust learning hits a wall. The syntax looks alien. The error messages talk about “named lifetimes.” Your code compiles fine until you add a second reference parameter, and then suddenly the compiler wants you to annotate things with 'a.

Here’s the thing most tutorials get wrong: lifetime annotations don’t change how long anything lives. They describe relationships that already exist.

Why Lifetimes Exist

Consider this function:

Lesson 4: The Borrow Checker — What It's Really Doing

Tue, 21 May 2024 16:33:00 +0000

I used to think the borrow checker was my enemy. It rejected valid programs! It made simple things hard! It was too conservative!

Then I started maintaining a large C++ codebase and found three use-after-free bugs in one week. The borrow checker stopped looking like an enemy real fast.

Borrowing: Using Without Owning

Ownership transfer is clean but inflexible. You can’t always afford to give your data away — sometimes you just want to let another function look at it for a moment. That’s borrowing.

Lesson 3: Copy vs Clone — When Data Gets Duplicated

Sun, 19 May 2024 11:10:00 +0000

A coworker once asked me: “If Rust moves everything, how do I ever use a value twice?” Fair question. The answer is two traits that look similar but behave very differently — Copy and Clone.

Getting these confused will either tank your performance or confuse the hell out of you. Probably both.

Copy: Implicit, Cheap, and Bitwise

Copy is a marker trait. It tells the compiler: “this type is so cheap to duplicate that you should do it automatically on assignment instead of moving.”

Lesson 2: Move Semantics — Why Assignment Transfers Ownership

Fri, 17 May 2024 14:45:00 +0000

The first time Rust told me I couldn’t use a variable after assigning it to another one, I stared at my screen for a solid minute. In what universe does let b = a make a invalid?

This universe. Rust’s universe. And honestly — it’s the only sane default.

What a Move Actually Is

In most languages, let b = a copies the data or copies a reference. In Rust, for heap-allocated types, it moves the ownership. The bits get copied (the stack portion — pointer, length, capacity), but the old variable is invalidated.

Lesson 1: The Mental Model — Stack, Heap, and Ownership

Wed, 15 May 2024 09:22:00 +0000

I spent my first three months in Rust confused about ownership. Not because the concept is hard — it’s genuinely simple — but because every tutorial I read explained it through the lens of “rules to memorize.” Three rules. Memorize them. Move on.

That’s backwards. You don’t learn ownership by memorizing rules. You learn it by understanding where your data actually lives.

Where Data Lives Changes Everything

Every value in your program sits in one of two places: the stack or the heap. If you’ve done any C or C++, this is familiar territory. If you haven’t — don’t worry, this isn’t as scary as systems programmers make it sound.