[jordigh]

Is the D GC actually that bad? Do we have benchmarks or something to prove that the GC means D is dead in the water? I always hear about this hypothetical danger of GC but my D usage hasn't found it and my D programs typically match or outperform my C++ programs. I mostly use it for numerical code, so maybe that's why I'm not feeling the pain of the GC?

To address your final point, I find D vastly superior to C++. Immensely, tremendously, bigly superior to C++. It's so nice, it's so pleasant, it's so easy. It's not an incremental change, it's a whole new world of no segfaults, no template metaprogramming, beautiful error messages, beautiful compile-time calculations.

[kllrnohj]

There is no such thing as a "good GC" in this context. Game engines go to great lengths to do things:

1) Have bounded memory usage 2) Have consistent frame times

These goals are critical to maintain a consistent framerate on fixed-memory devices (aka, consoles). GCs, by their very nature, are not compatible with either of those goals. They need lots of spare memory to go fast, and they cause hiccups when collection happens. They are a non-predictable, non-consistent load.

If you're not working on a problem that is a sustained, consistent workload that needs sustained, consistent result generation then no, you probably won't see the same GC problems. GCs work great when the work is bursty or when the work has no latency associated with it. There's an awful lot of programs that fit in that model. Games just aren't one of them.

[DblPlusUngood]

How are GCs not compatible with bounded memory use? Though many GCs size allocation arenas proportionally to the live data, there is no fundamental reason why the allocation arenas couldn't be fixed-size (of course, they must be large enough for good performance, etc.).

[p0nce]

And yet there are GCs in Unity and Unreal Engine, the most popular game engines of today.

[monocasa]

Only the scripting code is GCed. The core engine in both cases is C++ with manual memory management for the reasons stated above.

[pjmlp]

On Unity's case with some subsystems in the process of being replaced by HPC#.

And in Unreal you can use GC in whatever components you feel like, it is a matter of weighting where it makes sense.

[kllrnohj]

> On Unity's case with some subsystems in the process of being replaced by HPC#.

They are converting their C# code to HPC# which specifically does not do GC allocations.

https://youtu.be/NF6kcNS6U80?t=886

  HPC#:
   * no class types
   * no boxing
   * no GC allocation
   * not exceptions for control flow

They are building a compiler to eliminate the GC from the GC'd language they were using.

[pjmlp]

Once upon a time, C code for games engines looked like this.

    void do_stuff(void) {
        asm {
        }
    }

Hardly any C code in sight, and most of the stuff could equally have been coded in MASM/TASM with their higher level macros.

Eventually game devs migrated to proper C.

A couple of years later, C++ code in game engines, was not even "C with Classes", rather C compiled with C++ compiler.

Eventually game devs migrated to proper C++.

Looking at the past, which I was partially part of, I see HPC# as a stepping stone into regular C#, in a similar vein that C code of yore was full of inline Assembly.

It is of course a matter of opinion, however I like to look at the past to see where the future leads to.

So lets see who's is right in about 10 years, regarding how game engines get implemented.

[swsieber]

Electron is a very popular application framework today.