The D language has a lot of features that should appeal to large software projects, including a certain amount of feature overlap with the functional languages. It hasn't really taken off yet, but it could be a killer app or two away from taking off. Maybe.
I say all that to say that Go seems fantastic for server-side programs but I suspect other prospective languages will be better for large, performance-critical games, but I've been wrong before.
Also, I doubt Carmack would be interested in Go -- based on his previous talks, he seems to be going for a more functional approach. Go is imperative to the bone.
There's no technical reason I can think of why Go wouldn't work just as well as C# (XNA/XBLA/MonoTouch/Android) or Java (Minecraft etc) for game development.
Garbage Collector sweeps can indeed be a performance problem but there are obvious ways of minimizing it's impact during gameplay.
Overall I think (read guess) that unless you are doing some sort of physics simulation, typical game logic requires relatively little cpu power and for the graphics there is hardware acceleration doing the heavy lifting.
> Overall I think (read guess) that unless you are doing some sort of physics simulation, typical game logic requires relatively little cpu power and for the graphics there is hardware acceleration doing the heavy lifting.
Well, it of course depends on the game. AAA games spend all the CPU budget allocated to them.
Granted I haven't used Go myself (leaning towards Rust) but I've read that Go is already being employed in production scenarios with good results.
http://www.youtube.com/watch?v=BMRlY9dFVLg http://www.youtube.com/watch?v=iMMbf6SRb9Q
which are game examples as part of a game engine framework written in Go, seems to move smoothly with lots of objects including 2d physics.
Carmack seems to be interested in correctness and safety, neither for which Go has any significant offerings. In fact, it seems to be a step back for a "modern" language -- it has null pointers, no way to explicitly enforce immutability, no generics, and a crude and verbose way of handling errors. A panic() call in the code brings down the entire program.