Has D failed? ( unpopular opinion but I think yes )

[Julian]

On Thursday, 18 April 2019 at 23:43:26 UTC, Margo wrote:
> And this is where things turn into Crystal its advantage.
> Despite all the missing features, its so easy to get tasks
> setup and going. The roadblocks feel less of a issue. D just
> feels *old* with the 1001 command line options.

Crystal merits: it feels easy.

D demerits: it has typical compiler options instead of 
subcommands.

I felt that D was a lot easier than Crystal, but that's feelings
for you. I didn't much like sudden requirements like

   senders = {} of String => Int32

in code that's otherwise free of explicit types. I didn't like
Crystal's compile times. I had a lot more experiences that could 
be
narrated "I bet this will work... oh it does!" in D than in
Crystal.

With D, a lot of my stuff just has #! /usr/bin/env rdmd at the top
and I run it like a script, which is pretty good as far as
1001 command line options go.

> At my old job i spend a week trying to implement some code in D
> and being unhappy about all the other stuff i needed to write
> just to get it function. I spend a day in PHP and was finished.
> Sure, it was slower, used more memory but my time was way more
> valuable.

Just PHP, or a PHP framework?

I bet if you just printed HTML from a little CGI script in D it'd
be nearly as easy. I'm saying this seriously. I've written a lot 
of
internal webapps like this, especially where the backend has
very little to do. Nothing I couldn't do in D.

> Crystal when upgrading tends to be so easy to fix changes,
> where as a lot of the D eco system depends so much on specific
> versions of D. With constant changes for new features and
> removals of old ones, D keeps hurting so many packages.

That's too bad. My experience from learning the language from the 
D
Programming Language (released 2010) was just that some of the
imports had to be updated. Maybe that book just didn't cover the
features that changed so much in the meantime.

> PHP, what gets so much unholy criticism
> from people ( a lot undeserved because years out of date
> information ),

Sorry, but this will never, ever, ever be true.

> Somebody mentioned codingame just a few days ago... The first
> responds to this user: "You're probably in the best position,
> as a user of the site, to advocate D's inclusion.". Yes, a
> random newbie who asked why D was not on this website, where
> you learn to program needs to "do the work" to get D on it.

Wow. That guy should be banned. The obviously preferable response
to any question like this is "thanks! I've added this site to a
list or made an issue or ticket out of it and someone will be
emailing the owner to ask how we can help get D supported."

Even if D is never added, this is action in the direction of
spreading D and it's welcoming rather than dismissive. And even if
D is never added, the questioner might choose to learn more about
the language in the meantime, rather than giving up on such a
hostile community.

> The reality is, D brings few new things to the market that a
> competitor can not copy ( C++ already did, so why switch ).

C++ is the only language I've ever stopped learning before even
completing a tutorial, so I can't speak much on it, but every few
years I'll watch a serious presentation about the language that
has this kind of pattern:

   PRESENTER: Here's some code. Raise your hand if you'd write this
              code.

   AUDIENCE: *some hands are raised*

   P: haha, come on. Don't be shy. How many of you, really?

   A: *most hands raised*

   P: OK. Me too: *raises hand*. We're all wrong. This code is
      terrible. Nobody should ever write code like this.

   ...
   P: here's a way that's not so bad, but--
   ...
   P: here's another way, but it--
   ...
   P: this way is ideal, this is how the STL does it, but it is
      actually illegal under seven international anti-torture
      conventions to ask anyone to ever write code similar to this.
      Seven of my coworkers were found dead at their keyboards 
after
      writing such code. Most of the budget of this C++ convention
      is going towards therapists, this year, so that we can keep
      updating the STL without more than expected loss of life.
   ...
   P: and this is how I recommend you do it. This way still has
      some problems, in particular it's much less efficient than 
the
      ideal way, but it's the best compromise without compromising
      quality of life too much.

Ever few years a presentation like that.  The last one was titled
"The Nightmare of Move Semantics for Trivial Classes"

I don't think there's a feature you can add to C++ that will
prevent you from having to know *all* of the options above, even 
if
you only ever write the last, because you can still come across
other people's code.