DEV Community: Divyesh Kakadiya

Rc> vs Arc> — Why Rust Makes You Combine Smart Pointers

Divyesh Kakadiya — Fri, 31 Jul 2026 13:55:10 +0000

When I first got comfortable with RefCell and Mutex, I thought I was done. I could mutate things Rust normally wouldn't let me touch. Problem solved.

Then I actually tried to share that mutable value between two parts of my program, and Rust handed me this:

let shared = Rc::new(RefCell::new(0));

Two wrappers. Stacked. For one number. I had no idea why one wasn't enough.

So let's do this the same way we did closures — no jargon first. Just a real-life situation.

A Real Life Example First

Imagine your team shares one whiteboard.

Person 1 — Everyone in the Same Room

Five people work in one office. They all want to write on the same whiteboard sometimes. There's no lock on the door — you're all trusted adults in the same room, so you just take turns. If two people grab the marker at the exact same moment, someone yells "wait, I'm writing" and the other backs off.

Person 2 — People in Different Rooms

Now the team is spread across five different rooms, maybe different buildings. You can't just "take turns" anymore — nobody can see who's holding the marker. So you install an actual lock on the whiteboard cabinet. Whoever wants to write has to get the key first. Everyone else physically waits until the key comes back.

That's it. That's the whole idea behind Rc<RefCell<T>> and Arc<Mutex<T>>.

📝 Rc<RefCell<T>> = Same room — multiple people share the whiteboard, checked at "wait, I'm writing" speed

🔐 Arc<Mutex<T>> = Different rooms — multiple threads share the whiteboard, checked with an actual lock

Keep this in your head. Let's bring it into Rust now.

What Even Is Interior Mutability Doing Here?

If you read the last post, you already know RefCell and Mutex let you mutate something through what looks like an immutable reference. That solves "can I change this?"

But it doesn't solve a completely different question: "can more than one part of my program hold onto this at the same time?"

That second question is what Rc and Arc answer. Rc<RefCell<T>> and Arc<Mutex<T>> aren't one feature — they're two separate answers stacked together, and that's exactly why they show up glued like that.

Rc> — The Same Room

use std::rc::Rc;
use std::cell::RefCell;

let counter = Rc::new(RefCell::new(0));

let counter_a = Rc::clone(&counter);
let counter_b = Rc::clone(&counter);

*counter_a.borrow_mut() += 1;
*counter_b.borrow_mut() += 1;

println!("{}", counter.borrow()); // 2

Rc::clone doesn't copy the number — it hands out another reference to the same whiteboard. Rc is just counting how many people are currently holding a reference to it.

RefCell is the "wait, I'm writing" rule. It checks at runtime that nobody's already mid-write when you try to borrow_mut(). If two borrows overlap, it panics instead of letting the data get corrupted.

The Person 1 analogy: Same room, same whiteboard, multiple people holding a marker at different moments. Nobody needs a key because you can all see each other.

Where you'll see this in real code

fn increment_all(counters: &[Rc<RefCell<i32>>]) {
    for c in counters {
        *c.borrow_mut() += 1;
    }
}

This is the classic single-threaded "shared state" pattern — a tree of nodes each holding a shared parent reference, a shared cache multiple parts of your app read and update, a shared config object. As long as everything runs on one thread, Rc<RefCell<T>> is the answer.

Arc> — The Different Rooms

use std::sync::{Arc, Mutex};
use std::thread;

let counter = Arc::new(Mutex::new(0));
let mut handles = vec![];

for _ in 0..5 {
    let counter = Arc::clone(&counter);
    handles.push(thread::spawn(move || {
        let mut num = counter.lock().unwrap();
        *num += 1;
    }));
}

for handle in handles {
    handle.join().unwrap();
}

println!("{}", *counter.lock().unwrap()); // 5

Arc is Rc, but the reference count is atomic — safe to update from multiple threads at once without corrupting the count itself.

Mutex is the actual lock. .lock() is you walking up to the cabinet and waiting for the key. Whoever's holding it gets exclusive access; everyone else physically blocks until it's returned.

The Person 2 analogy: Different rooms, no way to just "see" who's writing, so you need a real lock and key changing hands.

Where you'll see this in real code

fn spawn_workers(shared_state: Arc<Mutex<Vec<String>>>) {
    for _ in 0..3 {
        let state = Arc::clone(&shared_state);
        thread::spawn(move || {
            state.lock().unwrap().push("done".to_string());
        });
    }
}

This is what you reach for the moment threads enter the picture — worker pools, shared caches across async tasks, any state multiple threads need to read and write.

Why Rc> Refuses to Cross Threads

Here's something most explanations skip: try sending Rc<RefCell<T>> into a thread and Rust stops you before you even get a chance to test it.

// this will NOT compile
let counter = Rc::new(RefCell::new(0));
std::thread::spawn(move || {
    *counter.borrow_mut() += 1;
});

Rust knows Rc's reference count isn't atomic — two threads bumping it at once could corrupt the count and cause a use-after-free. So Rc (and RefCell) simply don't implement Send, and the compiler refuses to let them cross a thread boundary at all. Not a runtime panic. Not a warning. A flat compile error.

That's the whole reason Arc and Mutex exist as separate types instead of Rust just making Rc<RefCell<T>> "thread-safe by default" — the atomic counting and the locking both cost a little performance, and Rust won't make you pay that cost unless you're actually using threads.

The Two Questions — This Is the Key Insight

Every time you're reaching for one of these four types, you're really answering two independent questions:

Question 1: Do I need more than one owner?
  No  → just use T directly, or Box<T>
  Yes → Rc<T> (single thread) or Arc<T> (multi-thread)

Question 2: Do I need to mutate it through a shared reference?
  No  → Rc<T> / Arc<T> alone is enough
  Yes → wrap the inner value in RefCell<T> (single thread) or Mutex<T> (multi-thread)

Once you see it this way, you stop memorizing four types and start just picking a row and a column:

	Single-threaded	Multi-threaded
Multiple owners	`Rc<T>`	`Arc<T>`
+ Mutation	`Rc<RefCell<T>>`	`Arc<Mutex<T>>`

Real Example — Putting Both Together

Let's use the same notification system from the closures post, so it's familiar.

use std::rc::Rc;
use std::cell::RefCell;
use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    // Rc<RefCell<T>> — single-threaded shared counter
    let sent_count = Rc::new(RefCell::new(0));

    let count_a = Rc::clone(&sent_count);
    let count_b = Rc::clone(&sent_count);

    *count_a.borrow_mut() += 1; // email sent
    *count_b.borrow_mut() += 1; // sms sent

    println!("Notifications sent (single thread): {}", sent_count.borrow());

    // Arc<Mutex<T>> — multi-threaded shared counter
    let queue = Arc::new(Mutex::new(Vec::new()));
    let mut handles = vec![];

    for channel in ["email", "sms", "push"] {
        let queue = Arc::clone(&queue);
        handles.push(thread::spawn(move || {
            queue.lock().unwrap().push(format!("{} sent", channel));
        }));
    }

    for handle in handles {
        handle.join().unwrap();
    }

    println!("{:?}", queue.lock().unwrap());
}

Output:

Notifications sent (single thread): 2
["email sent", "sms sent", "push sent"]

The Trade-Off Nobody Mentions Upfront

RefCell and Mutex don't remove Rust's borrowing rules — they just move the check to runtime.

let cell = RefCell::new(5);
let _b1 = cell.borrow_mut();
let _b2 = cell.borrow_mut(); // panics at runtime: already borrowed

