Things that keep D from evolving?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Tuesday, 9 February 2016 at 17:41:34 UTC, NX wrote:
> On Tuesday, 9 February 2016 at 14:35:48 UTC, Ola Fosheim 
> Grøstad wrote:
>> Not incredibly high level abstraction... But I get what you 
>> mean. It is fairly high level for a low level language.
>
> Coming from C#, it looks amazing but probably not that 
> incredible when coming from C++.

If D had parity with C++ features and didn't have it's own set of 
inconsistencies it could do a lot better. But the lack of 
willingness to change probably means that a new language will 
come along instead of D improving.

Right now D sits somewhere between C++/Rust and Swift/Go, which 
might not be the best position. It is natural that people will 
gravitate towards either end. If you don't want to deal with 
memory management use Swift/Go, if you want to optimize memory 
management go C++/Rust.


>> So you want this to be worked on (as D has a horribly slow 
>> one)?
>
> I would want it to be solved rather than being worked on... 
> which requires design change which is probably not going to 
> happen. There is still room for improvement though.

I think it would help a lot if there was a broad effort to 
refactor and document the compiler. If the compiler is difficult 
to change it becomes more difficult to experiment and there will 
be much more resistance to changing semantics...