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.
You're aware that the Go allocator is written in Go, right?
Unless you want to bucket all systsme programming in to one bucket, I will say this
#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.
#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. I am sure well written C++ code would have to do the same tricks. reduce >> reuse >> recycle. Both GC and free() are recyclers. Sure, one could argue GC could provide more control.
I 100% agree there are cases C/C++ or Rust would be better for 20% of the trickier situation, but let us not base it all on the presence of garbage collector.
Heck, some of my Java code works faster than even my Go code. I don't blame Java for having a garbage collector.