Large-scale, semi-automated Go GC tuning
I&#x27;ve written my own Go (subset + extensions) -&gt; C++ transpiler and using it on a game project: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=8He97Sl9iy0" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=8He97Sl9iy0</a> -- No GC, it does have slices and has access to an entity&#x2F;component API and with that I think you&#x27;re basically set and don&#x27;t need GC for games.<p>Example transpiler input &#x2F; output: <a href="https:&#x2F;&#x2F;github.com&#x2F;nikki93&#x2F;gx&#x2F;blob&#x2F;master&#x2F;example&#x2F;main.gx.go?ts=2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nikki93&#x2F;gx&#x2F;blob&#x2F;master&#x2F;example&#x2F;main.gx.go...</a> becomes <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;nikki93&#x2F;97ff376abb6718427387bb9cca2f548a" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;nikki93&#x2F;97ff376abb6718427387bb9cca2f...</a> Can call to C&#x2F;C++ (including templates) w&#x2F;o overhead.<p>That said, for logic that is heavy on async and escaping closures like how a lot of Go server code tends to be, a GC is maybe a reasonable tradeoff?