Why is D unpopular?

[arco]

On Friday, 5 November 2021 at 13:10:58 UTC, Guillaume Piolat 
wrote:

>
> Interesting point of view because obviously it isn't the point 
> of view of many in the D community. I'll spare you the details 
> but it is very possible D outperform those in their specialty.

I know it's not the point of view of many in the D community, but 
at least in part this topic is all about the gap between the PoV 
of the D community vs the rest. When the D community believes D 
has many advantages but the rest of the developer community is 
not rushing to embrace it, and when at the same time the OP asks 
why is it so, then it's fair to ask whether they might actually 
see certain things that the dlang community just doesn't want to 
recognise.

For low-level systems programming, Rust is fully committed to 
manual memory management unlike D with its schizophrenic attitude 
towards the GC. Together with the borrow checker, Rust can offer 
some static guarantees that D can't and which are especially 
important in low-level code. However unlike Phobos, using Rust 
that way also doesn't require you to forego the standard library. 
At the same time, its type system is richer than D's, with full 
Hindley Milner inference and especially now that GAT's are being 
stabilised and the language is basically on its way to support 
HKTs. It also offers sophisticated error handling without using 
exceptions (another big win in low level code).

Many people have forgotten it now but at one point, Rust had 
classes with inheritance as well as a GC. It was concluded that 
those features didn't belong in a systems language and were 
removed. This is probably Rust's greatest strength over D: its 
consistency, the follow through to ensure that features that are 
declared stable are really rock solid and make sense within the 
language's general philosophy. Sometimes the choice made is the 
wrong one, of course (the async semanitcs don't really play well 
with Linux's new io_uring API, for example), but even then, the 
community is fully committed to support them into the future with 
all the care it takes, and find solutions that work whenever they 
made the wrong call. Add a homogeneous ecosystem, top notch 
tooling and documentation and it's easy to see why it has been so 
successful.

The second example was Go. It's often criticised for being a 
limited language with not much expressive power. Undeniably D's 
modelling power is far greater than Go's. It's also largely 
irrelevant: Go still doesn't even have generics in stable and it 
hasn't slowed down its adoption. Why? Because Go's designer knew 
their target: corporate coders whose only concern is productivity 
and time-to-market. Go is not "elegant" or rich or powerful, but 
it's extremely easy to use and quick to get things done. GC is an 
advantage for those application and Go's is best of breed. D's 
situation here is a kind of lose-lose: it is primarily and 
clearly a GC langauge, which hampers its use for low level code, 
yet where a GC is desirable, it can't compete with Go's GC. 
Goroutines are another big item: a web application developer 
needs to react asynchronously to an event and calling "go 
process_stuff()" is an immediate answer. They want the code to 
work today, not spend time marvelling at how cleverly (or 
"cleverly") a framework that doesn't compile any more with a 
recent compiler used to implement it through template 
metaprogramming. Go gives them that and the time and effort it 
saves is worth every penny.

In many ways, Go epitomises an important trait of the Zen of 
Python: for every problem, there is one obvious way to do it. 
That's exactly what that programming community wants: a language 
that gets out of their way and just gives them the simple, basic 
building blocks (but of excellent quality) that allow them to 
solve their actual problem.

Regarding Python, its biggest advantage (other than its 
outstanding ecosystem) is that it's a dynamic language. 
Prototyping, testing, customising etc will always be easier and 
more flexible in Python than in any compiled language. Plus its 
conscious focus on a simple syntax makes it in my opinion the 
modern day heir to the BASIC of the 80s in terms of universal 
applicability and a kind of immediacy.

So where does that leave D? Someone here mentioned mobile 
development. IMHO that is one huge missed opportunity for D. It 
could have been a language of choice on Android (better than 
either Java or Kotlin). But note that no-one develops mobile 
applications in C, C++ or Rust. That's because once again, it 
requires a language that seamlessly blends with the APIs, doesn't 
bother the developer with the minutiae of memory management etc. 
D's general approach has been to always try to have its cake and 
eat it too. It wants a GC but at the same time wants to pretend 
that it doesn't need a GC, it wants to support OOP (with 
inheritance etc) and at the same time tries to downplay it, etc. 
Ultimately in each of these cases it fails to provide the 
advantages of either of the valid choices while retaining the 
disadvantages of both.