> #1 If your goal is to make the most efficient and fast code (garbage collected or not), it is not clear gc-less languages are always better. Sometimes, not fr

> #1 If your goal is to make the most efficient and fast code (garbage collected or not), it is not clear gc-less languages are always better. Sometimes, not free-ing the memory at the first possible time will actually be good for you overall. Which is why languages like C++ let you write and use your own allocators. There are lots of reasons to do this (eg word alignment). And while I agree that it's certainly possible that delayed freeing may be beneficial I'm not convinced it's a problem in practice, at least when you compare it to how often common GC problems are (eg memory leaking (admittedly also a problem with manual allocation), out-of-control process memory growth and STW pauses). #2 If you are writing anything with serious mem usage in Go, you will optimize for allocations using sync.Pool or some other form of reuse. True, and I mentioned this in another comment: the idea that you can get around many GC issues by using object and memory pools. > Heck, some of my Java code works faster than even my Go code. Why should that be surprising? The JVM at this point has >25 years of engineering effort into it and (IMHO) it doesn't get half the credit it deserves from the devotees of the latest flavour of the month.