With RefCell, breaking the rule means a panic. With Mutex, breaking the rule the wrong way (locking in inconsistent order across threads) means a deadlock — your program doesn't even panic, it just hangs forever. You traded a compile-time guarantee for a runtime one, and you're the one responsible for holding up your end of it.

Quick Reference — The One Table You Need

Type	Solves	Thread-safe	Failure mode if misused
`Rc<T>`	Multiple owners	No	N/A — read-only
`Arc<T>`	Multiple owners	Yes	N/A — read-only
`Rc<RefCell<T>>`	Multiple owners + mutation	No	Panics on conflicting borrow
`Arc<Mutex<T>>`	Multiple owners + mutation	Yes	Deadlocks on bad lock order

When to Use Which — The Simple Rule

Use Rc<RefCell<T>> when:

Everything runs on one thread
You're building trees/graphs with shared parent or sibling references
You have shared state (cache, config, counter) that never leaves the main thread

Use Arc<Mutex<T>> when:

You're spawning real OS threads or sharing state across async tasks
Multiple workers need to read and write the same data
You need the compiler to physically stop unsynchronized access, not just runtime-check it

Why This Is "The Heart of Rust" (Again)

Same story as closures. Most languages let you share mutable state by default and hope you're careful. Rust splits the problem into two honest questions — ownership and mutation — and makes you answer both explicitly before it lets you compile.

It's not extra ceremony for its own sake. It's the compiler refusing to let you pay for thread-safety you don't need, and refusing to let you skip it when you do.

📝 Rc<RefCell<T>> = same room, take turns, checked at write-time

🔐 Arc<Mutex<T>> = different rooms, real lock, checked with a key

Two separate questions. Always.

If this clicked for you, drop a comment — I'd love to know if you've hit the "Rc doesn't implement Send" error before you understood why. And if you missed the previous post on Interior Mutability with Cell, RefCell, and Mutex, that's the one to read first — this post builds directly on it. 👇

Interior Mutability — Cell, RefCell, and Mutex Finally Explained

Divyesh Kakadiya — Wed, 15 Jul 2026 05:48:25 +0000

The first time I ran into this, I had a struct with a method that took &self, and inside that method I just wanted to bump a counter by one.

struct Logger {
    count: u32,
}

impl Logger {
    fn log(&self, message: &str) {
        self.count += 1; // ❌ won't compile
        println!("[{}] {}", self.count, message);
    }
}

Rust said no.

error[E0596]: cannot borrow `self.count` as mutable,
as it is behind a `&` reference

I remember thinking — it's ONE number. I'm not doing anything dangerous. Why is the compiler being like this?

Every explanation I found jumped straight into "interior mutability allows mutation through an immutable reference using unsafe internally, abstracted safely." Cool sentence. Meant nothing to me at the time.

So let's do this the same way we did closures. Real life first. Rust second.

A Real Life Example First

Imagine you own a notebook, and you've decided the notebook itself is not allowed to be edited — that's the rule you've set. But you still need a way to track how many times people have flipped through it.

You've got three options for handling this.

Option 1 — The Sticky Note

You tape a small sticky note to the cover. Anyone holding the notebook can peel it off, write a new number, and stick it back — without ever "opening" the notebook itself. It's fast, nobody needs permission, and there's no risk because it's just a number being swapped out.

Option 2 — The Sign-In Sheet Inside

You keep a sign-in sheet clipped inside the notebook. Anyone can flip to it and write on it — but only one person can be writing on that sheet at a time. If two people try to grab a pen for it simultaneously, you stop them and make them wait their turn. You enforce this yourself, on the spot, every time someone reaches for it.

Option 3 — The Shared Notebook Across Two Offices

Now imagine the notebook isn't just passed around one room — it's shared between two separate offices, and people in both offices need to write in it. A sticky note isn't safe here, because two people in two different offices could grab it at the exact same instant. You need an actual lock on the sign-in sheet — something that physically stops a second person from touching it until the first person is done.

That's it. That's the whole idea.

📝 Sticky Note = Cell<T> — swap the value out, no borrowing involved

📋 Sign-In Sheet = RefCell<T> — borrow it, but rules get enforced on the spot

🔒 Locked Sheet = Mutex<T> — same idea, but safe across threads

Keep that in your head. Now let's bring it into Rust.

What "Interior Mutability" Actually Means

Rust's normal rule is simple: if you have &self, you can't mutate anything inside it. Mutation requires &mut self.

Interior mutability is the name for a small set of types that break this rule — safely — by moving the check from compile time to a different point: either "no references handed out at all" (Cell), or "checked the instant you ask for a borrow" (RefCell, Mutex).

The type still enforces Rust's core rule — no mutable access while something else is reading. It just enforces it at a different moment than the compiler normally does.

`Cell<T>` — The Sticky Note

use std::cell::Cell;

struct Logger {
    count: Cell<u32>,
}

impl Logger {
    fn log(&self, message: &str) {
        self.count.set(self.count.get() + 1);
        println!("[{}] {}", self.count.get(), message);
    }
}

fn main() {
    let logger = Logger { count: Cell::new(0) };
    logger.log("server started");
    logger.log("listening on port 8080");
}

Output:

[1] server started
[2] listening on port 8080

No borrowing happens here at all. .get() copies the value out. .set() writes a new value in. There's never a reference to fight over — which is exactly why this is the cheapest, simplest option, and also why it only works for small, Copy types like numbers, booleans, and simple enums.

The sticky note analogy: nobody ever "holds" the note while reading it — they just glance at the number and swap it out. Since nobody's holding onto it, there's nothing to conflict over.

`RefCell<T>` — The Sign-In Sheet

Cell falls apart the moment you want to store something bigger — a Vec, a String, a whole struct. You don't want to copy a Vec every time you read it. You want to actually borrow it, the normal Rust way — you just want to do that borrowing through a shared reference.

That's RefCell<T>.

use std::cell::RefCell;

struct Cache {
    items: RefCell<Vec<String>>,
}

impl Cache {
    fn add(&self, item: String) {
        self.items.borrow_mut().push(item);
    }

    fn print_all(&self) {
        for item in self.items.borrow().iter() {
            println!("{}", item);
        }
    }
}

fn main() {
    let cache = Cache { items: RefCell::new(vec![]) };
    cache.add(String::from("first"));
    cache.add(String::from("second"));
    cache.print_all();
}

Output:

first
second

.borrow() gives you shared, read-only access. .borrow_mut() gives you exclusive, mutable access. Under the hood, RefCell keeps a tiny counter tracking how many borrows are currently active — exactly like someone standing next to the sign-in sheet, watching who's holding the pen.

Try to grab the pen twice at once, and it stops you:

let cache = RefCell::new(vec![1, 2, 3]);

let first = cache.borrow_mut();
let second = cache.borrow_mut(); // 💥 panics at runtime

thread 'main' panicked at 'already borrowed: BorrowMutError'

This is the trade you're making. A mistake that the compiler would normally catch before your code even runs now shows up as a panic while your program is running. That's a real cost, not a free lunch — RefCell isn't a way to trick the compiler, it's a way to move the same check somewhere else, at the price of it being able to fail live instead of at compile time.

Where this shows up in real code: trees, graphs, and anything where a child needs to reach back and touch its parent, or siblings need to notify each other. This is common enough to have its own name — Rc<RefCell<T>>, which we'll get to in a second.

Why Doesn't `RefCell` Just Work Across Threads Too?

Because its "sign-in sheet" counter is a plain number, and two threads incrementing a plain number at the same time is a data race — the exact thing Rust exists to prevent.

Rust actually catches this at compile time. Try to share a RefCell across threads and you get:

