Too bad nobody directly addressed your question as to whether it had anything to do with pauses which would be unbearable on the gamer's experience.
Perhaps the question is still open whether properly managing allocation, using object pools as well as other strategies would enable writing triple A games with a managed language.
Or perhaps all we need is a GC race (à la JS engine race we've seen in the major browser) which Google might very well be starting with the recent efforts on the Go garbage collector.
It's not that you couldn't write a triple A game with a managed language.
It's that you can _quite easily_ write a triple A game without using a managed language.
For games, managing memory is not a big problem. For other kinds of apps, it can be. In some apps the lifetime of an object is not well defined. But in games, it tends to be very well defined.
There some AA or AAA games using languages that not are C/C++ . Severence: Blade of Darkness (Aka Blade: The edge of darkness), have a lot of code on pure Python. And it's well know that Naughty Dog use a variant of Lisp on his games.
Naughty dog used to use Game Oriented Assembly Lisp (GOAL), which was very scheme like. They dropped it for C++. Although they still use a Racket dialect for some gameplay scripting.
See my comment below, GC isn't the problem. It's being able to layout your memory appropriately so you don't cache miss which when everything is a single heap allocation becomes almost impossible.
> Or perhaps all we need is a GC race (à la JS engine race we've seen in the major browser) which Google might very well be starting with the recent efforts on the Go garbage collector.
This has been happening for a long time with Java HotSpot and Azul C4, which still represent the state of the art. Go isn't really doing anything new—it's still not generational, for example.
The speed of the GC isn't the issue (although it certainly can be). The non-determinism is. It's hard to control when a GC should happen, and when it happens at a bad time, the ramifications are perceived as an awful user-experience.
Perhaps the question is still open whether properly managing allocation, using object pools as well as other strategies would enable writing triple A games with a managed language.
Or perhaps all we need is a GC race (à la JS engine race we've seen in the major browser) which Google might very well be starting with the recent efforts on the Go garbage collector.