Why is D unpopular?

[Ola Fosheim Grøstad]

On Monday, 8 November 2021 at 01:36:59 UTC, arco wrote:
> On Sunday, 7 November 2021 at 09:18:37 UTC, Ola Fosheim Grøstad 
> wrote:
> But there are two aspects to this where in my opinion D is 
> currently failing and both are more cultural than technical.

I don't think D is failing, as it does what the creator set out 
to make it do. That this appeals to a limited audience is not as 
such a failure. In the context of computer language history, you 
might argue that some aspects of the semantics and syntax has 
serious flaws and that the language designers were unwilling or 
unable to fix them. But failure is not an appropriate word even 
in that context.


> The other problem is that D seems deeply allergic to making 
> hard decisions.

Yes, this is also typical for language design processes. It is 
easier to add new features instead of adjusting what is. You can 
always say «we a busy adding this new feature that will make all 
the difference» and thus the focus on streamlining what exists is 
limited to the most trivial and assert that the price of change 
is too high.


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

If there are 15 ways, then there is no real enforcement? I roll 
my own error-handling using panic. I care more about correctness 
and maintenance than a slowdown of code paths that are rarely 
executed. The Go Way does not lead to more correct programs as 
far as I am concerned.

Most people don't code C++ the way they do at conferences either. 
That is the power of meta programming too. That is the promise of 
high powered meta-programming. You can shape the language to the 
domain.

In fact I think this is a weak spot of D. It should leave more 
room for shaping the language. This is an area where D should be 
doing better, but the language designers have put severe 
constraints on operators that makes it more difficult to create 
useful types. These constraints are there out of fear of creating 
a tower of Babel. As such, D has kneecapped what is touted as its 
strong point. D should also add unicode operators and make it the 
best language for building frameworks for scientific computing 
etc.

But there is no strategic thinking or "scientific philosophy", 
just opinions, that shape the language. As I already have said; 
too much focus on what other programming languages are doing 
(replicating) and not enough focus on unused parts of the design 
space (reinventing/innovation). There should be a balance, but D 
has not quite found the right mix yet that would set it apart 
from other languages.


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

Not really. I am only interested in managed autoscaling. So App 
Engine Standard is my preferred option for now. I have to pick 
between: Python, Java (JVM), Node.js, PHP, Ruby and Go.

No Rust. No D. No C#. No Swift.

If JVM wasn't more heavy than other options I'd say it is the 
most attractive one , in addition to Python. But since 
performance sometimes matter, Go sometimes is the better option. 
And only because GOOGLE SAYS SO! (they optimize the service for 
Go?)

This isn't unique. In mobile space you have Swift, Kotlin, Dart, 
TypeScript, perhaps also C# (but I wouldn't). With a dash of C++. 
And that is it.

On the browser you have TypeScript and WASM. End of story.

D should not look for areas where there is volume. Too crowded. 
It should look for areas where metaprogramming could be 
transformative! The only area where it can be transformative are 
areas where building your own types has huge impact. Scientific 
computing, perhaps signal processing, 3D graphics etc…

But to do so it needs to improve on metaprogramming (and memory 
management). Not because other languages has it, but because 
metaprogramming is so weak in all languages that very few 
frameworks make good use of it. Irrespective of language. It is 
therefore an underutilized language feature (in all languages), 
but the core D language needs changes so it can blossom. It is 
great that the standard lib is going to be streamlined, but it 
won't move the needle as the root cause is in the language.


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

Yes, D primarily appeals to those that consider and reject C++ 
(for various reasons).


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

I don't know. Many C++ apps roll their own, all the way. Outside 
of games C++ applications tend to be very focused and there is 
limited room for reuse (e.g. a compiler can reuse the LLVM 
backend, and that is about it).


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

Yes, it was designed to be an academic language.

When I say Haskell in this context I mean people who use it in 
production, like for web solutions. You have to be dedicated to 
use it. People who do use it, say they are less miserable as 
programmers. I believe them, but they need to put in extra work 
initially, for sure. And that is not all that different from what 
professional D users do and say.


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

Ok, so this is the issue I have with Rust. All the points where 
Rust claims to have a better solution than C++ are areas where I 
never experience problems with C++! As far as I am concerned Rust 
is solving the wrong problems. Maybe Rust is better for bigger 
teams or bigger projects, but I fail to see how it could improve 
my programs.

If D was streamlined, cleaned up, with better memory management 
and improved metaprogramming (without the knee-capping), it could 
provide a better solution than C++ for writing full applications 
(like games, audio editors and the like).

Unfortunately the language designers have no interest in these 
application areas, so D is moving in the right direction, but 
very slowly. Too slow.


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

I don't do fine-grained multithreading, so RAII and exceptions 
covers me well in C++. Rust provides a solution for a problem I 
am unlikely to have…


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

D isn't stable. Go, Java and C++ are stable. That is a 
prerequisite for writing anything larger that is meant to last.

But there is no point in going stable until you have gotten the 
upper hand on semantics and syntax (or have reached critical 
mass).


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

Yes, I use Python whenever I can because it is cheaper (less 
time). But I would have preferred as stronger static type system. 
I rarely use dynamic features.


> 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

This is apples and oranges. I am pretty sure that Google didn't 
pick "Kotlin" in isolation, but that they picked JetBrain's 
Kotlin + JetBrain's IDE. Clearly a strategic partnership that 
benefits all.

D could not have been Google's choice for the JVM. That is 
improbable. Quite a few years back Mosync did quite well in 
providing a cross platform C++ solution (also for JVM), but it 
failed in the market. Google could have picked them up, if this 
is what they wanted.

There is no point in dreaming about what is improbable. D could 
not have been on Google's table for Android. To get there D would 
have had to be a completely different language.