error[E0277]: `RefCell<u32>` cannot be shared between threads safely

Which brings us to office #3.

`Mutex<T>` — The Locked Sign-In Sheet

Mutex<T> solves the exact same problem as RefCell — mutation through a shared reference — but backs it with an actual lock, so it's safe when multiple threads reach for it at the same time.

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];

    for _ in 0..10 {
        let counter = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            let mut num = counter.lock().unwrap();
            *num += 1;
        });
        handles.push(handle);
    }

    for handle in handles {
        handle.join().unwrap();
    }

    println!("Result: {}", *counter.lock().unwrap());
}

Output:

Result: 10

.lock() is the equivalent of .borrow_mut() — except instead of a quick counter check, it's an actual OS-level lock. If another thread already holds it, your thread physically waits until it's free. Same idea as the sign-in sheet, just enforced with a real lock instead of an honor system, because now two different "offices" (threads) are involved.

Notice the Arc wrapping the Mutex. That's not optional — and it's worth its own explanation.

`Rc<RefCell<T>>` and `Arc<Mutex<T>>` — The Combo You'll Actually See

Here's the part that trips people up: RefCell and Mutex solve mutation. They don't solve sharing. If you want multiple parts of your program to own the same data, you still need something to give you multiple owners in the first place.

That's what Rc and Arc are for — reference-counted pointers.

Single-threaded — Rc<RefCell<T>>

use std::rc::Rc;
use std::cell::RefCell;

fn main() {
    let shared = Rc::new(RefCell::new(vec![1, 2, 3]));

    let a = Rc::clone(&shared);
    let b = Rc::clone(&shared);

    a.borrow_mut().push(4);
    b.borrow_mut().push(5);

    println!("{:?}", shared.borrow());
}

Output:

[1, 2, 3, 4, 5]

Rc hands out multiple owners of the same notebook. RefCell lets any of those owners actually write in it, with the sign-in sheet enforcing turns. Together, they cover a case plain ownership rules can't: multiple things needing to both own and mutate the same data.

Multi-threaded — Arc<Mutex<T>>

Same pattern, thread-safe versions of both pieces — this is the one from the counter example above. Arc is Rc with an atomic (thread-safe) counter. Mutex is RefCell with a real lock instead of a soft check. If you've read almost any multithreaded Rust code, you've seen Arc<Mutex<T>> sitting somewhere in it — it's the default answer to "multiple threads need to share and mutate this."

Quick Reference — The One Table You Need

Type	Access style	Cost	Real life
`Cell<T>`	Copy in, copy out	Cheapest — no runtime check	The sticky note — swap the number, no borrowing
`RefCell<T>`	Borrow, checked at runtime	Panics if rules are broken	The sign-in sheet — one pen at a time, on the honor system
`Mutex<T>`	Borrow, thread-safe locking	Real OS lock, some overhead	The locked sheet — safe across two offices

When to Actually Reach for Each One

Use Cell<T> when:

The value is small and Copy — counters, flags, simple IDs
You never need to hand out a reference to it, only read/write the whole value

Use RefCell<T> when:

You're single-threaded
Multiple owners need to mutate shared, non-Copy data (trees, graphs, caches)
You're comfortable treating a BorrowMutError panic as a real bug to fix, not background noise

Use Mutex<T> (with Arc) when:

The same problem shows up across threads
Don't reach for it in single-threaded code out of habit — it's real locking overhead you don't need

And honestly — before reaching for any of these, ask if the data structure itself could be redesigned so nobody needs shared mutation in the first place. Interior mutability should be a deliberate choice, not the first thing you try when the borrow checker pushes back.

Why This Is Rust Being Rust (Again)

Same story as the closures post. Rust's whole thing is: the safety guarantee doesn't disappear just because the compiler can't prove it upfront. It just moves — from compile time to a small, explicit runtime check, in exactly the types built for that job.

You're never turning safety off. You're telling Rust exactly where and how to keep checking.

📝 Cell = swap the sticky note, no questions asked

📋 RefCell = borrow it, but the sign-in sheet is watching

🔒 Mutex = same sheet, now with an actual lock on it

The notebook still has rules. It just checks them at a different moment.

If this made things click, drop a comment — I'd love to know which analogy landed. And if you haven't read the one on Fn, FnMut, and FnOnce yet, that's a good companion piece — closures and interior mutability both come down to the same question: who's allowed to touch what, and when. 👇

Rust Lifetimes Aren't Scary, They're Just Honest

Divyesh Kakadiya — Tue, 07 Jul 2026 05:31:17 +0000

TL;DR: Lifetimes don't extend how long data lives — they just label the connection between borrowed inputs and outputs so Rust can verify nothing outlives what it borrowed from. Full breakdown below 👇

You've probably seen this error before:

error[E0106]: missing lifetime specifier

And your first reaction was probably: "I just wrote a function. Why is the compiler talking to me about time travel?"

Stay with me. By the end of this post, you'll see that lifetimes aren't some advanced wizardry bolted onto Rust. They're Rust doing you a favor — just in a language it hasn't learned to say nicely yet.

A real-life example first (no code, just think about this)

Imagine you borrow a book from a friend.

You can read it, highlight it, even lend it to someone else for a bit. But there's one rule you never break: you can't still be holding that book after your friend has thrown it away.

That would be absurd, right? The book doesn't exist anymore. Holding onto it would mean holding onto nothing — a book-shaped hole in your hands.

That's it. That's the entire idea behind lifetimes, before we even touch Rust.

Your friend owns the book. They decide when it gets thrown away.
You're just borrowing it. You have to give it back — or at least, stop using it — before it's gone.
Rust's job is to make sure you never end up holding a thrown-away book.

Keep this in your head. We're not leaving this analogy for the rest of the post.

Let's bring this into code — but with a simple example

Forget the textbook example of comparing two strings. Let's use something more relatable: a function that returns whichever name is longer, out of two names you give it.

fn longer_name(a: &str, b: &str) -> &str {
    if a.len() > b.len() {
        a
    } else {
        b
    }
}

Looks completely reasonable. You give it two borrowed strings, it hands one back. Try to compile it, though, and Rust stops you:

error[E0106]: missing lifetime specifier

This is the moment that actually matters. Not the fix — this exact confusion. I'm not creating anything. I'm not even keeping the data. I'm just returning one of the two things you gave me. Why does Rust care?

Here's the plain-language reason why

Go back to the borrowed book. Now imagine your friend hands you two books and says, "give me back whichever one is thicker."

Simple enough for you to do. But now imagine someone standing outside the room, watching you walk out holding a book. They have no idea which friend that book belongs to, or how long they're allowed to keep it before its owner wants it back or throws it away.

That's exactly the problem Rust has with longer_name. When it reads:

fn longer_name(a: &str, b: &str) -> &str

Rust sees: "I'm handed two borrowed things, and I'm handing back one borrowed thing." But it has no way of knowing which one you're handing back — a's book, or b's book. And since a and b might be thrown away (go out of scope) at different times, Rust genuinely cannot guarantee the thing you return will still exist by the time someone tries to use it.

Rust isn't confused about your code. Rust is refusing to guess. It won't let you hold onto a book that might already be in the trash — and it won't compile your program until you tell it exactly whose book is being borrowed.

So what do we actually write?

This is where lifetimes come in — and here's the part that made it click for me: a lifetime annotation isn't a value, a type, or a special power. It's a label.

It's you, standing in that room, saying to the person watching: "This exact book — I'm holding it for exactly as long as my friend allows. Not a second longer."

In code, that label is written as 'a:

