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

Joakim dlang at joakim.fea.st
Fri Nov 23 10:25:57 UTC 2018


On Wednesday, 21 November 2018 at 14:38:07 UTC, Chris wrote:
> On Wednesday, 21 November 2018 at 13:26:34 UTC, Joakim wrote:
>
>> What did you think about this bit?
>>
>> "There's one thing that we don't really have and I don't 
>> really want it in the language: it's meta-programming... 
>> instead we had a very good experience doing compiler plugins."
>> https://www.youtube.com/watch?v=PsaFVLr8t4E?t=2126
>>
>> Also, no "first-class immutability."
>
> I watched the whole keynote. Well, to begin with it's still a 
> very young language (not 18+ years old) and keeps getting 
> better and better. Things that were a bit tricky just recently 
> are now much easier and part and parcel of the language. It 
> shows that they listen to their user base and make things as 
> easy as possible. In many ways it's already miles ahead of D in 
> terms of what you need as a programmer to get things done fast, 
> e.g. tooling, interop, multi-platform, handling of deprecations 
> etc. There are useful features (I already knew from D) that 
> make life easier (e.g. lambdas).

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.

> And as for meta-programming (I knew this would come up ;)), I 
> don't really miss it / use it anymore. There was only one case 
> where I said it would have been nice, but it wasn't _really_ 
> necessary (it was just an old D habit, really). In fact, 
> meta-programming in D can cause a lot of unnecessary headaches 
> (cryptic compiler warnings galore, code breakage) and stall the 
> whole development process unnecessarily - and often for very 
> little extra value. It says a lot that Adam D. Ruppe stated 
> that if you don't want your code to break, use non-idiomatic D. 
> So what's the point of it then? It's just absurd.

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.

> D could have been a real contender here (e.g. C interop) but 
> instead of investing in a good infrastructure / tooling, 
> cleaning up and stabilizing the language, the community has 
> turned D into a "feature laboratory" where ideas are discussed 
> to death and really important issues are swept under the rug. 
> Other new languages focus on tooling and interop from the very 
> beginning as they realize that this is very important these 
> days, more so than fancy features (that can be added later).

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.

> Then, of course, the inevitable "X doesn't have feature Y, but 
> D does! That's why X sucks." Only: are all these super features 
> indispensable for production? Why hasn't D got backing from big 
> players yet? Because of the community's elitist and parochial 
> mindset and the overall lack of consistency.

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.

> Joakim, you have done some great work as regards Android / iOS 
> and I believe we are on the same page here. But see that the D 
> Foundation didn't pick up on it and say "Let's take this and 
> create some sound tooling for ARM cross-compilation." If it's 
> not about fancy super-sophisticated allocators, contributors 
> are completely on their own. This is no way to treat people who 
> make an effort.

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.

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.


More information about the Digitalmars-d mailing list