No judgement against trying to monetize valuable work, but in this day and nearly everyone expects free and OSS compilers/interpreters and core tooling.
The backend for the DMD compiler was not fully open source for a number of years. That's because Symantec owned some of the code and they were not willing to let it be relicensed. They did allow that in 2017. It was never a paid product AFAIK.
Overall, that was beneficial to the D community. The GDC backend has always been open, and for some time has been part of GCC. The LDC backend was developed to use LLVM. It's possible that there would not have been motivation for those projects if DMD's backend had been open from the start. DMD compiles fast but the performance is not competitive with the other compilers if you're working on something that needs to push the CPU to its limits.
Sadly, the number of people nerdly enough to want to work on a code generator is very, very small. Me, I find it quite enjoyable.
I cannot even think of anyone who wrote a full stack compiler these days.
Most components of the D standard library (Phobos) use garbage collection by default (when I last checked). This unfortunately removes it as a contender in the same space as Zig and Rust. And once you move to the GC space, there are a truckload of GC languages - it is the non-GC ones that are rare.
IMHO stdlib GC was one of the major barriers stopping D in the system programming space.
But it's difficult to do so! Nothing to do with marketing in my case, at least. The reasons are :
* `dub` is badly documented and does dumb things like including test code in the generated binary.
* `serve-d` is terrible. It can't handle even my little hello world programs - either crashes or consumes 100% CPU until I manually kill it.
* MacOS support sucks. All the time I have problems: the linker didn't work for years (fixed now). Immediate segmentation faults currently (fixed in nightly AFAIK). C code using the new flat128 doesn't compile (I think it was fixed already?). Just constant frustration.
* Too many features, many broken. It has an experimental borrow-checking feature, I tried to use it but it's largely undocumented. People in the Forum told me to that feature is completely unfinished. It has an allocators package as well, but no idea how I can make use of those like I would in Zig. Would love to see a well written post about that.
Using D in betterC mode is what I am most interested about exactly because it looks more like Zig and C than Java - and performs much better. But currently, that means forgetting about Phobos, the standard library, as that's written exclusively with GC and Exceptions in mind. Maybe that's ok as you can just use all C libraries you want, but would be nice to have some D conveniences to make that worthwhile.
Apart from that, I completely agree that D's comptime and metaprogramming is the best I've seen in any language (except for Lisp of course). All I need to keep using D is much better tooling and clarification about what parts of the language are "half-baked" (especially around DIP1000) and which parts are stable - perhaps "editions" will give us that, will check it out when it's ready. Oh and also top-notch MacOS support... I know that's a moving target but even Zig manages to handle that just fine, why not D?!
My library for example is not using the GC, but I don't put @nogc on every function because it does not make sense. Here is the link to the library: https://github.com/Kapendev/joka
I don't understand the special purpose behind Zig's allocators. It's just an interface. I make custom allocators in D all the time, it's trivial.
Dip1000 is also an experimental feature and is not part of the core language.
On a more pragmatic note, D has a notion of "sinks", aka output ranges. They provide a simple interface that accepts input, which is appended to the output range. Since the user of the sink has no idea what the sink is doing, just that it accepts input. This is a fun and very practical way to move the choice of how to allocate memory to the caller rather than the callee.
gdc and ldc offer top notch D support for the Mac.
Have you tried using D on Mac? That's almost impossible to do!! You get a segmentation fault immediately when using VS Code because it wants to download its own DCD and that's apparently compiled with DMD?? Everything that gets downloaded in binary doesn't work on MacOS. I only managed to get it working on emacs after building DCD locally with LDC AND making sure emacs does not try to use anything else. But even then, as I said, serve-d barely works (not sure if that's MacOS-specific). D has the worst MacOS experience of several dozen languages I've tried. Even FORTH just works, but D just does not.
I'm aware of D since it's inception more or less but don't know it very well. I would say D lacks a "bombastic" feature and maybe that's both the reason is not used more but also why is such a good language.
It's not "memory safe" like Rust, yes it's fast but so is C/C++, it doesn't have the "massive parallelism/ always-on" robustness like Erlang. It has a bit of everything which is good and bad.
Being a mid all-arounder is OK in my book, perhaps it's more a matter of some "post-AI" tech startup adopt it and get massive or famous, like Ruby because of the Web 2.0 era or Erlang with the Whatsapp thing.
Maybe D is good the way it is and will always be there.
It's a more memory safe language than C/C++, no need to worry about forward references, strong encapsulation, simple modules, and so on.
And let's face it - the C preprocessor is an abomination in modern languages, why does it persist?
We were able to get dmd's backend license fixed in 2017.