fn longer_name<'a>(a: &'a str, b: &'a str) -> &'a str {
    if a.len() > b.len() {
        a
    } else {
        b
    }
}

Read this out loud in plain English: "Whatever I return lives for exactly as long as the shorter-lived of a and b allows."

That's the whole sentence. You're not telling Rust how long something lives — Rust already knows that. You're telling Rust that the thing you return is tied to the same borrowing rules as what came in. You're just labeling the connection.

This compiles, because now the watcher outside the room knows exactly whose book you're holding — and can confirm that friend hasn't thrown it away yet.

The part almost nobody explains clearly

Here's the sentence that finally made lifetimes make sense to me:

Lifetimes don't make anything live longer. They only describe how long things already live, so Rust can check your work.

You're not controlling time. You're labeling it. It's the difference between a clock and a calendar reminder — the reminder doesn't change when the event happens, it just makes sure you don't miss it.

This is also why lifetimes disappear from so much everyday Rust code. If a function only borrows data and returns something unrelated to it (like a bool, or an owned String it built itself), there's no connection to label — so there's nothing to write.

You only write a lifetime when you're handing back a borrowed book, and Rust needs to know which friend to check back with.

Quick side-by-side, in plain words

	Owning a book	Borrowing a book (`&`)	Borrowing with a labeled lifetime (`&'a`)
Real-life version	It's yours. Keep it as long as you want.	You have it temporarily, must return before it's thrown away.	You have it temporarily, and you've told everyone exactly whose copy it is.
In Rust	`String`, `Vec<T>`, etc.	`&str`, `&T`	`&'a str`, `&'a T`
Who decides when it's gone	You do.	The owner does.	The owner does — Rust just tracks and confirms it.
What the compiler checks	Nothing extra.	That you don't use it after it's gone.	That the connection between input and output borrows is honored.

The actual error, decoded

Next time you see one of these, here's what Rust is really saying:

missing lifetime specifier → "You're returning (or storing) a borrowed value, and I can't tell whose rules it's supposed to follow. Label it."
borrowed value does not live long enough → "You're trying to keep the book after your friend already threw it away."
cannot return value referencing local variable → "You're trying to hand back a book that only existed inside this room — it won't exist once you walk out."

None of these are Rust being difficult. Every single one is Rust catching a bug that, in another language, would've quietly turned into a crash — or worse, a security hole — at runtime.

Three myths about lifetimes, cleared up

Myth 1: "Lifetimes make my data live longer."
No. They don't extend anything. They only describe how long something already lives, so Rust can verify your code respects it.

Myth 2: "I need to write 'a everywhere."
No. Rust infers lifetimes automatically in the vast majority of code (this is called lifetime elision). You only write them explicitly when there's a genuine ambiguity — like our longer_name example, where two different borrows are competing.

Myth 3: "This is a uniquely Rust problem, other languages don't have this."
Other languages have this exact problem — dangling pointers, use-after-free bugs. They just don't tell you about it at compile time. They let it become a runtime crash instead. Rust just refuses to let it slide.

So when do lifetimes actually show up?

Ask yourself one simple question:

"Am I handing back (or storing) something I only borrowed — and is there more than one place it could have come from?"

If yes — like longer_name, or a struct that holds a borrowed reference — Rust needs a label to know which "friend" to check back with.
If no — if you're returning something you built yourself, or something unrelated to what was borrowed — there's nothing to label, and you'll never see 'a in your code.

Why this is genuinely "the heart of Rust"

This is the same promise you've already seen in ownership and in dispatch: Rust refuses to let your program lie about what's happening in memory. Lifetimes are how that promise extends to borrowed data specifically — Rust won't let you hold a reference to something that might not exist anymore, and it catches that mistake before your program ever runs, not after it crashes in production.

You're not fighting the compiler. You're standing in a room, holding a borrowed book, and a very honest friend is simply asking: "are you sure that book still exists?"

Once you can answer that question, you already understand lifetimes.

If this helped, I write a lot more Rust content like this — breaking down confusing concepts using plain, real-life analogies instead of jargon. Follow along for more.

Rust Closures — Why Are There Three? Fn, FnMut, and FnOnce Finally Explained

Divyesh Kakadiya — Mon, 29 Jun 2026 12:29:03 +0000

When I first saw this in Rust:

fn apply<F: Fn()>(f: F) {
    f();
}

I thought — okay, Fn, fine. Then I saw FnMut. Then FnOnce. And I had no idea why there were three of them, when to use which, or what the difference actually was.

Every explanation I found went straight into "closures capture their environment by reference, by mutable reference, or by value."

That sentence is technically correct. It also told me nothing useful.

So let's do this differently. No jargon first. Just a real-life situation.

📖 A Real Life Example First

Imagine you hire three different people to do a job for you.

Person 1 — The Reader
You hand them your notebook. They read it as many times as they want. They never change anything. You can call ten of these people simultaneously — they all just read the same notebook.

Person 2 — The Editor
You hand them your notebook. They read it and make changes. Only one person can edit at a time. But you can ask them to edit multiple times.

Person 3 — The One-Time Guy
You hand them the notebook and they take it with them. They do their job — maybe they tear out all the pages and mail them somewhere. Once they're done, the notebook is gone. You can't call them again.

That's the whole idea behind Fn, FnMut, and FnOnce.

📖 Fn = The Reader — borrows, never changes, can be called many times

✏️ FnMut = The Editor — borrows and changes, can be called many times

📦 FnOnce = The One-Time Guy — takes ownership, can only be called once

Keep this in your head. Let's bring it into Rust now.

🤔 What Even Is a Closure?

Before the three traits, let's make sure closures themselves are clear.

A closure is just a function you define inline, that can reach out and use variables from the surrounding code.

let name = String::from("Ravi");

let greet = || {
    println!("Hello, {}!", name); // using `name` from outside
};

greet(); // Hello, Ravi!

That || { ... } is a closure. The || is where parameters go (empty here). And notice — it's using name which lives outside the closure. That's called capturing the environment.

Now, how the closure captures that variable — read-only, read-write, or taking full ownership — is exactly what determines which of the three traits it gets.

📖 `Fn` — The Reader (Immutable Borrow)

let message = String::from("Server started");

let log = || {
    println!("{}", message); // just reading message
};

log(); // Server started
log(); // Server started again — works fine
log(); // Works a third time too

This closure only reads message. It never changes it, never takes it away.

Rust sees this and thinks: "This closure is safe to call as many times as we want."

So Rust gives it the Fn trait.

The Reader analogy: The notebook stays on your desk. Anyone can read it. Nothing ever changes. You can call this closure a hundred times.

Where you'll see this in real code

fn run_twice<F: Fn()>(f: F) {
    f();
    f();
}

let city = String::from("Ahmedabad");
run_twice(|| println!("City: {}", city));

run_twice calls f twice — only possible because f is Fn. If it were FnOnce, the second call would fail because the closure would be used up after the first.

✏️ `FnMut` — The Editor (Mutable Borrow)

let mut count = 0;

let mut increment = || {
    count += 1; // changing count — mutable borrow
    println!("Count: {}", count);
};

increment(); // Count: 1
increment(); // Count: 2
increment(); // Count: 3

This closure is modifying count. It needs to change something outside itself.

Rust gives it FnMut — mutable, but still borrowing. Not owning.

The Editor analogy: The notebook stays with you, but the editor is actively scribbling in it. You can ask them to edit multiple times. But only one editor at a time.

Where you'll see this in real code

fn apply_three_times<F: FnMut()>(mut f: F) {
    f();
    f();
    f();
}

let mut total = 0;
apply_three_times(|| {
    total += 10;
});

