[jokoon]

You just mentioned 2 garbage collected languages on a game dev topic. I don't think they're adequate. Remember how the article was very insistent about being able to control memory and CPU resources. Those are one of the few reasons C++ is not dead.

Rust? I don't see it either.

[_lbaq]

Garbage Collection is not per default something bad, even in game development, its a method of memory management, just like reference counting, or manual memory management.

If you are allocating memory in your renderloop, your likely doing it wrong. Allocation outside of this critical path, well, chose your poison.

GC will consume more memory, but likely to be faster when it comes to allocating and deallocating large amount of small blocks.

Reference counting, if you do it properly (to avoid thread starvation), is costly. Cheap atomic reference counting, involves a calculated risk that you may have threads hanging.

Manual memory management, well, we all know the cost of that :)

That being said, many many games are today developed with Unit which uses C# as its primary programming language.

[HippoBaro]

Sure, you can. But then you need to manage when GC triggers. Because if you don't, you'll drop frames. And then the real choice is between C++ where there is (little) extra work getting RAII correct vs GC languages where you need to keep preventing GC up to a point where it's okay to freeze the universe.

[ulber]

A clever approach for VR that was used in Downward Spiral [1] (a Unity game) is to add a periodic eye blinking effect and trigger the GC on a black screen.

[1] http://www.3rdeyestudios.fi/downward-spiral-horus-station/

[_lbaq]

There are plenty of predictable garbage collectors now days, Shenandoah for example, Azul's C4 implementation is completly pause-less and concurrent. ZGC provides very low pause times (1 ms)

[jokoon]

You can allocate stuff on the stack instead, or keep things in a game state.

[deng]

His point is that many studios nowadays use an established engine and do not develop in the C++-from-scratch-style. Especially smaller studios do not have the capacity for this and also depend much more on cross-platform availability to generate more sales. So they use Unity or stuff like Gamemaker Studio and use whatever binding is available (C#/Boo/Js for Unity, Gamemaker Studio has its own language). Or they even turn to something more exotic, like Haxe/Heaps.

[andrewmcwatters]

A big part of this is ecosystem. You have so many game libraries and software that are written in C and C++. To many gamedevs, Rust is just a systems language Go. It doesn't bring anything significant to the table compared to just using a limited subset of C++.

[edoo]

The big game mills don't care about languages, they care about the bottom line. If you can churn out the same quality product with more junior engineers because the language is less difficult to master it is going to happen rather soon.

[edoo]

I see it in the sense of writing your game logic in Go using bindings for Unreal or one of the big ones. The real performance critical stuff will probably always be in C++. The popular game Rust (not language) uses Unity and the overall engine is pretty bad but it works and made them a fortune. By its nature it is incredibly extensible. You can mod it by dropping source files with hooks right into a directory without compiling anything. The ease of that kind of stuff draws people like crazy.