Rust Lifetimes explained like you are 12

Driving Innovative Success Stories

Imagine you have a library book that you borrowed.

The basic rule: You can’t keep reading that book after you’ve returned it to the library, right? That would be silly, you don’t have it anymore!

Rust lifetimes work the same way with computer memory. When your program creates some data (like borrowing a book), Rust needs to make sure you’re not trying to use that data after it’s been “returned” (i.e. deleted from memory).

Here’s a simple example:

Let’s say you write a note and give it to your friend to read. Your friend can read it while you’re holding the note. But if you throw the note in the trash, your friend can’t read it anymore, the note doesn’t exist!

Rust’s job is to check your code and say “Hey wait, you’re trying to read that note after it got thrown away!” and it won’t let you run the program until you fix it.

The confusing part with the 'a symbols:

When you see something like 'a in Rust code, that’s just Rust’s way of keeping track of “how long does this thing live?” It’s like putting a sticker on the note that says “this note exists from 2pm to 3pm” so Rust can make sure nobody tries to read it at 4pm.

The good news? Most of the time Rust figures this out automatically and you don’t have to think about it. You only need to tell Rust about lifetimes when it gets confused about which thing lives longer than another thing.

Why does Rust care so much?

Because using deleted memory causes really nasty bugs that crash programs. Rust is being a helpful (quite ofen annoying) teacher who checks your homework to make sure you won’t make those mistakes.

Annotation is for keeping track of relationships between variables

The 'a annotation is for keeping track of relationships between variables, not individual variables themselves. Think of it like this:

Without lifetimes:

  • Rust automatically tracks how long each variable lives
  • You create a variable, you use it, it gets cleaned up when you’re done
  • No annotations needed

With lifetimes ('a):

  • You’re telling Rust “these two things are connected”
  • Specifically: “this piece of data I’m returning lives at least as long as this piece of data I’m borrowing”

A real example:

fn get_first_word<'a>(sentence: &'a str) -> &'a str {
    // returns a piece of the sentence
}

That 'a is saying: “The word I’m giving back is a piece of the sentence you gave me. So the word can only exist as long as the original sentence exists.”

Lets say you are reading a page from a website via a URL, you can keep reading that page for as long as the website itself is up and available online. Once the website is removed, the page can’t be viewed anymore because it no longer exists.

The key thing: Rust already knows how long each individual variable lives. The 'a is only there when you need to tell Rust “hey, these two borrowed things are related to each other.”

Most of the time, Rust figures this out on its own and you never see 'a at all. You only need it when Rust gets confused about which borrowed thing depends on which other borrowed thing.

Lifetimes are specifically for connecting borrowed references to each other or to their source.

Here’s when you need them:

  1. When a function returns a borrowed reference – you need to tell Rust which input parameter that returned reference came from
  2. When a struct holds borrowed references – you need to tell Rust that the struct can’t live longer than the thing it’s borrowing from

When you DON’T need them:

  • Variables that own their data (no borrowing = no lifetime annotations)
  • Most function parameters; Rust figures this out
  • Local variables; Rust tracks them automatically

A simple way to think about it:

Lifetimes are like saying “this borrowed thing depends on that other thing still existing.” It’s tracking the relationship between the borrower and the thing being borrowed.

You are connecting two things, but specifically you’re connecting:

  • Something that’s borrowed (&T)
  • To the thing it was borrowed from

Without borrowing (using &), you don’t need lifetime annotations at all.

It is so Rust can throw a compile error if the source is being deleted too early.

This is the whole point. Rust uses those lifetime annotations to check at compile time: “Is this code trying to use borrowed data after the original owner is gone?”

If it finds a problem, it refuses to compile and tells you to fix it.

Why this is awesome:

In languages like C or C++, if you accidentally use data after it’s been deleted, your program might:

  • Crash randomly
  • Show garbage data
  • Work fine, until it suddenly doesn’t…
  • Have security vulnerabilities

These bugs are called “use-after-free” bugs and they’re really hard to find because they don’t always happen right away.

Rust’s approach:

Instead of letting you run the program and hoping nothing breaks, Rust says “Nope, I can see this WILL break, fix it now before I let you run it.”.

As annoying as this can it saves you time in the long run. You get annoying compile errors, but you NEVER get those nasty memory bugs at runtime.

In short: The lifetime annotations give Rust enough information to prove that you’re not doing anything dangerous with borrowed data. If it can’t prove your code is safe, it won’t compile.

John Ward