println!("Total: {}", total); // Total: 30

Notice mut f in the function signature — when you accept FnMut, you need to mark the parameter as mut because calling it changes internal state.

📦 `FnOnce` — The One-Time Guy (Takes Ownership)

let name = String::from("Divyesh");

let introduce = move || {
    println!("Hi, I am {}!", name);
    // name is now owned by this closure
};

introduce(); // Hi, I am Divyesh!
// introduce(); // ERROR — can't call again, name is gone

This closure used move — it took full ownership of name. Once it runs, name is consumed. Nothing left for a second call.

Rust gives it FnOnce — once, and only once.

The One-Time Guy analogy: You handed the notebook over. They took it. It left your hands. There's no calling them back.

Where you'll see this in real code — `thread::spawn`

This is the most important real-world use of FnOnce:

use std::thread;

let message = String::from("Hello from thread");

thread::spawn(move || {
    println!("{}", message); // message moved into the thread
});

thread::spawn requires FnOnce + Send + 'static. Why FnOnce? Because a spawned thread runs once. Ownership moves in, the thread runs, done.

🔑 The Hierarchy — The Key Insight Nobody Explains

Every Fn is also FnMut. Every FnMut is also FnOnce.

Think about it:

If a closure only reads (Fn), it can obviously also be called just once (FnOnce)
If a closure can be called repeatedly with mutation (FnMut), it can obviously be called just once (FnOnce)

So the traits form a hierarchy:

FnOnce          ← least restrictive — every closure implements this
  └── FnMut     ← closure can be called multiple times
        └── Fn  ← most restrictive — safe to call anywhere, anytime

In practice: use the least restrictive bound that still does what you need.

// Need to call it once?
fn do_once<F: FnOnce()>(f: F) { f(); }

// Need to call it multiple times with state change?
fn do_many<F: FnMut()>(mut f: F) { f(); f(); f(); }

// Need to call it anywhere, read-only?
fn do_shared<F: Fn()>(f: F) { f(); f(); }

🔔 Real Example — All Three Together

fn send_once<F: FnOnce()>(sender: F) {
    sender();
}

fn send_repeatedly<F: FnMut()>(mut sender: F, times: u32) {
    for _ in 0..times {
        sender();
    }
}

fn preview<F: Fn()>(sender: F) {
    println!("--- Preview ---");
    sender();
    sender();
    println!("--- End ---");
}

fn main() {
    // FnOnce — consumes the recipient string
    let recipient = String::from("ravi@example.com");
    send_once(move || {
        println!("Sending email to {}", recipient);
    });

    // FnMut — counts SMS sent
    let mut sms_count = 0;
    send_repeatedly(|| {
        sms_count += 1;
        println!("SMS #{} sent", sms_count);
    }, 3);

    // Fn — read-only preview
    let channel = String::from("Push Notification");
    preview(|| {
        println!("Channel: {}", channel);
    });
}

Output:

Sending email to ravi@example.com
SMS #1 sent
SMS #2 sent
SMS #3 sent
--- Preview ---
Channel: Push Notification
Channel: Push Notification
--- End ---

⚡ The `move` Keyword — Quick Clarification

move forces the closure to take ownership of captured variables instead of borrowing them.

let data = String::from("important");

// Without move — borrows data
let borrow_closure = || println!("{}", data);

// With move — owns data
let own_closure = move || println!("{}", data);

move doesn't automatically make something FnOnce. It just means the closure owns its captured variables. Whether it's Fn, FnMut, or FnOnce still depends on what the closure does with those variables inside.

⚖️ Quick Reference Table

Trait	Captures how	Call how many times	Real life
`Fn`	Immutable borrow `&T`	Unlimited	The Reader
`FnMut`	Mutable borrow `&mut T`	Unlimited	The Editor
`FnOnce`	By value (ownership)	Once only	The One-Time Guy

🤔 When to Use Which — The Simple Rule

Use FnOnce when:

Spawning threads (thread::spawn)
The closure needs to consume or drop something
Something that should only happen once

Use FnMut when:

Building counters or accumulators
Iterators with state
Anything updating a variable across multiple calls

Use Fn when:

Callbacks called from multiple places
Anything you want to store and reuse safely
Default choice when mutation isn't needed

🦀 Why This Matters

Rust's whole promise: flexibility shouldn't cost you performance.

Instead of one vague "callable" type, Rust gives you three — each with a precise contract about what the closure does with its environment. The compiler enforces that contract at compile time. Zero runtime cost.

📖 Fn = just reads. Call it forever.

✏️ FnMut = reads and writes. Call it many times.

📦 FnOnce = takes ownership. Call it once, then it's done.

The notebook never lied to you. 📓

Follow me for more Rust deep dives 🦀

Missed the previous post? Check out Static Dispatch, Dynamic Dispatch & Monomorphization in Rust — closures and dispatch use the same underlying trait system, so that one pairs well with this.

Drop a ❤️ if this helped, and leave a comment below with which part finally made it click for you. 👇

Static Dispatch, Dynamic Dispatch & Monomorphization in Rust — Explained Like a Human

Divyesh Kakadiya — Thu, 25 Jun 2026 11:50:05 +0000

When I first read about this topic, every article used words like "polymorphism," "vtable," and "compile-time resolution" in the very first line.

I understood none of it. I just nodded and moved on — and the confusion stayed with me for weeks.

So this time: no fancy words first. Let's start from real life.

📱 A Real Life Example First (No Code, Just Think About This)

Imagine you want to call someone for help.

Case 1: You know exactly who to call. You open your contacts, tap "Mom", and the phone dials her number directly. No confusion, no waiting, no middleman. You knew exactly who you were calling before you even picked up the phone.

Case 2: You call a company's customer care number. You don't know who will pick up. Could be Agent A, could be Agent B — whoever is free at that moment. The company decides while you're on the call, not before.

That's it. That's the whole idea — before we even touch Rust.

📱 Calling "Mom" directly = decision made beforehand = Static Dispatch

☎️ Calling customer care and getting routed = decision made at call time = Dynamic Dispatch

In Rust, your code does the exact same two things — it either knows exactly which function to run before the program starts, or it figures it out while the program is running.

Keep this phone analogy in your head. We'll come back to it throughout.

🔔 Let's Bring This Into Code — With a Simple Example

Forget shapes and circles. Let's use something everyone understands: sending a notification — like an app sending you either an Email or an SMS.

trait Notification {
    fn send(&self);
}

struct Email {
    address: String,
}

struct SMS {
    phone_number: String,
}

impl Notification for Email {
    fn send(&self) {
        println!("Sending Email to {}", self.address);
    }
}

impl Notification for SMS {
    fn send(&self) {
        println!("Sending SMS to {}", self.phone_number);
    }
}

Simple enough — two different ways of notifying someone, both following the same basic contract: "you can send me."

Now let's write a function that sends a notification:

fn notify<T: Notification>(item: T) {
    item.send();
}

This works perfectly fine if I call it like this:

notify(Email { address: String::from("ravi@example.com") });
notify(SMS { phone_number: String::from("9999999999") });

Both lines work. No problem yet. 👍

😕 Here's Where It Gets Confusing (This Was My Exact Confusion)

Now I wanted one list, containing both an Email and an SMS — so I could loop through and send all notifications at once. Felt like a totally normal thing to want.

let notifications = vec![
    Email { address: String::from("ravi@example.com") },
    SMS { phone_number: String::from("9999999999") },
];

This does not compile. 🚫

Rust says these are different types and refuses to put them in the same list.

This is the moment that actually matters. Not vocabulary — this exact confusion.

