I'm not sure that your premise is solid. Your citations point to a single program that was somewhat naively written, not well optimized, and designed as a compu

I'm not sure that your premise is solid. Your citations point to a single program that was somewhat naively written, not well optimized, and designed as a computational benchmark spending much of it's time in GC. That's doesn't necessarily imply that "GC takes more CPU time than actual computations in normal Go programs". That's not to say that Go's GC isn't slow, but as citation #2 shows, one can limit heap allocation if performance requires it. So, the fact that you're saying "Don't do what Go does, it makes Go almost useless for real world applications" seems odd to be because: 1. Not all applications care deeply about stop-the-world gc pauses. 2. Not all of those that do will have a problem with them, as GC can be avoided by value semantics and escape analysis. 3. Go will not necessarily always have a Stop-The-World GC, though it does now. I don't think it's required by the spec. 4. People are using Go in real world applications, implying that it isn't almost useless. Even servers. 5. The Rust folks clearly have thought hard about efficient and scalable memory management, and the slideshow indicates that, so I'm not sure why you're worried for them.