How Rust Manages Memory Without a Garbage Collector
You're building a text parser. You read a line from a file into a buffer. You pass that buffer to a tokenizer. The tokenizer passes a slice to a validator. The validator returns the result. In C, you'd spend ten minutes deciding who frees the buffer and write a bug where it gets freed twice. In Java, the buffer sits in a heap until the garbage collector decides to sweep it, potentially pausing your thread. Rust takes a third path. The compiler tracks exactly who owns the buffer and deletes the moment the last user is done. No runtime overhead. No manual free calls. Just rules enforced at compile time.
Ownership and Scope
Rust manages memory through a system called ownership. Every value in Rust has exactly one owner. The owner is responsible for the value's lifetime. When the owner goes out of scope, the value is dropped immediately. This is deterministic cleanup. There is no background thread scanning for dead objects. The cleanup happens the instant the variable is no longer needed.
Think of memory like a rented apartment. You sign the lease when you allocate the value. You live there while the variable is in scope. When you move out, you hand back the keys and the apartment is cleared for the next tenant. The twist is that Rust forces you to hand back the keys exactly when you walk out the door. You can't leave the keys under the mat. You can't give a copy of the keys to a friend who then tries to sell the apartment. You can lend the keys to a friend for a specific time, but you can't use them yourself while they have them.
Borrowing lets you look at or use a value without taking ownership. You can have many read-only borrows, or exactly one mutable borrow. Never both at the same time. This prevents data races and dangling pointers without a runtime check. The borrow checker verifies these rules at compile time. If your code violates the rules, the compiler rejects it. If it passes, the memory management is guaranteed safe.
The Minimal Example
Here is the simplest case. A String allocates memory on the heap. The variable s owns that allocation. When main ends, s goes out of scope and the memory is freed.
fn main() {
// Allocate a String on the heap. `s` is the owner.
// The stack holds a pointer, length, and capacity.
let s = String::from("hello");
// `s` is used here. We can read or modify it.
// End of scope. `s` is dropped. Memory is freed immediately.
// No garbage collector pause. No manual free call.
}
The String type owns its data. When s is created, Rust allocates heap memory for the characters. The variable s itself lives on the stack and holds a pointer to that heap memory. When s goes out of scope, Rust calls the drop function for String. That function frees the heap memory. The stack space for s is reclaimed automatically because the stack is just a pointer-sized slot.
What Happens at Compile and Runtime
The magic happens during compilation. The borrow checker analyzes your code and builds a map of ownership and borrowing. It tracks where values are created, where they are moved, where they are borrowed, and where they go out of scope. If the map is valid, the compiler inserts drop calls at the exact points where scopes end.
At runtime, nothing happens until the scope ends. Then the destructor runs. This is why Rust is fast. There is no hidden bookkeeping during execution. The cost is paid upfront when you write the code. If the compiler rejects you, you fix the logic. If it accepts, the runtime is lean. You get the safety of managed memory with the performance of manual management.
Custom types can implement the Drop trait to run cleanup code. This is how files are closed, locks are released, and network connections are terminated. The drop method runs automatically when the value goes out of scope. You don't need to remember to close resources. The compiler guarantees it happens.
A Realistic Scenario
In real code, you rarely keep data in a single function. You pass it around. Ownership and borrowing make this safe. Functions can take ownership or borrow data. Taking ownership moves the value. Borrowing lets the caller keep the value.
/// Processes a message without taking ownership.
/// Takes a borrowed reference so the caller keeps the data.
fn process_message(msg: &str) {
// `msg` is borrowed. We don't own it.
// We can read it, but we can't free it.
println!("Processing: {}", msg);
}
fn main() {
// `message` is owned by main.
let message = String::from("Rust is safe");
// We lend a reference to process_message.
// The borrow starts here.
process_message(&message);
// The borrow ends when process_message returns.
// `message` is still valid and owned by main.
println!("Original: {}", message);
}
The function process_message takes &str, a borrowed string slice. It doesn't own the data. It can read the string, but it can't modify it or free it. When the function returns, the borrow ends. The caller still owns the String and can use it again. This pattern avoids unnecessary allocations and keeps the data alive as long as the owner needs it.
Convention aside: functions should take &str instead of &String whenever possible. &str accepts both owned strings and string literals. This makes your API more flexible. It's the "accept the most general type" convention. Callers can pass &my_string or "literal" without extra work.
Common Pitfalls and Compiler Errors
The borrow checker catches bugs that would cause crashes in other languages. You'll see errors when you try to use a value after moving it, or when you mix mutable and immutable borrows.
Use After Move
If you assign a value to a new variable, ownership moves. The old variable is invalid.
fn main() {
let s1 = String::from("hello");
let s2 = s1; // s1 is moved to s2. s1 is no longer valid.
println!("{}", s1); // Error!
}
The compiler rejects this with E0382: use of moved value: 's1'. You tried to use s1 after giving ownership to s2. Rust doesn't copy heap data by default. Moving is cheap. It just copies the pointer and length. The old owner is invalidated to prevent double free. Fix this by cloning the value if you need two copies, or by borrowing instead of moving.
Mutable and Immutable Conflict
You can have many immutable borrows, or one mutable borrow. Never both.
fn main() {
let mut s = String::from("hello");
let r1 = &s; // Immutable borrow starts
let r2 = &mut s; // Mutable borrow starts
println!("{} {}", r1, r2); // Error!
}
The compiler rejects this with E0502: cannot borrow 's' as mutable because it is also borrowed as immutable. You have a reader and a writer active at the same time. If the writer changes the string, the reader might see garbage or crash. Rust stops this. Drop the immutable borrow before creating the mutable one, or restructure the code to avoid overlapping borrows.
Moving Out of Borrowed Content
You can't move a field out of a borrowed struct. The borrow doesn't give you ownership of the fields.
struct User {
name: String,
}
fn main() {
let user = User { name: String::from("Alice") };
let borrowed = &user;
let name = borrowed.name; // Error!
println!("{}", borrowed.name);
}
The compiler rejects this with E0507: cannot move out of 'borrowed' which is behind a shared reference. You tried to move name out of borrowed. The borrow only lets you read the struct, not steal its parts. Clone the field if you need ownership, or restructure the code to avoid the move.
Trust the borrow checker. It usually has a point. If you're fighting it, your logic likely has a flaw.
Decision Matrix
Rust gives you tools for different memory needs. Pick the right one based on your scenario.
Use stack allocation for small, fixed-size data like integers, floats, or structs with known sizes. The compiler handles the memory automatically. No heap overhead.
Use Box<T> when you need heap allocation with a single owner. The data can be large or its size is unknown at compile time. The box moves the data to the heap and gives you a pointer.
Use borrowing (&T or &mut T) when you need to access data without taking ownership. This avoids moving values and keeps the original owner alive. Borrowing is the default for function arguments.
Use Rc<T> when multiple parts of your code need to read the same data and you don't care about thread safety. The reference count tracks how many owners exist. The data is freed when the count hits zero.
Use Arc<T> when you need shared ownership across threads. The atomic counter handles concurrent increments and decrements safely. It's slightly slower than Rc<T> due to atomic operations.
Use Vec<T> when you need a growable array. The vector owns its elements and manages the heap buffer for you. It resizes automatically as you push items.
Use String when you need an owned, mutable sequence of characters. It wraps a Vec<u8> and guarantees valid UTF-8. Use &str for borrowed slices.
Memory safety isn't a feature. It's the default. If you're manually tracking memory, you're doing it wrong.