Why is D unpopular?

[arco]

On Sunday, 7 November 2021 at 09:18:37 UTC, Ola Fosheim Grøstad 
wrote:

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

It is a very common response when people are enthusiastic about a 
particular technology. People for whom using D is a goal in 
itself are using it, but the others are not going to move to it 
for the sake of using D. They would do it if D solves some 
problems they are currently facing, or if it allows them to 
achieve their own objectives (which are probably unrelated to D) 
better than some other alternative.

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

But there are two aspects to this where in my opinion D is 
currently failing and both are more cultural than technical. That 
D "can" do something is not enough; that someone successfully 
wrote some app in D doesn't mean D is a good choice for that 
application field. Like any language, D must not just be good at 
something, it must be the best at something. It's fair to say 
that currently it isn't. The dlang community wants to push static 
if etc. as their killer feature but it seems that more often than 
not, it elicites a "meh" reaction.

The other problem is that D seems deeply allergic to making hard 
decisions. From reading this forum it seems to me that the 
overall attitude within D is that it should offer choices, not 
enforce decisions. But in the real world, that's often a bad 
thing. Another language with the same mantra was Perl. Look at 
what happened to Perl the moment we got Python, Ruby etc. 
Enforcing decisions is a Good Thing: it ensures that people 
understand each other's code, that analysis tools can do a much 
better job, that people won't roll out their own error management 
that doesn't work together with someone else's, that there will 
be consistency in memory management, etc etc etc. Once again, the 
two languages somewhat comparable to D that "made it", Go and 
Rust, are all about enforcing what they deemed to be their way to 
do things. That doesn't mean it's the only legitimate way, but it 
means that if you want to do X, this is how you do it in Go (not 
that there isn't a one true way, but you are free to try to 
devise 15 different ways). And if the Go way doesn't work for 
you, that's perfectly fine, there are other languages that would 
be a better fit for your problem. Same for Rust.

This is a hard lesson that D desperately doesn't want to learn. 
By trying to appease everyone it ultimately doesn't win for 
anyone in particular.


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

Not really. C++ has a huge wealth of frameworks, IDEs, tools and 
libraries that make its strength. Plus ever since C++11 it has 
been dedicated to recognising and attempting to fix its problems 
(although the solutions are often a kind of placebo: there is no 
way to ensure, for example, that unique_ptr is really unique, or 
that an object won't be accessed after std::move). I personally 
dislike C++ with a vengeance, but if you develop in C++, you will 
never be on your own. Not so with D.

Haskell is a different beast altogether. It's a niche language 
that knows exactly what it wants to be and especially what it 
doesn't want. It's the perfect solution for a specific area of 
problems. Which illustrates the discussion above.

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

Of course. But why should they? A language is nothing more than a 
tool. Carpenters are dedicated to building furniture, not to 
using a hammer.

> What does "GAT" and "HKT" mean?

[Generic Associated 
Types](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html).

HKT = Higher Kind Types. GATs are a subset of HKTs.


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

In several ways. Rust has proper sum types and a "match" 
statement that guarantees that all cases are covered (plus it has 
functional semantics). That alone makes it more general and safer 
than C++. It also has some syntactic sugar (like the ? operator) 
and the pseudo-monadic methods and_then etc. that together make 
it basically as easy to use as exceptions. But it has also the 
advantages that since all errors are in-band values, they are 
friendly towards multithreading and parallelisation. With the 
Rayon library (which provides parallel iterators) you can for 
example write something like:

```
let results = data.par_iter().map(|v| 
process_value(&v)).collect();
```

This will run process_value() in parallel on all elements of the 
data collection. If process_value() can fail (= it could throw in 
D or C++), it will return a Result. You will get a collection 
(like a Vec) of Results and you will be able to check which ones 
have succeeded and which have failed.

Using exceptions in multithreaded code is... no comment.

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

It seems that those who use Go, Google to begin with, beg to 
disagree that it's just for tiny applications. As for whether it 
scales well, its long term evolution and maintenance... how do 
you think it compares to D as far as hard data and proof of the 
pudding are concerned?

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

Of course it's also a big disadvantage. But notice the pattern: 
Python is dynamic - type annotations don't change that, it can 
still alter classes at runtime, reflect etc. It made that design 
choice and tries to offer developers all the benefits that go 
with it. And where it's not suitable, then you simply don't use 
Python.

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

It needn't be improbable. Kotlin was born as a third party 
project, like D but smaller. Google saw its benefit for Android 
development and embraced it wholeheartedly. It could have been D 
instead (and IMO it would make a nicer Android language than 
Kotlin). Making D target the JVM shouldn't have been a big 
problem. What was and still missing is consistency, well defined 
features that make sense for a stated goal, excellent tools and 
documentation and community dedication (to the application field, 
not to the language as such).

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

You are onto something there. Maybe an interesting and promising 
direction for D would be to get inspiration from Erlang as an 
actor-based application language, but with full C 
interoperability and a generally more conventional (and thus more 
approachable) language design. But once again, it needs to make 
the choices that are consistent with that, in full knowledge that 
it means saying NO to those features that aren't, and keep on 
track. It also requires a deliberate and long term community 
building effort. Go does it and Rust does it, but D still seems 
to believe that "if you just make a compiler, they will come".