Go to Rust Series: ← No Garbage Collector | Series Overview | Mut vs Immutable →

The Concept Go Doesn’t Need

Lifetimes are Rust’s way of tracking how long references are valid—all at compile time.

Go doesn’t need lifetimes because the garbage collector tracks reference validity at runtime. Rust needs them because there’s no GC.

Go: References Just Work

Go:

func getFirst(a, b string) string {
    if len(a) > len(b) {
        return a
    }
    return b
}

func main() {
    x := "short"
    y := "longer"
    result := getFirst(x, y)
    fmt.Println(result)
}

No annotations needed. GC ensures result stays valid.

Rust: Compiler Needs Proof

Rust (won’t compile without lifetimes):

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

Error:

error[E0106]: missing lifetime specifier
 --> src/main.rs:1:37
  |
1 | fn get_first(a: &str, b: &str) -> &str {
  |                 ----     ----     ^ expected named lifetime parameter

Rust needs to know: does the returned reference come from a or b? How long is it valid?

Fixed with lifetime annotation:

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

fn main() {
    let x = "short";
    let y = "longer";
    let result = get_first(x, y);
    println!("{}", result);
}

The 'a annotation says: “The returned reference lives as long as the shorter of a or b.”

What Are Lifetimes?

Lifetimes are compile-time annotations that tell the compiler how long references are valid.

Syntax:

  • 'a - A lifetime parameter (pronounced “tick a”)
  • &'a str - A reference with lifetime 'a

Example:

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() { x } else { y }
}

This says:

  • x and y both have lifetime 'a
  • The return value has lifetime 'a
  • Therefore: return value lives as long as both inputs

Lifetime Elision: When You Don’t Need Annotations

Rust has rules to infer lifetimes in simple cases:

Rule 1: Each parameter gets its own lifetime

Explicit:

fn print_str<'a>(s: &'a str) {
    println!("{}", s);
}

Elided (compiler infers):

fn print_str(s: &str) {
    println!("{}", s);
}

Rule 2: If one input lifetime, output gets same lifetime

Explicit:

fn first_word<'a>(s: &'a str) -> &'a str {
    s.split_whitespace().next().unwrap_or("")
}

Elided:

fn first_word(s: &str) -> &str {
    s.split_whitespace().next().unwrap_or("")
}

Rule 3: Multiple inputs, but one is &self, output gets &self lifetime

Explicit:

impl MyStruct {
    fn get_data<'a>(&'a self) -> &'a str {
        &self.data
    }
}

Elided:

impl MyStruct {
    fn get_data(&self) -> &str {
        &self.data
    }
}

When elision doesn’t work, you need explicit annotations.

Dangling References: Go vs Rust

Go: GC Saves You

Go:

func dangling() *int {
    x := 42
    return &x  // OK! GC extends x's lifetime
}

func main() {
    ptr := dangling()
    fmt.Println(*ptr)  // 42
}

GC realizes x is referenced and keeps it alive.

Rust: Compiler Rejects

Rust:

fn dangling() -> &i32 {
    let x = 42;
    &x  // ERROR! x doesn't live long enough
}

Error:

error[E0106]: missing lifetime specifier
error[E0515]: cannot return reference to local variable `x`

Rust prevents the bug at compile time.

Fix: Return owned value

fn not_dangling() -> i32 {
    42  // Return value, not reference
}

Structs with References

Go: No Annotations

Go:

type Excerpt struct {
    text *string
}

func main() {
    s := "Hello, world!"
    e := Excerpt{text: &s}
    fmt.Println(*e.text)
}

Works. GC tracks the reference.

Rust: Lifetime Annotations Required

Rust:

struct Excerpt<'a> {
    text: &'a str,
}

fn main() {
    let s = String::from("Hello, world!");
    let e = Excerpt { text: &s };
    println!("{}", e.text);
}

The 'a in Excerpt<'a> says: “This struct holds a reference that lives for 'a.”

What happens if the reference outlives the data?

fn main() {
    let e;
    {
        let s = String::from("Hello");
        e = Excerpt { text: &s };
    }  // s is dropped here

    println!("{}", e.text);  // ERROR!
}

Error:

error[E0597]: `s` does not live long enough

Rust prevents use-after-free at compile time.

Multiple Lifetimes

Sometimes you need different lifetimes for different parameters:

Rust:

fn announce<'a, 'b>(
    announcement: &'a str,
    context: &'b str
) -> &'a str {
    println!("Context: {}", context);
    announcement  // Return announcement (lifetime 'a)
}

fn main() {
    let ann = String::from("Important!");
    {
        let ctx = String::from("Some context");
        let result = announce(&ann, &ctx);
        println!("{}", result);
    }
    // ctx is dropped, but result (from ann) is still valid
}

