It is the year 2020: why should I use / learn D?

[Chris]

On Friday, 23 November 2018 at 10:25:57 UTC, Joakim wrote:


>
> You would expect that from a language coming out of a tools 
> provider. I thought it was interesting how he mentioned that 
> one of the main reasons he didn't want meta-programming in 
> Kotlin is because it's extremely hard for an IDE like theirs to 
> deal with.

> That's potentially one of the big advantages of D's 
> string-based mixin approach: the IDE can tell the compiler to 
> dump them to files and then just treat them as regular D 
> source, though I don't know that anybody is doing that yet.

>
> It's probably D's biggest differentiator, the one feature that 
> people always say blows their mind when they use D, both from 
> its power and relative ease of use. Of course, it's not for 
> everyone, just like lisp macros, so I asked you what you 
> thought, without saying "Kotlin sucks" or whatever.

No, in fairness, you didn't say Kotlin sucks. To be honest 
meta-programming is really hard for the compiler and the D user. 
And when you look back at the code after all the headache you 
wonder was it really worth it. Also, an IDE / compiler that 
immediately tells you what's wrong is _very_ handy.


>
> This is a common theme in open source: OSS devs are often much 
> more interested in trying their hand at writing some whizbang 
> tech, which they may not get to do at their day job, than 
> fixing bugs and taking out the trash. Another is that they 
> simply write a clone of some expensive proprietary software 
> that only has some strict subset of its features, say Linus 
> writing the linux kernel because he wanted to run UNIX on his 
> home desktop.
>
> Neither are conducive to production, stable environments: it 
> took many companies coming in and polishing up the linux kernel 
> or LLVM before they became core components at many companies 
> today. The same will have to be done for D.
>

Exactly, so what is the D Foundation waiting for? D is 18 years 
old.

>
> Why hasn't ruby/rails, Rust, or Nim gotten backing from big 
> players yet? Most things don't get backing from big players, 
> especially initially. What you hope is to create a superior 
> tool that helps small companies grow into the big players 
> someday.

D could be a superior tool. But D is drinking all its money.

>
> I agree that D has had perhaps too much of an emphasis on 
> breaking new ground rather than the boring nuts-and-bolts of 
> adding new platforms and bug-fixing. Now that multiple 
> multi-million-valued and several small companies are built on 
> D, let's hope they get together and make a push with the 
> community in that direction, as Nicholas indicates.

It's 2018. The IT world has realized that you need to be 
compatible. And it has to be as easy and smooth as possible.

> In the meantime, you are a commercial user of D, one who has 
> always been _extremely_ positive about the language over the 
> years in these forums. What changed your mind recently?
>
> I'm asking for specifics: bugs not fixed or concrete incidents 
> that indicate the wrong mindset. We can all wave our hands in 
> the air over perceived generalities, but nothing can change 
> without specifics.

Thanks for asking. It's little things and big things that 
happened over the years. I think what really made me go "Hm" was 
https://issues.dlang.org/show_bug.cgi?id=16739 and that it took 
so long to fix it. I was starting to write a new text parser and 
came across this stupid bug. Then there was the whole issue of 
string handling and autodecode and the way the leadership / big 
guys in the community dealt with it. I was of the opinion that 
such an essential issue had to be fixed immediately (of course 
with a proper path to fix it). I even offered to be the guinea 
pig and document the transition. But no.

Then there were the dreaded dmd updates. "Shit, what will break 
now?" this question would be my constant companion. Sometimes 
nothing, sometimes quite a few things. How would fixing it affect 
my code? Yes, I updated my code, but...Once my code broke and I 
was told to use the `-allinst` flag (Why? It had worked before!), 
then a few releases later my code broke completely again and on a 
whim I removed the -allinst flag and it compiled again. Just 
don't ask why! It's Ahhhrrrrrrrr! The thing is, in D normal 
features break, not the experimental ones. Ordinary idiomatic D 
code just breaks and then works again and breaks again. WT*?

And, being a vibe.d user, the compiler would spit out loads of 
warnings related to vibe.d or just break it. I would have to wait 
for poor Sönke to fix it, but in the meantime there would be a 
new dmd version and again...poor Sönke. You can put up with this 
for a while until you realize that it need not be this way.

Then there was the whole issue of ARM. Walter said he had no 
experience with it and kinda didn't care either, while everything 
was going in the direction of mobile (talking about priorities 
and signs of the time)! If it wasn't for you we'd have nothing, 
zero, nada. 5 years ago I raised the question. 5 years. D is 18 
years old.

What makes my blood boil is when I see lengthy discussions about 
semi-demented constructors and how they are soooo useful and then 
they forgot the semi-demented deconstructor and it wouldn't work 
anyway, because it would break some sh*it and conflict with the 
PR for the new loco-allocator library...and the guys don't even 
have a new XML parser you can safely use...but who needs XML, it 
suck anyway...ah, no lads, it's just crazy.

And the advent of the D Foundation didn't help either. Quite the 
opposite.

All I know is that I got things working fast in other languages 
(even if they don't have semi-demented constructors), I'm more 
productive than in D,...and I don't need to be afraid of the 
compiler...afraid of the compiler!