Challenging to overcome languages like C++, Rust, Java, and C#. D seems to sit somewhere in between, a better C++, but with (optional) GC. The thing is, Java and C# are already making strides into that space.
This specific article talks about using No GC aka "betterC".
D has GC by default; the use of GC is convenient and mainstream as most popular languages show - Java/C#/Python etc. What D gives is the unique ability to do No GC programming for the cases where GC is not desirable. Very few languages offer this capability.
Zig is interesting in this arena, but it approaches the problem from the other angle. It is manual memory management by default, but you can explicitly choose which memory management technique you want to use - at compile time.
Granted, this isn't optional GC, but does D really give you that? Don't you lose the entire ecosystem and stdlib with -asBetterC? Why would I choose that over rust/zig/c++?
FWIW, I am a big fan of D.
[0] https://docs.microsoft.com/en-us/archive/msdn-magazine/2018/...
-betterC is not the only way to avoid the GC in D, just the most extreme. The original motivation for -betterC was to ease porting C code to D. Walter has used it for that to port a good bit of his old C code over. But it's also suited for the space in which the blog author is using it, and some people just prefer it. You always have access to the existing C ecosystem, but there are people writing -betterC libraries in the D ecosystem. And as more people use it, I expect that space will grow.
1. either they don't use any library, including the standard one,
2. or the (standard) libraries must be written in both manual and managed memory management versions.
Additionally, the language must include extra syntax for memory allocation and access. This doesn't event include safety-related semantics, like Rust, which would be very hard to bolt-in (language-wise).
I hardly see any advantage in Java/C# having this functionality; Oracle is actually putting lots of effort into improving their garbage collectors. Java does actually have manual memory management (through Unsafe), although it's rudimentary; for the reason mentioned, I doubt it will ever be improved/expanded.
That's at least why I glossed over it.
Granted on Java side it required sun.misc.Unsafe, JNI or Real-Time JSR, while on C# side, a mix of structs, SafeHandle, MarshalInterop, unsafe and eventually C++/CLI.
So while not as pleasant as D, the cost to drop those eco-systems wasn't worth the cost to switch, and now 10 years later those eco-systems have doubled down on improving the experience for low level coding.
This makes it quite hard to sell D to those potential users.