Why can't GC coexist with memory pools? They both have good uses. It's pretty clear that Go designers wanted a GC, but also wanted control over memory. In go,

Why can't GC coexist with memory pools? They both have good uses. It's pretty clear that Go designers wanted a GC, but also wanted control over memory. In go, it is trivial to create a slice of structs that's contiguous in memory, and built-ins like 'copy' means the language designers wanted users to use this feature. When I write go, GC is used almost always. Except when it becomes a bottleneck, at which point I trivially switch to memory pools. I just add a comment like "preallocate to avoid allocating in a loop", and move on. The next person that comes by my code would have no trouble understanding what happened there--unlike Java where using memory pools stops looking like Java. I think when the Go FAQ mentions existing pain points, it means both GC'ed and Non-GC'ed languages. Zig is cool because it went the manual layout route, but with a pluggable allocator. I think it's a brilliant choice, especially for embedded.