Part 2 of 3: Is It Memory Safe? | Languages Evolve | When Does It Make Sense?
Part 1 described a pattern. This part asks a different question: what if the languages being rewritten away from solve the problems that motivated the rewrite?
Rust had a garbage collector#
Before Rust 1.0 shipped in 2015, the language had garbage-collected pointer types (@T and Gc<T>). The language designers experimented with GC, decided it was the wrong tradeoff for their goals, and removed it. The ownership and borrowing model that defines Rust today was not the original design. It was the result of iteration.
That history is worth sitting with. Rust’s most celebrated feature, the thing that motivates most rewrites, emerged because the language was willing to rethink its core assumptions. The Rust community did not accept the first design as permanent. They improved it.
If Rust earned the right to evolve past its early decisions, why would we assume other languages cannot do the same?
Go is not standing still#
A common justification for rewriting Go tools in Rust is Go’s garbage collector. The GC introduces latency. It uses more memory. For certain workloads, that matters.
But Go is on version 1.26 now. The Green Tea garbage collector, enabled by default as of February 2026, reduces GC overhead by 10 to 40 percent by processing small objects at the memory page level instead of chasing individual pointers. The runtime has arena allocation and better memory layout control. The language is not ignoring its limitations; it is actively fixing them.
The argument “Go will never match Rust’s compile-time safety guarantees” assumes Go stops evolving. That assumption has not held for any widely adopted language in the history of software. C added _Static_assert and bounds-checking annotations. Java rewrote its garbage collector multiple times. Python added type hints. Languages that survive do so because they adapt.
What happens to the case for a rewrite if the source language fixes the problem the rewrite was meant to solve?
What if the energy went somewhere else?#
The talent in the Rust ecosystem is remarkable. The people building these rewrites are skilled engineers doing serious work. That is not in question.
But there is an opportunity cost worth considering. Every engineer spending months rewriting coreutils or sudo in Rust is an engineer not working on something that does not exist yet. The rewrite inherits a solved problem and re-solves it. The unsolved problems stay unsolved.
What if that concentrated effort went into improving the original tools instead? A Rust developer contributing memory-safety improvements to an existing C project through safer interfaces, better fuzzing, or incremental rewrites of the most dangerous components would preserve the community, preserve the edge-case knowledge, and still improve safety. It is less dramatic than a full rewrite. It might also be more useful.
Or what if that energy went toward genuinely new problems? Rust is well-suited for areas that are underserved: safe concurrent network services, secure-by-default parsers for complex formats, tooling for domains where memory safety is a hard requirement and nothing adequate exists yet. The language has the potential to create things that have never existed, not just recreate things that already work.
The rewrite pattern channels enormous talent into rediscovering what was already known. That feels like a missed opportunity.
Iteration is how everything gets better#
The throughline here is that improvement comes from iteration, not replacement. Rust itself improved by iterating. Go is improving by iterating. The original tools being rewritten improved over decades of iteration, which is exactly why they are hard to replace.
A rewrite discards that iteration history and starts the clock over. Sometimes that is the right call. But it is a much larger cost than the rewrite narrative typically acknowledges.
The interesting question is not “should we rewrite this in Rust?” It is “what is the best use of this energy?” Sometimes the answer is a rewrite. Sometimes it is a contribution. Sometimes it is something entirely new.
Part 2 of 3: Is It Memory Safe? | Languages Evolve | When Does It Make Sense?