Why can't I put both in one list? They both know how to send(). Why does Rust care?

🔬 Monomorphization — The Compiler's Hidden Superpower

Here's the plain-language reason why.

Remember the "calling Mom directly" example? When you write a generic function like notify<T: Notification>, Rust treats it almost like writing a separate, hardcoded version of that function for every single type you actually use with it.

So behind the scenes, when you call notify with an Email and then with an SMS, Rust quietly creates two separate versions — something like this:

// Rust creates this secretly — you never write it yourself
fn notify_for_email(item: Email) {
    item.send(); // Rust already knows: call Email's send
}

fn notify_for_sms(item: SMS) {
    item.send(); // Rust already knows: call SMS's send
}

You never write this yourself and you never even see it. Rust does it silently while compiling. This is called monomorphization.

Don't worry about the word. Just remember what it means in plain English:

🔬 Monomorphization = Rust takes your one generic function and quietly stamps out a separate, specific copy of it for every type you use it with — before your program even runs.

This is exactly why Email and SMS couldn't sit in the same Vec using a plain generic. Once Rust locks in T as Email in one copy of the function, that copy can only ever deal with Email. Like dialing "Mom" — once that copy exists, there's no ambiguity left.

This whole approach — Rust knowing exactly which send() to call because it generated a dedicated copy of the function — is static dispatch. It's "calling Mom directly." Fast, no confusion, decided way ahead of time.

The cost: if you use notify with five different types, Rust creates five separate copies in your compiled program. More code gets generated. That's the price for that speed and certainty.

✅ So How Do I Actually Mix Email and SMS in One List?

This is where we go back to the "customer care line" idea — the version where the decision happens while the call is happening, not before.

In Rust, this is written using dyn Trait:

fn notify_all(items: Vec<Box<dyn Notification>>) {
    for item in items {
        item.send();
    }
}

let notifications: Vec<Box<dyn Notification>> = vec![
    Box::new(Email { address: String::from("ravi@example.com") }),
    Box::new(SMS { phone_number: String::from("9999999999") }),
];

notify_all(notifications);

✅ This compiles. One list, two different types, both treated as "something that can send a notification."

🧠 What Is `Box<dyn Notification>` Really? (The Part That Finally Clicked For Me)

Think of Box<dyn Notification> as a sticky note with two pieces of information on it:

Where the actual data lives — a pointer to the real Email or SMS value sitting in memory
A small instruction sheet for that specific type — a tiny lookup table that says "if someone asks for send, here's exactly which function to run for this type"

That second part is what people call a vtable (virtual table). You don't need the word — just remember:

☎️ vtable = a lookup sheet, attached to each value, telling the program which actual function to run at runtime.

So when you call item.send() on a Box<dyn Notification>, the program doesn't already know at compile time whether this item is an Email or SMS. So it looks at the attached lookup sheet while running, finds the right function, and calls it.

That lookup — happening while your program runs — is exactly the "customer care line" situation. This is dynamic dispatch. It's marginally slower than calling Mom directly — not because of some mysterious penalty, but for the most boring reason possible: there's literally one extra step (checking the lookup sheet) before the actual function runs.

Why do we need `Box`?

An Email and an SMS aren't the same size in memory. Rust always needs to know the exact size of a value upfront. By using Box, you're holding a pointer — and a pointer is always the same fixed size, no matter what it points to. That's it.

⚖️ Quick Side-by-Side, In Plain Words

	Static Dispatch (generics)	Dynamic Dispatch (`dyn Trait`)
Real life version	Calling "Mom" directly	Calling customer care
When Rust decides	Before the program runs	While the program is running
What Rust does	Stamps out a copy per type (monomorphization)	Attaches a lookup sheet (vtable) to each value
Speed	⚡ Slightly faster	🐢 Tiny overhead
Binary size	📦 Larger (more copies)	✅ Smaller (one version)
Mix different types?	❌ No — locked to one type	✅ Yes — that's the whole point

🤔 So When Do You Pick Which One?

Ask yourself one simple question:

"Do I need to keep genuinely different types together — in the same place — and decide what to do with them only while the program is running?"

If yes — like our notification list, a list of payment methods, or plugins added at runtime — use dyn Trait.

If no — if you're fine handling one type at a time and just want one piece of code that works across many types — use generics. You get the "calling Mom directly" speed, automatically, for free.

🦀 Why This Is Genuinely "The Heart of Rust"

This is the actual reason people say this topic matters so much in Rust.

Rust makes a big promise: writing flexible, reusable code shouldn't cost you anything at runtime.

The static dispatch + monomorphization mechanism is how that promise is kept — your generic code gets turned into the exact same machine code you would've written by hand for each specific type, with zero extra runtime cost.

dyn Trait exists for the cases where that promise genuinely can't apply — where you truly don't know the type until the program is running. And in Rust, you have to ask for that flexibility on purpose, by writing dyn. It's never sneaked in on you.

You always know, just by reading the code, whether you're "calling Mom directly" or "calling customer care."

And now, so do you. 📱☎️

🔑 The One-Line Summary

Static dispatch = compiler decides at build time → fast, bigger binary, generics
Dynamic dispatch = program decides at runtime → flexible, smaller binary, dyn Trait
Monomorphization = how static dispatch actually works under the hood → one generic becomes many type-specific copies

If this helped you, drop a ❤️ — it took me months to piece this together, and I hope this saves you that time.

Have a question or something still unclear? Leave a comment below — I read every one. 👇

How Rust's Ownership Model Prevents Bugs — A Visual Guide

Divyesh Kakadiya — Wed, 01 Apr 2026 08:23:18 +0000

No segfaults. No data races. No garbage collector. Here's the idea behind Rust's most powerful feature — with diagrams that make it click.

You've probably heard that Rust is memory-safe — that it doesn't crash with segfaults or silently corrupt data like C can. But how does it do that without a garbage collector slowing things down?

The answer is ownership — three simple rules the compiler checks before your code even runs. Break a rule and it won't compile. The bug never runs. It never ships.

By the end of this post you'll understand all three rules with real diagrams and code. No systems programming background needed.

Three rules — that's the whole model

Step	Rule	What it prevents
1	One Owner	No duplicates
2	Borrow Rules	Read or write, never both
3	Auto Drop	No leaks

⚠ The problem every other language has

In C, C++, and even some higher-level languages, you can create as many pointers or references to the same data as you want — with no rules about who's responsible for it. That freedom causes three brutal bug families:

Three bug families — all caused by uncontrolled references to the same memory

🔥 The real cost — These bugs don't just crash. They cause silent data corruption, security vulnerabilities, and bugs that only appear once a month in production. The Microsoft Security Response Center found that ~70% of CVEs they patch every year are memory safety issues.

Rust's answer: make these bug patterns structurally impossible to write. Not just hard — impossible. The compiler rejects them.

Rule 1: Every value has exactly one owner

Imagine a physical key to a storage unit. There's only one key. If you give it to someone, you no longer have it — they have it. You can't use a key you don't hold.

Rust works the same way with data. Every value has exactly one variable that "owns" it. When you assign a value to another variable, ownership moves. The original variable becomes invalid.

Ownership moves like a physical object — only one variable holds it at a time

let s1 = String::from("hello");   // s1 owns the string
let s2 = s1;                       // ownership MOVES to s2
// s1 is now dead — try to use it and:
println!("{}", s1);  // ❌ error[E0382]: borrow of moved value: `s1`
// s2 works fine:
println!("{}", s2);  // ✅ prints "hello"

💡 What this prevents — Use-after-free bugs become literally uncompilable. You can't use a value after it's been moved — the compiler won't let you. No runtime check, no crash — it fails at build time.

