Why Discord left Go for Rust, and why that is not an argument against Go
Discord's post about rewriting a service from Go to Rust is one of the most cited engineering blog posts of the last decade, and one of the most misread. It gets linked in arguments as though it settles something about Go in general. It does not. It is a very specific story about one service with one unusual property.
What actually went wrong
The service in question kept a large amount of state in memory and read from it constantly. Go's garbage collector has to periodically walk that memory to work out what can be freed. The more live state you hold, the longer that walk takes. Discord saw latency spikes on a regular cadence that lined up exactly with garbage collection cycles.
They tuned it. They adjusted how often collection ran. The spikes moved around but did not go away, because the underlying work was not optional: something had to scan that memory eventually.
Why Rust fixed it
Rust has no garbage collector. Memory is freed at deterministic points the compiler works out at build time. There is no background process that periodically stops to survey the heap, so there is no periodic pause to tune away. The spikes did not get smaller. The mechanism that caused them stopped existing.
The part people skip
This is a story about a service holding a big in-memory cache in a latency-sensitive path. That is a narrow profile. The overwhelming majority of backend services do not hold enough live state for GC pauses to register, and for those, Go's collector is not a problem worth solving.
Discord itself did not abandon Go. They replaced one service where the tradeoff had flipped. That is a much less exciting headline, which is presumably why it is not the one that circulates.
How to use this when choosing
The transferable lesson is not "Rust beats Go." It is: know which resource your service is actually constrained by. If you are holding gigabytes of live objects and your p99 latency matters more than your p50, garbage collection is a real design input. If you are writing a service that handles a request, touches a database and returns, it is noise.
Most teams reaching for this post as justification are in the second category and quoting evidence from the first.