> Zig particularly shines: comptime metaprogramming, explicit memory allocators, and best-in-class C interoperability. Not to mention the ongoing work on compilation times
explicit memory allocators: these are easily made, there's nothing special about them, I use them all the time
best-in-class C interoperability: Nothing beats D's ImportC, where you can import a .c file as if it were a module. You can even use ImportC to translate your C code to D! https://dlang.org/spec/importc.html
I think in many ways D was just too ahead of it's time; Packaging the same feature set and abstraction level of C++ in much cleaner and saner package wasn't really seen at valuable at that time.
I think that if D were to be "re-release today" with a lighter syntax, and some coporate backing a-la GO/swift/typescript/carbon; It would find quite a bit of success.
Also wasn't the D compiler proprietary and a paid product for a long time after its initial release?
No judgement against trying to monetize valuable work, but in this day and nearly everyone expects free and OSS compilers/interpreters and core tooling.
> Also wasn't the D compiler proprietary and a paid product for a long time after its initial release?
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.
I really like D and want to use D instead of Zig if I can...
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?!
Build the “killer app” that the audience wants and needs and where D is the best lang to do it and justify the investment in learning yet another lang. I have no idea of what that is and nobody knows, it’s the universal problem of any product/lang/tech. Right place at the right time I guess
Of course it can, but different killer apps for a different crowd. A missile tracking system wouldn't be the kind of application to do in PHP. Wrong app, wrong crowd.
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.
D doesn't have a bombastic or killer feature. What it has is elegance. It simplifies things, and smooths out the ugly stuff. You don't have to worry if your char is signed or unsigned, or how many bits are in an int, or whether to use dot or arrow, or remember to make your destructor virtual, and on and on.
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?
The D programming language shines:
comptime: https://dlang.org/spec/function.html#interpretation
metaprogramming: https://dlang.org/spec/template.html#function-templates
explicit memory allocators: these are easily made, there's nothing special about them, I use them all the time
best-in-class C interoperability: Nothing beats D's ImportC, where you can import a .c file as if it were a module. You can even use ImportC to translate your C code to D! https://dlang.org/spec/importc.html
Performance: same as C and C++