I've been using D for my amateur game engine development for a while now and so far it's been a pretty good experience. Thanks to reflection features I can ser

I've been using D for my amateur game engine development for a while now and so far it's been a pretty good experience. Thanks to reflection features I can serialize/deserialize entire scenes just by annotating the fields in structures as needed, and can also autogenerate editor fields for inspector views. With C++ I'd have to do some out of place looking define magic to generate my structures and it wouldn't just work with any struct. Unlike my fellow D game developers I don't fight the GC. I don't use any of the @nogc features in D or obsess about manual memory management. I have a fairly beefy machine, but still, I think the dangers of D's GC are somewhat overblown. There was a blog article back in the day by someone writing a 3D space game in D and it was often referred to as an example of how bad D's GC is, but there wasn't really enough data in that post to know about the methodology. Firstly, in a game most of the data should be preallocated anyway, in the game loop there isn't that much to allocate. Secondly, D has value types, so there's much less pressure on GC because you can stack allocate things like vectors or matrices. Sure, in other GC languages a sufficiently smart VM could probably optimize that out and avoid the GC, but I doubt it would catch most cases. I also like how easy it is to interact with C. This grants me access to gamedev libraries such as bgfx, wgpu-native, ODE, NewtonPhysics and many, many more. C++ interaction however never cared much for. I feel like D spent too much effort here, even adding language features (copy constructors) to interact better with C++. In the meantime, it seems that it's still hard to interact with C++ libraries from D, and ironically I feel like languages like Rust or Zig have a better interop story with popular C++ libraries like Qt or Bullet, despite not investing as heavily into that. My main current issue with D is that as a community project, it seems to lack some direction. There's some very talented people working around the project, but most of that work is done on a specific issues and projects people want to work on. Since a lot of the work on D is unpaid work, you can't force people to do what you want them to do. However, the language lead team should influence the direction of the language and provide a path forward. It's getting better in recent times, so there is a lot to look for in that aspect. The multiparadigm aspect of D and its flexibility can be detrimental too sometimes. There are some subgroups in the language community that approach the language in a specific way and feel their way is the true "D way". For example, you have OOP folks that would like more features like named constructors, you have template metaprogramming folks who would like to remove most D features such as classes and just replace them with some metaprogramming template magic, you have folks that disable the GC and avoid the standard library from the get-go. This causes some friction, because any new feature for the language would have some opposition from the other side who will consider it bloat and unnecessary. In some ways the article about "Lisp curse" applies well to D. These factors however don't really influence me personally, because I get to pick the features I want to use and can avoid the ones that I don't see the benefit of.