Sure. That encompasses a very small set of code. Indeed, it's interesting that you mentioned games given that most game engines now are a relatively small non-GC engine, layered atop with GC technologies.

You are a rather heavy advocate of Rust, and for whatever bizarre reason the Rust crew has decided that they need to aggressively attack Go (I'd recommend you maybe focus on delivering a production product first?), but it's interesting that you did exactly what I said -- it's just a checkmark.

"GC baaaaaaad".

Having developed a number of solutions with Go, and been involved in the solutions of others, interestingly the GC has never -- literally never -- been an issue with the platform. It has never, once, come up as a weakness with the language.

Now I'm not using Go to make a real-time nuclear power plant controller, nor would I ever use Rust for that.

No, .NET and Java do escape analysis as well.

.NET does not do escape analysis: Every reference allocation starts as a generation 0 heap allocation, and every collection is just as complex as any GC collection. Java mostly performs it for, as you mention, lock eliding.

so heap allocations are essentially as cheap as stack allocations: just a pointer bump

When comparing stack versus GC heap, the allocation is irrelevant. It's the clean-up that is the difference: The fundamental mechanism of how GC works guarantees it cannot possibly even come remotely close to approaching the speed of stack freeing.