Performance is a spectrum and Go hits a sweet spot between ease of development and "good enough" performance by default with enough escape hatches to get "competitive with C/C++" performance in critical paths when needed.

Just because you're using a GC'd language doesn't mean that you should give no thought whatsoever to the garbage your program is generating.

It's a common optimization in Go. The benchmark tool that ships with go allows reporting of bytes allocated per call. Many webserver frameworks in Go strive for 0 allocs so as a user of the library, you know it won't cause extra garbage.

https://scene-si.org/2017/06/06/benchmarking-go-programs/

Even in C and C++ you still need to optimize to get rid of allocations.

Maybe the allocations are more obvious, because you usually have to write them out yourself (heap-allocating RAII containers excepted), but the problem is the same.

Realistically if you're able to serve 10k requests/s and you want to get to 20k and you have the option of:

a) rewriting in C++

b) pooling some objects

Which one is the right call?

Both

Not all Go programs need garbage collection to run.

Garbage collected memory allocations would be the subset of allocations for which the compiler was unable, through escape analysis or otherwise, prove that an allocation's lifetime extends past (for example) its lexical scope, in which case the analog of C auto allocation would suffice.

Thing I'd like is the ability to annotate objects and have the compiler generate a warning if the annotation is violated. As tell the compiler you expect the object to pass escape analysis. And it if doesn't the compiler will give you a bitchy warning.