What about integers? Simple types like i32, bool, and f64 implement the Copy trait — they're so small that copying them is cheaper than tracking ownership. The move rule applies to heap-allocated types like String, Vec, and Box.

Rule 2: Borrow rules — reading or writing, never both

Most of the time you don't want to transfer ownership — you just want to let a function use your data temporarily. That's called borrowing. You pass a reference (&) instead of the value itself.

There are two kinds of borrows, and the rule between them is strict:

You can have many readers OR one writer — never both at the same time

Shared borrow `&T` — read only, unlimited count

fn print_length(s: &String) {         // borrows s, doesn't own it
    println!("Length: {}", s.len());
}
let s = String::from("hello");
print_length(&s);  // pass a reference — s is lent, not moved
println!("{}", s);  // ✅ s still works — we only borrowed it

Mutable borrow `&mut T` — one writer, exclusive

fn shout(s: &mut String) {
    s.push_str("!!!");                // we can modify it
}
let mut s = String::from("hello");
shout(&mut s);
println!("{}", s);  // ✅ "hello!!!"

The rule you cannot break

let mut s = String::from("hello");
let r1 = &s;      // ✅ shared borrow #1
let r2 = &s;      // ✅ shared borrow #2 — still fine
let r3 = &mut s;  // ❌ error: cannot borrow `s` as mutable
                  //          because it is also borrowed as immutable
println!("{} {} {}", r1, r2, r3);

Borrow rules summary

What you do	Allowed?	Why
Many `&` borrows at once	✅ Valid	Readers don't interfere — safe in parallel
One `&mut` borrow alone	✅ Valid	Exclusive write with no readers — safe
`&` and `&mut` at the same time	❌ Blocked	Reader could see half-modified state
Two `&mut` at the same time	❌ Blocked	Both writers conflict — unpredictable

💡 Why this kills data races — A data race needs two concurrent accesses where at least one is a write. Rust's borrow rules make this structurally impossible — the compiler enforces it even across threads. You get concurrency safety for free, without writing a single mutex.

Rule 3: Values drop automatically at the end of scope

No free(). No delete. No garbage collector pausing your program. When the variable that owns data reaches the closing } of its block, Rust automatically calls drop() and frees the memory.

Rust inserts drop() automatically — zero runtime overhead, guaranteed cleanup

{
    let s = String::from("hello");  // heap allocated here
    println!("{}", s);               // works fine
}  // ← drop(s) is inserted here by the compiler. Memory freed.
// s doesn't exist anymore — can't use it even if you tried

💡 Two bugs killed at once — This prevents both memory leaks (forgetting to free) and double-free errors (freeing twice). Only the owner can drop, and since there's only ever one owner, it drops exactly once.

⚡ C vs Rust: the same bug, two outcomes

Here's the most common memory bug — accessing data after it's been freed. Same logic, completely different results:

C — compiles. Ships. Crashes in production.

char* s = malloc(6);
strcpy(s, "hello");
free(s);  // memory freed
printf("%s\n", s);
// 💥 undefined behaviour
// crash / garbage / silent corruption — no warning

Rust — rejected at compile time.

let s = String::from("hello");
let s2 = s;  // s moved
// s2 owns it now:
println!("{}", s);
// ❌ error[E0382]
// borrow of moved value
// → fix it NOW, before ship

⚡ The key insight — In C the bug compiles, ships, and explodes at 2am in production. In Rust the same bug is a line 5 compiler error on your laptop. You fix it before it ever runs.

Bonus: references can't outlive their data

There's one more thing the borrow checker enforces automatically. A reference can never outlive the data it points to. Try to return a reference to local data and Rust stops you:

// ❌ This function tries to return a reference to local data
fn dangle() -> &String {
    let s = String::from("hello");
    &s  // ❌ s is about to be dropped — this reference would dangle!
}   // s dropped here, reference becomes invalid

// ✅ The fix: return ownership, not a reference
fn no_dangle() -> String {
    let s = String::from("hello");
    s  // ✅ ownership moves out — data lives on
}

📋 The three rules — one final time

Rule 1: Every value has exactly one owner
Moving a value to another variable invalidates the original. Only one variable can hold a heap value at a time. This kills use-after-free and double-free bugs permanently.

Rule 2: Borrow with rules — many readers OR one writer
You can lend data via & (read-only, many allowed) or &mut (read-write, exclusive). Never both at once. This makes data races impossible — even across threads.

Rule 3: Values drop when their owner leaves scope
Rust inserts drop() automatically at the closing brace — no manual memory management, no GC. One owner means one drop — no leaks, no double-free.

That's it. Three rules, zero memory bugs, zero runtime cost. The borrow checker feels strict at first — but every error it shows you is a real bug it's preventing. Once you stop fighting it and start reading its messages, it becomes the best pair-programmer you've ever had.

🦀 What beginners should expect — The borrow checker will reject code that compiles fine in other languages. This is disorienting for the first few weeks. Push through it. The moment it "clicks" — usually around week 3 — you'll start writing better code in every language, because you'll think about ownership and aliasing everywhere.

If this helped, share it with someone learning Rust — it's the explanation I wish existed when I started. 🦀

Zero-Cost Abstractions in Rust — What It Really Means

Divyesh Kakadiya — Thu, 26 Mar 2026 04:50:08 +0000

“What you don’t use, you don’t pay for. And what you do use, you couldn’t hand-code better.” — Bjarne Stroustrup

The Philosophy at the Core

When Bjarne Stroustrup coined the term zero-cost abstractions for C++, he meant two things:

You don’t pay for what you don’t use
You can’t do better by hand

Rust takes that philosophy and turns it into a guarantee, not just an aspiration. It’s baked into the design of the language itself.

But what does that actually mean in practice?

Most explanations stop at “the compiler is smart.” That’s not enough. Let’s break it down — from source code to machine code.

What “Zero-Cost” Actually Means

Let’s clarify what zero-cost abstractions do NOT mean:

Your program runs instantly
You never need to think about performance
All Rust code is automatically fast

What it does mean:

The abstraction mechanism adds no runtime overhead
Iterators compile to the same code as manual loops
Generics compile to specialized versions (no dynamic cost)
Closures compile to inline logic

The cost exists at compile time:

Longer builds
Larger binaries (due to monomorphization)

At runtime? Zero tax.

Iterators vs Loops — The Classic Example

Manual loop

fn sum_squares_loop(data: &[i64]) -> i64 {
    let mut total = 0;
    let mut i = 0;
    while i < data.len() {
        let x = data[i];
        if x % 2 == 0 {
            total += x * x;
        }
        i += 1;
    }
    total
}

Iterator version

fn sum_squares_iter(data: &[i64]) -> i64 {
    data
        .iter()
        .filter(|&&x| x % 2 == 0)
        .map(|&x| x * x)
        .sum()
}

The iterator version reads like English:

“Filter even numbers → square them → sum the results.”

Why it's just as fast (or faster)

1. Bounds-check elimination
The compiler can prove accesses are safe and removes checks entirely.

2. Loop fusion
.filter(), .map(), .sum() → one loop, not three.

3. Auto-vectorization
The compiler may use SIMD instructions automatically.

What the Compiler Actually Does

Stage 1: Source code

data.iter().filter(...).map(...).sum()

Stage 2: MIR (Mid-level IR)

Iterators become state machines
No heap allocations
Everything gets inlined

Stage 3: LLVM optimizations

Functions + closures inlined
Operations fused into a single loop
Bounds checks removed
SIMD applied where possible

