D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)

[Guillaume Piolat]

On Thursday, 23 August 2018 at 04:46:25 UTC, Eugene Wissner wrote:
> But this kind of development doesn't work anymore that well for 
> commercial customers that aren't (only) interested in research. 
> From this perspective D becomes over-complicated, half-finished 
> language. And nobody can tell what will be "in" tomorrow.

My point of view (as a tiny commercial user) is that D has 
everything you need:

- a way to convert money into bugfixes with the new Foundation 
deals

- it's pretty boring and predictable with upgrades, few surprise. 
Each releases bring improvements, you get CI and docs for free 
etc.

- future-proof. It's not a weaponized language, people love it 
etc. It cannot be wiped out by a giant because it doesn't fit a 
corporate agenda.


Of the real problems I think I see - and everyone sees those 
differently:

A - D needs to keep generating drama (like this thread) to 
storify its development and keep people active. It creates 
engagement. A lot of the D marketing is very reasonable and that 
doesn't cut it that much. Where is superdan?

B - sometimes bizzarre allocation of effort, that's probably part 
of some unexplainable evil plan, but can at times feel like 
counterproductive wrt marketing.

   For example: why implement AVX in DMD backend? Who are the 
users that will be delighted by that? Those interested in 
performance already use some other back-end, it's imo a 
completely useless development since _no one_ use D_SIMD 
seriously apart from compiler tests 
(https://github.com/search?l=D&p=4&q=D_SIMD&type=Code)

C - _absurd_ focus on the language, and in lesser part Phobos 
instead of _community_ and DUB things (ie: libraries, making sure 
they exist and make some sense while not putting more work on 
core developers). What if the language was "good enough" while 
the ecosystem wasn't?

Example:
   A best example of this is std.experimental:
      * "to develop something for std.experimental, put it on DUB 
it will be able to be used and upgraded!"
      * "to update something in std.experimental, put it back on 
DUB it will be able to be upgraded while keeping 
backward-compatibility!"

Example:

The solution is (still subjectively) obviously to offload as much 
as possible to the community, simply because there are more 
people making libraries than core developers so why core 
developers should take ownership of an ever growing amount of 
"big Phobos"?
Phobos shouldn't even be a thing, we always read "hopefully this 
will be moved into Phobos" which is entirely wrong. People should 
be pushed to use the community to their advantage. SemVer is 
where it's at.