Hacker News Reader

Comment by pjmlp | Hacker News Reader

> Go is a bad choice for game with its unavoidable GC.

Better let the Unreal guys know about it then.

There's a big difference in engine support for GC of a certain object type with lots of support for tuning (https://wiki.unrealengine.com/Garbage_Collection_%26_Dynamic... and https://docs.unrealengine.com/latest/INT/Programming/UnrealA...) and language-level untuneable GC of everything.

Not all language-level GCs are untuneable .

Also if one doesn't allocate like crazy on the heap, there is no reason the GC needs to work.

I agree, but the GP comment was in the context of Go. Nim is a newer option I'd like to see tried more, its GC is optional and swappable.

If you never run out of memory you'll also never need to GC. ;) Or even free(), just let the program finish and reset the machine. (Actually not too weird in some embedded systems...) Some languages make it easier to not heap allocate than others, or notice when you are heap allocating. I hear Go does better than Java in this regard. But if you're facing a performance issue at the level where you're fighting the GC as the biggest barrier, and the language doesn't give you much assistance (like being able to choose latency/throughput tradeoffs or controls on non-determinism), that's a sign the language isn't that suitable for that performance problem domain. With performance sensitive games, you're already in the corner of having to worry about hardware details, so there's a strong incentive to just start the fight at the beginning without your hands tied by some language's static GC.

Not all games need to be the next Crysis.

If fact, the majority of them gets abandoned even before memory pressure starts to be a relevant issue.

Even if Go isn't at the same level of D or Modula-3 in regards to memory management (heap, stack, global), it is already quite usable for many types of games.

Yeah, at some point it doesn't matter what language if the game is just game logic on a standard input and output layer that are already fast. Even high end engines like CryEngine often include a scripting layer in some higher level language like Lua that probably has GC, because it's nice to have for game logic that doesn't have the same constraints as other parts of the game. (http://docs.cryengine.com/display/SDKDOC4/Lua+Scripting)

As I mentioned in another comment a lot of fun games have been made in all sorts of languages. That doesn't really make any of them suitable for games though, and you'll still find far fewer examples of game engines in GC languages.

Actually, I am old enough to have heard the same kind of argumentation against adoption of C, Turbo Pascal and C++ for game development, depending when I heard it (80's, 90's, early 2000's), because how we do it today is the only way possible.

Game developers have a tendency to only update their tools when OS or console vendors force them to do so.

Lua has a GC, but it's incremental and tunable. Video game scripting is actually one of the biggest use cases for Lua for that reason. Lua is also one of the fastest scripting languages, especially if you can get away with using LuaJIT.

The important difference is that not everything in Unreal is GC'd, only UObjects. Internally the rendering, animation, networking and other high-performance subsystems don't use GC because they can't afford the overhead. Being able to opt in to GC where it's useful is great, being forced to use it everywhere can be a hassle.

> Being able to opt in to GC where it's useful is great, being forced to use it everywhere can be a hassle.

True, but just because a programming has language level GC, it doesn't mean it must be used everywhere.

If one doesn't allocate like crazy on the heap, there is no reason the GC needs to work.

Also using value types is always an option.

One also doesn't call malloc() in such high-performance subsystems.

Reply on news.ycombinator.com