The article references a blog post that I wrote a long while ago about how we do memory management for some Go programs at CloudFlare: https://blog.cloudflare.com/recycling-memory-buffers-in-go/ We've switched most of that stuff to use sync.Pool now. And we've done a lot of pprof work to simply reduce garbage in the first place.
Regardless of my opinion about some Go issues, I really look forward to see the language becoming widespread.
My experience with Oberon back in the mid-90's, made me aware that it is possible to have systems languages with GC.
The main problem is that many developers don't experience the variety from GC implementations that exist out there, and equate all implementations alike.
In Oberon's case it wasn't the best GC in the world, specially in mid-90's PC hardware, but coupled together with value types it was good enough to fully implement an OS in Oberon (and its derivatives).
Regardless of my opinion about some Go issues, I really look forward to see the language becoming widespread.
My experience with Oberon back in the mid-90's, made me aware that it is possible to have systems languages with GC.
The main problem is that many developers don't experience the variety from GC implementations that exist out there, and equate all implementations alike.
In Oberon's case it wasn't the best GC in the world, specially in mid-90's PC hardware, but coupled together with value types it was good enough to fully implement an OS in Oberon (and its derivatives).