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

[Jonathan M Davis]

On Thursday, November 15, 2018 7:02:26 PM MST H. S. Teoh via Digitalmars-d 
wrote:
> On Thu, Nov 15, 2018 at 06:03:37PM -0700, Jonathan M Davis via
> Digitalmars-d wrote: [...]
>
> > *sigh* Honestly, auto-decoding is almost a perfect storm of issues for
> > us being able to actually get rid of it. So, while I agree with you
> > that we'd ideally fix the problem, it's _not_ an easy one to fix, and
> > really the only "easy" way to fix it is to pretty much literally say
> > "D3" and hard break all code. I think that the reality of the matter
> > is that there are issues in every language that you can't fix without
> > either creating a new language or creating a new version of the
> > language that's not backwards compatible with the old one (which then
> > forks the language and community).  So, while we'd very much like to
> > fix everything, there are going to be some things we simply can't fix
> > if we're not willing to create D3, and talking about D3 creates a
> > whole other can of worms, which I don't think we're even vaguely ready
> > for yet.
>
> Talking about D3 has sorta become taboo around here, for understandable
> reasons -- splitting the community now might very well be the death of D
> after that Tango vs. Phobos fiasco.  Python survived such a transition,
> and Perl too AIUI.  But D currently does not have nearly the size of
> Python or Perl to be able to bear the brunt of such a drastic change.
>
> Nevertheless I can't help wondering if it would be beneficial to one day
> sit down and sketch out D3, even if we never actually implement it. It
> may give us some insights on the language design we should strive to
> reach, based on the experience we have accumulated thus far.
> Autodecoding, even though it's a commonly mentioned example, actually is
> only a minor point as far as language design is concerned.  More
> fundamental issues could be how to address the can of worms that
> 'shared' has become, for example, or what the type system might look
> like if we were to shed the vestiges of C integer promotion rules.

Honestly, over time, I've become increasingly convinced that the more
radical ideas would be incredibly undesirable (e.g. making const or
immutable the default). shared has some rough edges that need to be sorted
out, but I don't think that it's fundamentally broken as things stand. I
think that the issue is more that it's misunderstood, and its proper use has
not really been messaged well - with the related problem being that the core
synchronization components in druntime have not been entirely properly
updated to take shared into account like they should have been, mostly
because no one wanted to mess with them, because they had the idea that
shared was largely unfinished and might change drastically later. So, while
shared's implementation needs some tweaks to be sure, I'm not the least bit
convinced that it needs a serious overhaul on the language front so much as
some work on the library front and an overhaul on the PR front.

In any case, I think that _most_ of the things that should go in something
like D3 can be done in D2 so long as Walter and Andrei can be convinced. For
instance, we totally _could_ fix the nonsense about treating bool as an
integer type in D2. There's nothing about that that requires D3.
Unfortunately, of course, Walter and Andrei weren't convinced by the DIP
that would effectively have fixed that by removing the implicit conversions
from integer literals to bool, so that's not happening in D2 unless
something drastic changes, and as such, I see no reason to expect that it
would happen in D3. And I think that most of the potential changes are like
that. Maybe Walter and Andrei can be convinced of a particular change, maybe
not. But each change can tackled individually, and for the most part, I
think that the ones that have real value can be made in D2 (though
obviously, convincing Walter and Andrei of any particular change is rarely
easy). It's just the real earth-shattering ones like reversing the defaults
of things that can't be, and I'm not at all convinced that any of those
would actually be a good idea anyway, much as folks like to talk about them.
In a large program, it can very much be worth going to the extra effort of
making your program work with a lot of extra attributes, but they often just
get in the way, and forcing them on all programs by default would easily
risk making D miserable to work in by default. LOL. Walter's comment at
dconf this year that he wished D had const as the default definitely makes
me that much more leery of D3 ever arriving, since I increasingly avoid
const in D.

Honestly, the only thing I can think of where I'd love the opportunity to be
able to sit down and start from scratch would be ranges - and not just for
auto-decoding. I'd want to rework them so that save wasn't a thing, and I'd
want to figure out how to rework them so that the reference and value
semantics were cleaner. What we have works really well in the common case
but ends up as a bit of a mess in the corner cases, and I don't think that
it's entirely fixable. It's mostly a library issue (though it's also partly
an issue with foreach), but it's pervasive enough that we can't really
change it at this point. It's one of those areas where we introduced a
revolutionary idea, and we didn't get it quite right. So, it's great, but it
has problems, and we're stuck with at least some of them. Personally, that's
probably the only thing that I'd be looking to change that I don't think
could be changed without effectively doing D3. In general, the kind of
changes that I can think of that I'd like to see are things that can
definitely be done in D2 - assuming that Walter and Andrei can be convinced,
which is rarely easy, and the question of D2 vs D3 probably wouldn't change
that much (some, since backwards compatibility would be less of an issue,
but that doesn't mean that they'd then be easy to convince of major changes
in general).

- Jonathan M Davis