Memory & Garbage Collection, Explained

What actually happens to the objects your code creates: where they live in memory, why some of them have to be cleaned up, and how the two big approaches - freeing memory by hand versus a garbage collector that does it for you - really work.

1. Where Objects Live & How They're Allocated A quick recap of the stack (fast, automatic) versus the heap (flexible, manual), then the heart of it: the heap is where objects that outlive a function go, and the hard problem is knowing when it's safe to reclaim that memory.
2. Manual vs Automatic Memory Two ways to answer 'when is it safe to reclaim memory?': manual (C/C++ - you allocate and free, total control but footguns like use-after-free and leaks) versus automatic (Java/Go/Python/JS - a garbage collector does it for you, safe but with a cost), plus Rust's ownership as a third way.
3. How Garbage Collection Actually Works The core idea is reachability: anything you can still reach from your live variables is kept, everything else is garbage. Mark-and-sweep at a gentle level, why a garbage-collected program can hiccup (GC pauses), and the uncomfortable truth that memory leaks still happen in GC languages - with the classic cause and its cure.