Borrow F*cking Checker

Rust is known for its safety, everyone raves about its type safety and gets an orgasm. But everything comes at a cost, and that cost is called the Borrow Checker.

It sounds like something bad, but of course, it isn't. It's a different approach, a very different one.

If you're switching to Rust from another language, such as c++, python, java (ugh), js or sexy php, you'll definitely be surprised and for some, the concept of the Borrow Checker might be irritating. Let's start with some prerequisites -->

What is it?

The Borrow Checker is a part of the Rust compiler that monitors how your code uses references (borrows) to data. It ensures that all operations on data in your code adhere to the rules of ownership (more on that in a moment).

Why? To guarantee that your code won't encounter memory issues such as dangling pointers, data races, or undefined behavior. If you're used to c/c++, where you have to catch such problems manually, the borrow checker will certainly surprise you.

This is important because in c/c++ you manage memory manually. That's cool, but it's easy to shoot yourself in the foot, especially in large software projects. In more 'zoomer' languages like python, java (ugh), js or sexy php, memory is managed by a garbage collector (GC), which is convenient and worry free but comes with its own overhead.

Rust offers something else: memory control without a GC and without manual management, but through strict rules enforced at compile time.

Before diving into how the borrow checker works, let's break down three concepts:

• Ownership
• Borrowing (references)
• Lifetimes

Let's go! -->

Ownership

Every value in Rust has an owner (a variable) that is responsible for its deletion. When the owner goes out of scope, the value is deleted (i.e. drop is called).

Here's an example:

fn main() {
    let a = String::from("JVM SUCKS"); // 'a' is the owner of the string
    take_ownership(a); // 'a' is passed to the function, transferring ownership

    // error here: 'a' no longer owns the data
    // println!("{}", a); 
}

fn take_ownership(a: String) {
    println!("{}", a);
} // here 'a' goes out of scope, and the memory is freed

c++ analogy: It's like std::unique_ptr you can’t copy it, but you can move it.

Borrowing

To avoid constantly transferring ownership, Rust allows you to take references to data (in other words, to "lend" it).

Immutable reference &T (you can read the data, but you can't modify it. you can have as many immutable references as you want.)

Mutable reference &mut T (you can modify the data. only one mutable reference can be active in a scope.)

fn main() {
    let mut s = String::from("php sexy");
    let r1 = &s; // immutable reference
    let r2 = &s; // another immutable reference
    println!("{} and {}", r1, r2); // all good here

    let r3 = &mut s; // mutable reference
    r3.push_str(" world!");

    // error: cannot use r1 while r3 is active
    // println!("{}", r1); 
}

Borrowing rules:

• Either one mutable reference or any number of immutable references
• References must not outlive their owner

Lifetimes

The Borrow Checker ensures that all references are valid for the duration of their lifetimes. Usually, the compiler infers lifetimes automatically, but sometimes you need to specify them explicitly:

// Example of explicitly specifying lifetimes
fn longest<'a>(s1: &'a str, s2: &'a str) -> &'a str {
    if s1.len() > s2.len() { s1 } else { s2 }
}

Here, 'a indicates that the returned reference lives at least as long as the shorter of s1 or s2.

You'll get used to it

I get it, it's unfamiliar, but it's not hard to adapt (even if it feels impossible). Practice, practice and practice. After a couple weeks of coding, it'll start to feel intuitive.

p.s if you stuck, look up patterns like "transferring ownership via structs" or using smart pointers (Rc, Arc, RefCell). Sometimes arguing with the Rust compiler is the default, xd

Bonus tips

Modify data only after its references have gone out of scope.

let mut x = 5;
let y = &x;
x = 10; // error: cannot modify 'x' while there is an active reference 'y'

println!("{}", y);

Let’s keep going -->

Dangling Reference

fn dangle() -> &String {
    let s = String::from("Hello");
    &s // error!
// 's' is dropped when the function ends, so the reference is invalid
}

Return ownership instead of a reference:

fn no_dangle() -> String {
    let s = String::from("Hello");
    s // ownership is transferred out
}

Let’s go further -->

let mut s = String::new();
let r1 = &mut s;
let r2 = &mut s; // error: two mutable references to 's'

r1.push_str("test");

Use references in different scopes →

let mut s = String::new();
{
    let r1 = &mut s;
    r1.push_str("test");
} // r1 goes out of scope

let r2 = &mut s; // now it's allowed

These pseudocode examples could go on forever:

• Start with immutable references. Use & wherever possible
• Localize mutability. The less code that has access to mutable data, the simpler it is
• Trust the compiler. Its error messages are the best textbook, read them like scripture
• Use clone() as a temporary solution if you're stuck (but don't abuse it)

And again, practice, practice and practice. Luckily, Rust has an active, growing community. Check the docs, Google stuff, read books.