The ability to respond in microseconds is a latency issue, not a raw speed issue. Erlang and Elixer can do that because of the way the core systems are architected but the underlying VM and language constructs are quite a bit slower than anything that Go has to offer.
For maximum throughput out of a given chunk of hardware you'd want Go.
Erlang / Elixer and the associated VM and eco-system have their own strength, reliability for instance, with some C code thrown in for heavy lifting if required.
If we are talking about maximum throughput, then you want C++ and in my tests Java has been better than Go, .NET probably is better than Go as well - because when speaking of maximum throughput RAM becomes the biggest bottleneck. And as soon as you're talking about platforms with a non-optional GC, then we start speaking about the performance and predictability of that GC. Go doesn't bring improvements for managing memory access patterns over other GC-enabled platforms, like Java or .NET and compared to those, its garbage collector story has been much, much worse, albeit improving.
But we're not talking about maximum throughput above all else. We're talking about the differing throughputs of high-level languages, which Golang is, but C++ is obviously not.
That's not entirely true, not everything is garbage collected. With some care, you can get a whole lots of things allocated on the stack. Tooling can also help you figure if things escape to the heap.
You can also control the size and number of objects your program creates, which impacts the performance of GC. Sure you can't pick a GC from a stack of GCs, but you do have many things in your hand to control how memory will behave.
