D is dead

[Jesse Phillips]

On Thursday, 23 August 2018 at 09:26:46 UTC, rikki cattermole 
wrote:
> On 23/08/2018 9:09 PM, Shachar Shemesh wrote:
>> functions may be @safe, nothrow, @nogc, pure. If it's a method 
>> it might also be const/inout/immutable, static. The number of 
>> libraries that support all combinations is exactly zero (e.g. 
>> - when passing a delegate in).
>
> Indeed that combination is horrible. It does deserve a rethink, 
> but it probably doesn't warrant changing for a little while 
> since its more of a polishing than anything else (IMO anyway).


I think that tends to be where D's biggest failing tends to be is 
the polish.

I started using D before these features existed, I also continue 
to use despite these features existing, like many I try to use 
them but end up falling back to not. But these things tend to be 
a big part of the D marketing.

I would classify the --dip1000 work as a polishing effort, but it 
also opens the doors to more areas that need polish, and most 
likely won't get it before --dip1000 is considered done.

I would also disagree with the community being hostile to 
criticism. Explanation and workarounds are usually given, not 
hostility. There is a huge resistance to change, but that should 
be expected and continue to increase. It is usually just sad how 
long it takes for change to happen when it needs to.

Tangent:

Sem versions may be easy to implement, but they have no value 
without practice. Practice isn't so easy to manage. We may not be 
following the sem version spec but it wouldn't add value to 
current practice. There is a patch release and there is a 
breaking changes and feature release. If we don't get the 
management of breaking changes correct, sem versioning is broken 
anyway.