Why is D unpopular?

[Ola Fosheim Grøstad]

On Friday, 6 May 2022 at 06:57:52 UTC, Siarhei Siamashka wrote:
> For example, I can have a tool which calculates Pi number with 
> high precision. Then I bundle this tool as a part of the 
> project and simply use the computed constant in the source 
> code. This extra tool is very visible in the project structure 
> and there's nothing obscure about it. But with the CTFE 
> approach, somebody may be tempted to do the expensive Pi 
> constant computation every time at the compilation time. And 
> this may be hidden somewhere deep in the source code in a much 
> less visible way. Looks like such feature makes it too easy to 
> shoot yourself in the foot.

Yes, you have som points here.

The total development overhead of meta programming is costly if 
you don't write libraries that are reused in multiple projects. 
So in order to reap the benefits of having advanced meta 
programming in a language you need a community that builds 
libraries for reuse. In D that primarily means the standard 
library as the number and quality of third party libraries is 
limiting in comparison with more mainstream languages.

This could be improved by having a smaller stable standard 
library and in addition have a set of curated libraries that are 
more open to evolution.

As it is, D cannot capitalize on metaprogramming features, 
because the eco system for building reusable components isn't 
there.

If you have an unchanging external library and an advanced 
compiler then it could cache some of the work done for reuse to 
lower the compilation times.

This could be improved by having a strategy where the focus was 
on building a more modular compiler rather than adding more 
features to the existing one.

---

D is where it is because of management choices made (or not 
made), I think. Overall, D is not as popular as it could be 
because there are missing bits and pieces, both in the 
language/implementation and the approach to the eco system.

The solution to this could be:

1. Simplify syntax and semantics, clean it up with a focus on 
ease of use. Full feature freeze until this is done.

2. Create a compiler infrastructure that is modular where 
contributors can contribute in focused areas without 
understanding the whole thing.

3. Reduce the core standard library to something that is stable 
and can be evolved to be of the highest quality. Then move 
auxillary stuff to official support-libraries where breaking 
changes are more accepted (with semver support so you still can 
use an older version).

4. Map out the missing bits in documentation and official 
support-libraries that hampers productivity.

With no such clear strategy, nothing will change.