Memory Safety Isn’t Just Rust: A Serious Look at GC

Posted by Looper 15 June 2025 0:59 AM

In the age of Rust hype and memory-safe programming, it's easy to forget that there’s an older, more battle-hardened warrior in the same arena: the Garbage Collector. While Rust earns headlines with its “fearless concurrency” and “zero-cost abstraction,” the truth is, memory safety has long been solved in other ways—just not always with the same buzzwords.

Garbage Collection (GC) has powered generations of stable systems—from Erlang’s telecom backbones to high-frequency trading systems written in Java. Yet GC is often painted with a simplistic brush: “GC is slow.” But the reality is nuanced. GC is a powerful tool that’s evolving fast, and in many cases, it’s more than fast enough.

Let’s take a deeper look.

What is Garbage Collection?

In a manually managed memory system (like C), developers must explicitly allocate and free memory. Forget to free memory? You get a leak. Free it too early? You get a segmentation fault.

Garbage Collection automates this. GC systems track references to memory and automatically free objects that are no longer in use. This removes whole classes of bugs—and removes a huge mental load from the developer.

There are several types of GC algorithms. Let’s cover the most prominent ones:

1. Reference Counting

Every object keeps track of how many references point to it. When the count drops to zero, the memory is freed. Simple, deterministic, but struggles with cycles.

2. Tracing Garbage Collection

Popular in languages like Java and JavaScript. The GC “pauses the world,” walks the object graph from roots (like global variables or the stack), and frees everything not reachable. Examples: mark-and-sweep, generational GC.

3. Generational GC

Based on the observation that most objects die young. Memory is divided into generations (young, old). Young objects are collected frequently; older ones less often. Improves performance by reducing the scanning scope.

4. Real-Time or Incremental GC

Used in hard real-time or interactive systems. These systems split GC work into tiny increments to prevent long pauses. Think: concurrent mark-sweep, or pause-less collectors like ZGC and Shenandoah in JVM.

GC Isn’t “Slow” Anymore

The claim that GC is slow is stuck in the 1990s. Yes, early GCs had brutal pause times. But today’s GCs are engineered for low latency and predictable performance.

JVM's ZGC and Shenandoah now offer pause times under 10ms, even with gigabytes of heap.
Go's GC evolved from high-latency to being real-time capable under most workloads.
Erlang's per-process GC enables soft real-time by isolating GC to individual lightweight processes.
WebAssembly GC proposals aim to bring fast, language-neutral GC to the modern web and embedded systems.

GC vs. Compile-Time Checking (Rust)

Rust enforces memory safety via lifetimes and ownership—at compile time. No runtime overhead, but also, steep learning curve and sometimes productivity drag.

So what are the trade-offs?

Rust is like flying a plane with no autopilot: you're in total control. GC is like having a smart co-pilot who cleans up after you so you can focus on flying.

GC Loves Functional Programming

There’s another secret advantage to GC: it works beautifully with functional programming (FP).

Why?

Immutable data: FP languages like Clojure or Haskell emphasize immutable values. This removes aliasing problems and makes GC easier and faster.
Short-lived objects: Functional code often chains operations, producing transient data structures. This works perfectly with generational GC.
No manual lifecycle: Functional code often discourages manual resource management, making GC the natural choice.

Languages like Lisp/Scheme, Haskell, OCaml, and Erlang rely on GC—and they can hit performance sweet spots when paired with intelligent memory management.

Realtime GC Exists

Realtime GC isn’t a fantasy—it’s shipping today. Realtime GCs like Metronome (used in IBM WebSphere) or Azul’s C4 have been used in production environments where latency spikes are unacceptable.

In short: if your argument is that GC can’t be used for games, embedded systems, or finance, it’s outdated.

C is coming back

Filip Pizlo, senior director of language engineering at Epic Games and one of the original developers of JavaScriptCore’s concurrent garbage collector, has taken a different path. His new language, fil-c (short for Filip’s C), offers memory safety without a borrow checker, with garbage collection, and without the Rust-shaped cognitive overhead.

Memory Safety: Not a Monoculture

Rust is not the messiah. It’s a good tool—but so is garbage collection, so is region-based analysis, so are typed arenas, so is filc. The deeper truth is this:

Memory safety is a spectrum of techniques, not a single ideology.

When language engineering is treated like a fashion show, entire ecosystems suffer. Innovation happens when experienced engineers (like Pizlo) quietly build the tools they actually need, without submitting to community peer pressure.

If you're building a system that needs to be fast, safe, and not boxed in by dogma—pay attention. GC is evolving. Static analysis is evolving. And now, thanks to projects like filc, C is evolving too.

The future isn't just Rust. It’s plural.

Final Thoughts: Choose the Tool, Not the Hype

Rust is great. It offers deterministic performance, zero-cost abstraction, and an uncompromising safety model. But it’s not the only answer to memory safety.

Garbage Collection is not just “okay”—it’s powerful, fast, and proven. The reality is that most modern apps—from JVM backends to Go microservices to the Emacs editor you love—are alive today because GC quietly does its job.

Don’t worship the compiler. Know your tools. GC is not your enemy—it’s your invisible ally.