The issue with D is not mandatory garbage collection, rather its quality and anti-GC religion.
Joe Duffy mentioned on his Rustconf talk that Windows devs even with Midori running in front of them, it was still a very hard sell for them to psychology accept it as doable.
The problem with Ada was basically expensive SDK, Pascal-like syntax and not being part of OS SDKs.
Only systems programming languages that are bundled with OS SDKs survive on the market, others either get a niche (Ada - high integrity systems) or fade into oblivion/maintenance (Modula-2, Delphi, ...).
The main reason being, companies already payed for OS SDK or gotten it for free with the OS.
Any other language must add a very worthwhile set of benefits for them to look beyond the SDK and possible toolchain integration issues.
> Windows devs even with Midori running in front of them,
There were GC'ed operating systems in the 80s. The point is not this. It's writing applications where you can maximize your CPU usage.
If it's a game, it means that you want to write your code so that the highest number of objects are visible on screen and are being updated on each tick.
If its's a multimedia software, you want to be able to run most sounds / videos in parallel at the same time.
If it's an interpreter, you want to have the highest instructions-per-second count.
etc etc... the point is not to have "good enough" performance, it never has been as soon as you use non-trivial apps. It's always "how fast can it be" / "how far can I push it", and an implicit language-level GC puts limits to this.
Having a GC enabled OS doesn't mean the GC runs all the time or it is the only way of allocating memory.
The last generations of Oberon OS had support for video editing applications as an example.
There are real time GC applications in production being used to control weapons systems, including live targeting and soft real time factory automation systems.
Regarding D, using @nogc or -vgc allows the developer to control when the GC works, it at all. What the language lacks is a GC that can match real-time GCs used in soft real time systems.
At very least, there needs to exist painless interoperability with the SDK toolchain, debugging tools, IDE, platform libraries.
Every piece of the puzzle that doesn't quite work like the SDK tools, means additional development/debugging effort.
Naturally the big question is always if the added benefit of using language X outside the expected workflow outweighs the extra development costs.
Just look at C++, it was on the path of being widely adopted by desktop OSes, every C compiler vendor was adding support for it.
Then BSD and Linux large scale adoption happened with GNU manifesto favouring C as the language to write portable software, Java and .NET came into the scene.
Microsoft was probably the only major OS vendor still caring about it, until LLVM happened and the wind started blowing again with C++11.
The embedded space is still an area where C++ is hardly seen, with a few conference talks last year discussing on how to advocate for it.
Now all major C compilers are written in C++, but had Microsoft focused only on .NET or LLVM never happened, and history would probably followed another path.
Joe Duffy mentioned on his Rustconf talk that Windows devs even with Midori running in front of them, it was still a very hard sell for them to psychology accept it as doable.
The problem with Ada was basically expensive SDK, Pascal-like syntax and not being part of OS SDKs.
Only systems programming languages that are bundled with OS SDKs survive on the market, others either get a niche (Ada - high integrity systems) or fade into oblivion/maintenance (Modula-2, Delphi, ...).
The main reason being, companies already payed for OS SDK or gotten it for free with the OS.
Any other language must add a very worthwhile set of benefits for them to look beyond the SDK and possible toolchain integration issues.