Why is D unpopular?

[Ola Fosheim Grøstad]

On Sunday, 7 November 2021 at 06:36:48 UTC, arco wrote:
> 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.

Yes, I think you get this response because people have written 
successful applications for things like micro-services. But there 
is a difference between being usable and having solid support.

So the real challenge for D is focusing and providing solid 
support for something specific. I think everyone understands 
this. People who use D in professional contexts seems to be ok 
with creating their own frameworks, which requires dedication.

As of today D is for programmers with a high level of dedication. 
That basically puts D in the same category as C++ and Haskell, 
but not in the same category as Go, Python, Java etc.

That there are fewer programmers with a high level of dedication 
to a single language should not surprise anyone.


> that GAT's are being stabilised and the language is basically 
> on its way to support HKTs.

What does "GAT" and "HKT" mean?


> It also offers sophisticated error handling without using 
> exceptions (another big win in low level code).

Doesn't seem to be better than C++20 in that regard? How is 
Rust's error handling sophisticated?


> 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.

Go is ok for tiny applications that fits well to their standard 
library, but the language does not seem to scale very well. I am 
not so sure about productivity. I want to see that measured in 
terms of long term evolution and maintenance.

I would prefer Java, but Go's runtime is lighter and spins up 
faster on the platform I use, so Go it is. Has nothing to do with 
the language, only runtime and stability. The JVM clearly 
provides better languages than Go…

D isn't stable enough. Both Java and Go have stellar backwards 
compatibility and that is critical for servers where you may be 
forced to upgrade over night (either because of security issues 
or because the cloud service requires you to).


> D's situation here is a kind of lose-lose: it is primarily and 
> clearly a GC language, which hampers its use for low level 
> code, yet where a GC is desirable, it can't compete with Go's 
> GC.

Well, it is primarily C with some adjustments and additions. What 
is unfortunate is that the language does not fit well with global 
GC and there is no willingness to do what is necessary: switch to 
a GC model that is local to the computation and use  reference 
counting elsewhere. (other options are also possible)

There is also little willingness to adjust the language, clean 
out inconsistencies,  improve on C (like fixing the flawed 
operator precedence rules of C). These language issues are 
perhaps not so apparent for people who primarily use D, but 
stands out to anyone with a comp sci background or who use many 
languages.

I see people claim tooling as the "one issue". I don't think so. 
I think language issues come first, then eco system, then 
tooling. Can I prove it? No, but if you have quirks that is 
off-putting to highly educated programmers then that means less 
sophisticated eco system. This is particularly true for D and C++ 
as making good use of metaprogramming requires high levels of 
sophistication!

The one issue that truly prevents progress is that the language 
designers are happy with the language as is, and they are not 
interested in changes (only additions).


> Regarding Python, its biggest advantage (other than its 
> outstanding ecosystem) is that it's a dynamic language.

And its biggest disadvantage. However now that type annotations 
have been added, you basically have gradual typing in Python, 
which is very productive.


> 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).

Moving target. You need vast resources to address the continuous 
changes on mobile platforms. The graveyard for mobile cross 
platform frameworks is enormous! It is improbable for D to 
succeed in this field.


> 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.

D is retaining the disadvantages because features are being 
replicated from other languages rather than reinvented. If you 
want to combine low level programming with high level programming 
you need to go further away from the mainstream than D. (E.g. 
choose the actor model).

In order to reinvent, D needs to accept more breaking changes on 
the language level.