Possibly only because they have been around for longer. The CLR 1.0 GC was a terrible beast. I'm sure that the earlier Java GCs were horrible things, too.
sufficiently complicated game will spend a lot of time dealing with memory issues.
This is precisely why gamedevs are going for data oriented design, it all does come down to this at the end of the day. In theory a GC doesn't actually get in the way of DOD, because in the strictest definition it simulates infinite memory (it is, strictly, not a memory reclaiming device). GCs are getting better and better at doing this with less and less overhead. The newest concurrent CLR GC is pretty impressive, it very nearly never has to stop-the-world.
Sorry, I didn't mean to imply that I'd use them because of Go's garbage collector, which is vastly improved and arguably the best part of the entire ecosystem these days. I'd use the JVM or the CLR mostly because I am more convinced than I am about almost any technical topic that Go is a creeping, faddish horror that resists decent design practices for applications over a trivial scope, made by a team that took all the wrong lessons from Java and C++ and made a language worse than one or the other at almost every task that I can think of.
Comments
Possibly only because they have been around for longer. The CLR 1.0 GC was a terrible beast. I'm sure that the earlier Java GCs were horrible things, too.
This is precisely why gamedevs are going for data oriented design, it all does come down to this at the end of the day. In theory a GC doesn't actually get in the way of DOD, because in the strictest definition it simulates infinite memory (it is, strictly, not a memory reclaiming device). GCs are getting better and better at doing this with less and less overhead. The newest concurrent CLR GC is pretty impressive, it very nearly never has to stop-the-world.
Sorry, I didn't mean to imply that I'd use them because of Go's garbage collector, which is vastly improved and arguably the best part of the entire ecosystem these days. I'd use the JVM or the CLR mostly because I am more convinced than I am about almost any technical topic that Go is a creeping, faddish horror that resists decent design practices for applications over a trivial scope, made by a team that took all the wrong lessons from Java and C++ and made a language worse than one or the other at almost every task that I can think of.