This is technically correct, but not pragmatically correct. D doesn't have every memory unsafe operation plugged, but it's pretty darned close, and does have the major ones covered (like array bounds checking, alternatives to pointers, RAII, etc.).
> library support
D has excellent library support.
Yeah but C++ has all of that, too, as well as a vastly broader ecosystem in the space of non-GC'd, ultra-high-performance languages.
fyi std::array also has bounds checking, you're not limited to vector<> to have that.
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.
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.
And in Unreal you can use GC in whatever components you feel like, it is a matter of weighting where it makes sense.
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
void do_stuff(void) {
asm {
}
}
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.
And the game-industry as a whole is moving to data-oriented design, which tends to be hard to do at best (if not downright impossible) in most GC'd languages.
Regardless the transition from C to C++ has no performance cost (often a performance advatnage), so I'm not sure why you're bringing that up as some significant migration in this case? It doesn't support any argument for a transition from C++ to C# or similar, as that comes with a huge performance cost. Particularly in an era where CPU performance hasn't improved for almost a decade now.
Additionally dataflow languages are better suited for GPGPU programming than plain old C and C++, as Google is exploring with XLA on Tensorflow, and game engines with graphical tooling for shader generation.
Again, lets come back in 10 years and see who was actually right.
Doing the next Fortnite, Crysis or ground breaking AR/VR/Ray Tracing? Sure, every ms/byte counts.
Doing a typical Flash like casual game, game prototypes at Ludum Dare, participating at IGF? Having a GC around isn't the biggest concern.
But for those cases, what would move you to use D instead of an entirely memory-safe language like Python or Lua?
To justify using D for games, you'd need to find a use-case where speed (e.g. targeting 60fps) is high-priority enough to be writing a lot of low-level code; and yet, where "having a CG around" still won't cause problems. Can you think of one?
Some AAA studios do use D instead of a C++ based script language exactly for that.
This is actually one of the worst features of GC where game development is concerned. Memory usage isn't the main problem to be solved in game engines, it's consistency of execution time.
In that context, even if you're spending more resources on memory allocation/deallocation overall, it's much better to know that you can consistently fit that overhead into the 16 milliseconds you have for this frame rather than having it mediated by a system you do not have direct control over.
There are also other advantages to having more direct control over memory management than is typically allowed by garbage-collected languages. For instance, CPU cache-coherency can be a major performance concern when dealing with the type of computation required for games. Without being able to lay out memory and deal with memory in a precise way, there are whole categories of optimization which are not really possible.
Non-conservative GCs use a lot of extra metadata to be able to figure out what's a pointer and what isn't. Conserative GCs leak.
In both cases GCs cut into worse case latency.
This isn't to say that Rust is better than D, but it is to say that Rust targets a gap in the market whereas D is trying to have the same tradeoffs as C++ but be better, which is nowhere near as compelling for most developers who've invested a lot of time into learning C++. C++ developers don't use D for the same reason that most people don't switch from qwerty to dvorak even though it's technically more efficient. It's not such a qualitative change that it's worth the retraining.