This says:

  • announcement has lifetime 'a
  • context has lifetime 'b
  • Return value has lifetime 'a (tied to announcement, not context)

Static Lifetime: Lives Forever

Rust:

fn get_message() -> &'static str {
    "This string literal lives for the entire program"
}

fn main() {
    let msg = get_message();
    println!("{}", msg);
}

'static means the reference is valid for the entire program duration (e.g., string literals, static variables).

Example with static variable:

static GLOBAL_MESSAGE: &str = "Global";

fn get_global() -> &'static str {
    GLOBAL_MESSAGE
}

Real-World Example: Iterator

Go: No Lifetime Annotations

Go:

type Words struct {
    text string
    pos  int
}

func (w *Words) Next() *string {
    // Find next word and return reference
    // GC handles lifetime
}

Rust: Lifetime Tied to Struct

Rust:

struct Words<'a> {
    text: &'a str,
    pos: usize,
}

impl<'a> Words<'a> {
    fn new(text: &'a str) -> Self {
        Words { text, pos: 0 }
    }

    fn next(&mut self) -> Option<&'a str> {
        // Find next word
        // Returned reference has same lifetime as original text
        if self.pos >= self.text.len() {
            return None;
        }

        let start = self.pos;
        while self.pos < self.text.len() && !self.text.as_bytes()[self.pos].is_ascii_whitespace() {
            self.pos += 1;
        }

        let word = &self.text[start..self.pos];
        self.pos += 1;  // Skip whitespace

        Some(word)
    }
}

fn main() {
    let text = String::from("Hello Rust world");
    let mut words = Words::new(&text);

    while let Some(word) = words.next() {
        println!("{}", word);
    }
}

The 'a ensures returned words live as long as the original text.

Common Lifetime Patterns

Pattern 1: Returning One of Many References

Rust:

fn choose<'a>(first: &'a str, second: &'a str, condition: bool) -> &'a str {
    if condition { first } else { second }
}

Return value tied to shortest lifetime of inputs.

Pattern 2: Struct Holding Multiple References

Rust:

struct Context<'a, 'b> {
    name: &'a str,
    description: &'b str,
}

impl<'a, 'b> Context<'a, 'b> {
    fn print(&self) {
        println!("{}: {}", self.name, self.description);
    }
}

Different fields can have different lifetimes.

Pattern 3: Lifetime Bounds

Rust:

fn longest_with_announcement<'a, T>(
    x: &'a str,
    y: &'a str,
    ann: T,
) -> &'a str
where
    T: std::fmt::Display,
{
    println!("Announcement: {}", ann);
    if x.len() > y.len() { x } else { y }
}

Combining lifetimes with generics.

When Lifetimes Get Complex

Rust:

struct Parser<'a> {
    input: &'a str,
}

impl<'a> Parser<'a> {
    fn parse(&self) -> Result<Token<'a>, Error> {
        // Token references data from input
        // Token's lifetime tied to Parser's lifetime
        unimplemented!()
    }
}

struct Token<'a> {
    value: &'a str,
}

This gets complex fast! But it ensures memory safety without GC.

The Mental Model

Go:

  • “Pass references around”
  • “GC will handle it”

Rust:

  • “How long does this reference live?”
  • “Does it outlive what it points to?”
  • “Can the compiler prove safety?”

Why Go Developers Struggle

Coming from Go, lifetimes feel like unnecessary ceremony:

Go version (simple):

func process(data string) string {
    return data
}

Rust version (explicit):

fn process<'a>(data: &'a str) -> &'a str {
    data
}

But Rust’s explicitness prevents bugs:

Go (compiles, crashes at runtime):

func getRef() *string {
    s := "temporary"
    return &s  // Looks safe, GC saves it
}

Rust (won’t compile):

fn get_ref() -> &str {
    let s = "temporary".to_string();
    &s  // ERROR! s doesn't live long enough
}

Conclusion

Lifetimes in Rust:

  • Ensure references never outlive their data
  • Prevent dangling pointers at compile time
  • Add complexity but eliminate runtime bugs

Go’s approach:

  • No lifetime annotations needed
  • GC handles everything at runtime
  • Simpler to write, potential runtime issues

Trade-off:

  • Go: Faster to write, runtime safety net
  • Rust: More upfront work, compile-time guarantees

Next: Understanding mut vs immutable—why Rust makes you choose explicitly.

Go to Rust Series: ← No Garbage Collector | Series Overview | Mut vs Immutable →

Lifetimes verdict: Hardest concept for Go developers. But they prevent entire classes of bugs that GC can’t catch.