Go is a fine language, but I do have a nitpick here: you do not "avoid the GC" by using memory pools. The GC must still trace through the pool when it does run. The more correct thing to say is that you can reduce allocations with memory pools, which make the GC run less often and make it do less work.
Furthermore, memory pools compromise safety: if you free a pointer to an object in your memory pool and you accidentally had aliases to that pointer, then you'll get subtle bugs when one of those objects gets reused.
Yes, but that's only true if you get down to zero allocations. Memory pools reduce allocations, but you cannot get down to zero allocations--even if you somehow managed to convert every allocation site into a memory pool (which basically means not using the standard library), you'd still have to allocate the pool (unless it's stored in static memory, but then your maximum number of allocations is fixed).
The only code I've seen that actually had zero allocations in a GC'd language is actually Emscripten-generated code in JS, which is of course not actually JS but C.
Furthermore, memory pools compromise safety: if you free a pointer to an object in your memory pool and you accidentally had aliases to that pointer, then you'll get subtle bugs when one of those objects gets reused.