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

[Chris]

On Sunday, 25 November 2018 at 06:56:10 UTC, Walter Bright wrote:
> On 11/24/2018 7:19 AM, Chris wrote:
>> Of course you cannot do everything alone. I never expected 
>> that. But ARM was never really high on the agenda.
>
> It cannot be high on the agenda without a self-motivated, 
> competent person to work on it.
>
>
>> But it is essential enough that it should have gotten a higher 
>> priority than just to wait until someone stepped up.
>
> I have a lot of history with people asking me "what can I work 
> on?" I give them a list of suggestions, and they work on 
> something not on that list, i.e. what they want to work on.
>
> The D community is a volunteer one. I cannot order anyone to 
> work on anything.
>
> For example, you can step up and work to improve any aspect of 
> D that matters to you.
>
>
>> I see a lot of other things happening like the 
>> re-implementation of the D compiler in D. Fine. But do I as a 
>> user really care if it's written in D or C++?
>
> Not directly, no. But there are a number of problems working on 
> that code due to it being half in D, half in C++, such as:
>
> 1. C/C++ is just a clumsy language to work in when one is used 
> to D.
> 2. Half in one language, half in the other, means you have to 
> main two sets of declarations of the data structures, and 
> there's hell to pay if they get out of sync.
> 3. There's lots of technical debt in the old backend. Redoing 
> it in D makes that a lot easier to improve.
> 4. I don't have to deal with C/C++'s portability problems when 
> it's in D. I've spent a stupid amount of time just dealing with 
> size_t.
>
>
>> I don't understand how things are prioritized in D. Basic and 
>> important things seem to be at the bottom of the list (XML 
>> parser), other things get huge attention while they are of 
>> dubious value to many users. This is why I don't completely 
>> buy the "we don't have enough resources" argument. The scarce 
>> resources you have are not used wisely in my opinion. And it 
>> is a pity when I see that D has loads of potential (C/C++ 
>> interop, Objective-C interop etc.) but other new languages 
>> overtake D because they focus on practical issues too.
>
> It's fairly straightforward. Things that get attention do so 
> because a self-motivated and competent person decides to solve 
> it. Commercial organizations that rely on D tend to spend money 
> solving their problems with D, not others. The D Foundation 
> does have some money to spend, but you may not realize just how 
> much a competent compiler engineer costs!

Sorry, but D tends to D-motivate people. One example is std.xml. 
Another issue I've brought up over the years. You talk about 
highly motivated volunteers and when you get one what does s/he 
get? Review limbo for ever, because everything else is more 
important than that volunteer's work. Dip1000, the C++ > D 
transition, whatever. And when people ask about std.xml or any 
other work in limbo the answer is "The person didn't push hard 
enough!". That's cynical. How is that supposed to motivate 
anyone? Do you and Andrei sometimes think about how this sort of 
behavior is perceived by users? Believe me, it doesn't go 
unnoticed and it makes you think twice about contributing. It's 
normal psychology. And it's a rinse and repeat pattern in the D 
world.

Guess why - and this speaks volumes - Johnathan M. Davis couldn't 
be bothered to put dxml through a review process? Johnathan told 
us that he wasn't "too enthusiastic" about it. Why wasn't the new 
std.xml ever reviewed + accepted back in the day?

Contribute! You may not know, but D users are usually too busy 
finding workarounds for bugs, fixing broken code and coming up 
with their own solutions for basic things. I wrote a small XML 
parser for my own specific needs, because I couldn't wait 
anymore. We've kept your and our dream alive by working around 
difficulties ourselves in the hope that some day things would 
improve. But in vain.