Stage 4: Assembly

What remains is highly optimized machine code — often processing multiple values at once.

Generics: Monomorphization

fn largest<T: PartialOrd>(list: &[T]) -> &T {
    let mut largest = &list[0];
    for item in list.iter() {
        if item > largest {
            largest = item;
        }
    }
    largest
}

What actually happens:

largest(&[3_i32, 1, 7, 2]);  // generates largest_i32
largest(&[3.1_f64, 1.0]);    // generates largest_f64

Each type gets its own specialized version.

Result:

No virtual dispatch
No runtime overhead
Same performance as handwritten code

Tradeoff: larger binaries, longer compile times.

Traits: Static vs Dynamic Dispatch

trait Drawable {
    fn draw(&self);
}

Static dispatch (zero-cost)

fn render_static<T: Drawable>(shape: &T) {
    shape.draw();
}

Fully known at compile time
Inlined
No vtable

Dynamic dispatch (runtime cost)

fn render_dynamic(shape: &dyn Drawable) {
    shape.draw();
}

Uses vtable lookup
~3–5ns overhead per call
Cannot be inlined

👉 In Rust, dynamic dispatch is always explicit (dyn Trait).

Real-World Example

fn process_logs(raw: &str) -> HashMap<String, usize> {
    raw
        .lines()
        .filter(|l| l.contains("ERROR"))
        .filter_map(|l| parse_service(l))
        .fold(HashMap::new(), |mut acc, service| {
            *acc.entry(service).or_insert(0) += 1;
            acc
        })
}

What this gives you:

Single pass over data
No intermediate allocations
No extra memory overhead

Readable AND fast.

Performance Summary

Task	Approach	Performance
Sum of squares	Iterators	Same as loop
Filter + map	Iterators	Same or faster
Generics	Monomorphized	Same
Dynamic dispatch	`dyn Trait`	Small overhead

Where You Can Still Go Wrong

Zero-cost abstractions don’t mean zero thinking.

Common pitfalls:

1. clone() in hot loops
→ Each call may allocate

2. .collect() mid-chain
→ Breaks fusion + allocates memory

3. Box<dyn Trait> in hot paths
→ Heap allocation + dynamic dispatch

4. Large values copied repeatedly
→ Prefer references or Arc<T>

How This Changes Your Coding Style

1. Prefer clarity first

Readable iterator chains are usually also the fastest.

2. Trust the compiler

Don’t assume loops are faster — measure first.

3. Make costs explicit

dyn Trait → runtime cost
Box, Vec → allocation

4. Embrace iterator chains

They give the compiler more optimization opportunities.

The Bigger Picture

Zero-cost abstractions are more than a performance feature.

They represent a shift in how we think about programming:

You shouldn’t have to choose between readability and performance.

Rust proves you can have both.

Key Takeaways

Prefer iterators over loops — clearer and just as fast
Use generics and impl Trait by default (static dispatch = free)
Closures are inlined — no overhead
Avoid unnecessary .collect() calls
Profile before optimizing

Final Thought

Rust’s biggest promise isn’t just memory safety.

It’s this:

High-level code that compiles down to low-level performance — without compromise.

DEV Community: Divyesh Kakadiya

Rc> vs Arc> — Why Rust Makes You Combine Smart Pointers

A Real Life Example First

What Even Is Interior Mutability Doing Here?

Rc> — The Same Room

Arc> — The Different Rooms

Why Rc> Refuses to Cross Threads

The Two Questions — This Is the Key Insight

Real Example — Putting Both Together

The Trade-Off Nobody Mentions Upfront

Quick Reference — The One Table You Need

When to Use Which — The Simple Rule

Why This Is "The Heart of Rust" (Again)

Interior Mutability — Cell, RefCell, and Mutex Finally Explained

A Real Life Example First

What "Interior Mutability" Actually Means

Cell<T> — The Sticky Note

RefCell<T> — The Sign-In Sheet

Why Doesn't RefCell Just Work Across Threads Too?

Mutex<T> — The Locked Sign-In Sheet

Rc<RefCell<T>> and Arc<Mutex<T>> — The Combo You'll Actually See

Quick Reference — The One Table You Need

When to Actually Reach for Each One

Why This Is Rust Being Rust (Again)

Rust Lifetimes Aren't Scary, They're Just Honest

A real-life example first (no code, just think about this)

Let's bring this into code — but with a simple example

Here's the plain-language reason why

So what do we actually write?

The part almost nobody explains clearly

Quick side-by-side, in plain words

The actual error, decoded

Three myths about lifetimes, cleared up

So when do lifetimes actually show up?

Why this is genuinely "the heart of Rust"

Rust Closures — Why Are There Three? Fn, FnMut, and FnOnce Finally Explained

📖 A Real Life Example First

🤔 What Even Is a Closure?

📖 Fn — The Reader (Immutable Borrow)

Where you'll see this in real code

✏️ FnMut — The Editor (Mutable Borrow)

Where you'll see this in real code

📦 FnOnce — The One-Time Guy (Takes Ownership)

Where you'll see this in real code — thread::spawn

🔑 The Hierarchy — The Key Insight Nobody Explains

🔔 Real Example — All Three Together

⚡ The move Keyword — Quick Clarification

⚖️ Quick Reference Table

🤔 When to Use Which — The Simple Rule

🦀 Why This Matters

Static Dispatch, Dynamic Dispatch & Monomorphization in Rust — Explained Like a Human

📱 A Real Life Example First (No Code, Just Think About This)

🔔 Let's Bring This Into Code — With a Simple Example

😕 Here's Where It Gets Confusing (This Was My Exact Confusion)

🔬 Monomorphization — The Compiler's Hidden Superpower

✅ So How Do I Actually Mix Email and SMS in One List?

🧠 What Is Box<dyn Notification> Really? (The Part That Finally Clicked For Me)

Why do we need Box?

⚖️ Quick Side-by-Side, In Plain Words

🤔 So When Do You Pick Which One?

🦀 Why This Is Genuinely "The Heart of Rust"

🔑 The One-Line Summary

How Rust's Ownership Model Prevents Bugs — A Visual Guide

Three rules — that's the whole model

⚠ The problem every other language has

Rule 1: Every value has exactly one owner

Rule 2: Borrow rules — reading or writing, never both

Shared borrow &T — read only, unlimited count

Mutable borrow &mut T — one writer, exclusive

The rule you cannot break

Borrow rules summary

Rule 3: Values drop automatically at the end of scope

⚡ C vs Rust: the same bug, two outcomes

Bonus: references can't outlive their data

📋 The three rules — one final time

Zero-Cost Abstractions in Rust — What It Really Means

The Philosophy at the Core

What “Zero-Cost” Actually Means

Iterators vs Loops — The Classic Example

Manual loop

`Cell<T>` — The Sticky Note

`RefCell<T>` — The Sign-In Sheet

Why Doesn't `RefCell` Just Work Across Threads Too?

`Mutex<T>` — The Locked Sign-In Sheet

`Rc<RefCell<T>>` and `Arc<Mutex<T>>` — The Combo You'll Actually See

📖 `Fn` — The Reader (Immutable Borrow)

✏️ `FnMut` — The Editor (Mutable Borrow)

📦 `FnOnce` — The One-Time Guy (Takes Ownership)

Where you'll see this in real code — `thread::spawn`

⚡ The `move` Keyword — Quick Clarification

🧠 What Is `Box<dyn Notification>` Really? (The Part That Finally Clicked For Me)

Why do we need `Box`?

Shared borrow `&T` — read only, unlimited count

Mutable borrow `&mut T` — one writer, exclusive