Stack vs Heap in Rust: Essential Memory Management

The Stack and the Heap are two memory zones with different rules for storing data.

If you come from languages like JavaScript, Python, or C#, you probably haven’t had to free memory explicitly. A garbage collector detects objects that are no longer used, at the cost of some additional consumption and pauses that depend on each runtime.

In C, we can request memory manually with malloc and free it with free. C++ also allows this, although modern code usually relies on RAII and smart pointers to automate deallocation.

Rust takes a third path. To understand how it achieves safety without a garbage collector, we must first understand where our data lives. In your computer’s RAM, your program primarily uses two areas: the Stack and the Heap.

The stack

The Stack is a LIFO data structure (Last In, First Out).

Imagine a stack of plates in a restaurant.

1. When you wash a plate, you put it on top of the stack (Push).
2. When you need a plate, you take the one from the top (Pop).
3. You cannot take a plate from the middle without causing a mess.

The heap

What if we want to store a list that grows dynamically (like a Vector) or user-entered text (String)? We don’t know how much space it will take at compile time. We can’t put it on the Stack.

For these cases, we use the Heap. The Heap is less organized; it’s like a huge restaurant with many tables.

When you want to put something on the Heap:

1. You request a certain amount of memory.
2. The memory allocator looks for a free slot large enough and, when necessary, requests more memory from the operating system.
3. It marks that slot as “occupied”.
4. It returns a pointer (the memory address of that table).

The connection between stack and heap

In types like String or Vec<T>, the dynamically allocated elements live on the heap, while the structure holding the pointer, length, and capacity is usually part of the local variable.

Imagine the Heap is the restaurant’s dining room and the Stack is the reservation list at the entrance. You (the processor) look at the list (Stack) to know which table (Heap) your diners are at.

Quick comparison

The cleanup problem

Languages differ significantly in how they handle this. Recovering a stack frame is simple; the interesting problem is knowing when to free each heap allocation.

1. In C: The programmer must coordinate calls like malloc and free. Forgetting to free an allocation creates a leak; freeing it too early can leave a dangling pointer.
2. In C++: RAII allows binding resources to the lifetime of objects, although the language still supports manual management and unsafe accesses.
3. In Java, Go, or Python: A collector detects unreachable objects and reclaims their memory. It consumes resources and can introduce pauses, though its behavior depends heavily on the implementation.

Rust’s solution: ownership

Rust binds each resource to an owner. When the owner goes out of scope, Rust executes the corresponding drop logic, which for types like String or Vec<T> frees their heap allocation.

No Garbage Collector. No manual free.

fn main() {
    {
        // 's' is a String.
        // The text "hola" is stored on the HEAP.
        // The variable 's' (which contains the pointer, length, and capacity) lives on the STACK.
        let s = String::from("hola");

        // Do things with s...
    }
    // <--- The scope ends here.
    // Rust sees that 's' disappears from the Stack.
    // Automatically, Rust calls a special function (drop) that frees the Heap memory.
}

This idea, seemingly simple, has profound implications. What happens if we copy s? Can we have two pointers on the Stack pointing to the same place on the Heap?

If we did that and both tried to free the memory at the end… we’d have a Double Free error. Rust prevents this through the Ownership system.