On Thursday, 23 August 2018 at 10:41:03 UTC, Jonathan M Davis
wrote:
D does have a problem in general of having a lot of great
features that work really well in isolation but don't
necessarily work well in concert (and it doesn't help that some
features have really never been properly finished). And
frequently, the answer that folks go with is to simply not use
sections of the language (e.g. it's _very_ common for folks to
just give up on a lot of attributes like pure, nothrow, or
@safe). A number of the issues do get worked out over time, but
not all of them do, and sometimes the solutions cause a lot of
problems. For instance, DIP 1000 may end up being great for
@safe and will help solve certain issues, but it results in yet
another attribute that has to be pasted all over your code and
which most folks simply won't use. So, it's helping to fix a
real problem, but is it making things better overall? I don't
know.
And while I definitely think that D is easier to understand
than C++ (in spite of the increase in D's complexity over
time), it's also very much true that D continues to get more
and more complicated as we add more stuff. Generally, each
solution is solving a real problem, and at least some of time,
the solution actually interacts quite well with the rest of the
language, but it all adds up. And honestly, I don't think that
there's a real solution to that. Languages pretty much always
get more complicated over time, and unless we're willing to get
rid of more stuff, it's guaranteed to just become more
complicated over time rather than less.
D definitely improves over time, but certain classes of issues
just never seem to be fixed for some reason (e.g. the issue
with RAII and destructors really should have been fixed ages
ago), and some of the major design decisions don't get fully
sorted out for years, because they're not a high enough
priority (e.g. shared). I don't really agree that D is in much
danger of dying at this point, but I completely agree that we
as a group are not doing a good enough job getting some of the
key things done (much of which comes down to an issue of
manpower, though some of it is also likely due to
organizational issues).
- Jonathan M Davis
This is a great summary of the situation, thanks for such a good
and honest appraisal. From a technical POV I'd say it could
replace the whole thread.
But there is a social/psychological aspect to the whole thing.
Sachar's comment is obviously the cry of pain of someone whose
back has just been broken by a last straw. He is being told, 'the
straw you are complaining about is nothing'.
There is a class of developers who expect things to Just Work TM,
especially if they are told that it Just Works. Each time that
they discover some combination of features that doesn't work they
have to refactor their code and remember not to try that again.
Ultimately the developer painfully learns the things that they
should not attempt to use, or they give up before the process is
complete and leave. I expect the pain caused by this is much more
acute in a commercial environment where the pressure is on.
Long term D developers have learnt not to bother with certain
features or combinations of features and forget all the pain they
went through to get that knowledge. They are ones saying, come in
the water's lovely.
For anyone considering using D for a commercial project the
situation you describe is cause for concern. The issues can be
fixed but it will take some brave and ruthless decisions, I
suspect.