dlang would have been a very serious contender to C++ had it been fully nogc, stable & lean. Also dlang unnecessarily suffered low adoption in start due to competing stdlibs, trying to be both Java & C++ at once.
Yes it is very useful addition. Hopefully stdlib will also be fully nogc soon. Of all available options I am most hopeful of dlang. While it doesn't still have taken off it still is improving a lot & has high chances of increased usage. (Python also took years).
It doesn't need to be fully nogc. Not using the parts that use the gc will cripple nothing. You'll know which ones use the gc because they won't compile with @nogc.
There's no "nogc" containers in phobos, or allocators, or an idiomatic way to do safe manual memory management. It expects you to do it the C way. It's also impossible to implement some things because of how D does moving. There's a DIP in the works to change how moving works, but it's overly complicated and bound to introduce even more bugs. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1040.md
Most C++ codebases would be exactly the same with or without a GC. Probably 90% of collective programmer-intuition about memory allocation is either completely wrong or from thinking about a scaling to a point that most products don't get anywhere near.
There is more to performance than allocating memory. In fact some very performance-centric codebases do use a GC like unreal engine.
On the subject of games it always makes me chuckle when I see people complaining about garbage collection but then having 20 calls to malloc in their hot loop. All memory allocation is slow and not necessarily bounded.
I have written code that uses SoA, cache aware metaprogramming, inline asm, SIMD etc, with a GC because I knew I didn't need to allocate often.
On the subject of Java, I'm no fan of it but lots of projects would probably be fine - probably not quite as fast, but not horrifically so. On hackernews we only discuss extremely careful or expertly written code whereas in real life a lot people use C++ because it's what they got hammered into them at university 20 years ago as the fast language.
For example a lot of engineering and finance codebases are written in a very bad style of C++ code that would be improved by not having the programmers worry about memory too much - infrastructural code is more subtle, but most code serves a direct purpose like implementing some model. In these cases memory allocation is merely a means to an end rather than part of some grand strategy (i.e. it's not like writing a library)
I love when people bring up that UE has a GC, if it was written in Java, do you think they would have built a GC on top of Java's GC?
I guess it depends on the GC at that point, 20 mallocs isn't a lot but like the GC in D, it pauses all threads to do it's collection when you allocate. There's also a few games that use C# that have a really bad stutter because of the GC. There's nothing they can do about that though.
Unreal Engine mostly uses GC for game world objects. Only C++ classes that inherit from a special base class and opt-in are subject to GC. If they used GC for everything the performance would be much worse.
