On Friday, 28 October 2022 at 11:39:12 UTC, Guillaume Piolat wrote:
> the better it is, the more any perceived flaw is painted as huge and "show-stopper".
This is a truth I have encountered numerous times in game design. The more rich and rewarding your feature set and environment are, the more it generates a sense of "well, if only it was BETTER, THEN it would be just what I wanted!" The more restricted something is, the more content one remains with what has been accomplished within the bounds of the design.
And to respond to the OP, D is definitely good enough that I don't want to switch to anything else for this purpose when I don't have to! And by good enough, I mean great. I definitely feel D is the "should have been, but wasn't" language that C# ended up becoming for claiming the gaming industry (or at least squeezing alongside C++, which will sadly never leave us). It's just a joy to program in, the metaprogramming capabilities are fantastic. I don't know how to really quantify whether D does them "better" than other languages, but it always feels cleaner to me. I am not a language design expert, I am just a humble tiller of the soil that is allotted to me. But IMO D lets you write things that end up looking beautiful. I put together a quick RPC module to call functions on client objects from their server representations in a multiplayer game engine. All parameters matched for implicit conversions, marshaled, bundled and prepared for network sending. Hard compiler errors on any mismatches. Any method I want replicable, All I need to do is just drop a UDA onto it. No complicated lookup tables or list of mangles or serialization definition documents. No need to add any code or create stubs anywhere else in the project. It all "just works". The entire RPC module? 194 lines of code. Brings a tear to my eye. The thought of building the equivalent in C# gives me a headache. C++? Migraine. And I do not care for Rust.
On Friday, 28 October 2022 at 13:23:42 UTC, Adam D Ruppe wrote:
> in fact
d rox
This. Although I do agree that allocators should be tuned up and taken out of experimental. I would personally love to see alternative memory management strategies made to feel more "at home" as base language features, instead of tricks with structs and templates. Just my pipedream.