In Go garbage collection is global mark and sweep. This pauses all goroutines during the sweep and this is terrible for latency. Again, low latency is hard, the more the runtime can do for you the better.
Garbage collection is one thing Erlang’s model got really really right. The actual implementation of Erlang’s GC is incredibly dumb because it can be. No references across the entire VMs heap means you never have to stop the world, just parts of it. This is great for low latency systems. You can allocate and destroy tons of junk with your system chugging along pretty happily. At scale you’ll run into some issues, of course, but you always do that at scale.
I’ve added an update to the top of the post because I didn’t make the point clear enough:
I’m seeing that I did not make the point of this post clear. I am not saying Go is wrong or should change because it isn’t like Erlang. What I am attempting to show is the choices Go made that make it not an alternative to Erlang for backends where availability and low latency for high numbers of concurrent requests is a requirement. And notice I’m not writing this about a language like Julia. I have heard Go pitched as an alternative to Erlang for not only new projects but replacing old. No one would say the same for Julia, but Go and Node.js are seen by some as friendlier alternatives. And no, Erlang isn’t the solution for everything! But this is specifically about where Erlang is appropriate and Go is lacking.