What are the worst parts of D?

[via Digitalmars-d]

On Saturday, 20 September 2014 at 14:22:32 UTC, Tofu Ninja wrote:
> Not really a problem with the language. Just problems.

It is kind of interlinked in a world that keeps moving forward. I 
found myself agreeing (or at least empathising) with a lot of 
what Jonathan Blow said. Of course, since his presentation was 
laid-back the people on reddit kind of attacked him and who 
knows, maybe he lost inspiration. He did at least respond on 
twitter. And his language project probably depends on his next 
game Witness (which sounds cool) to succeed.

Anyway, I think he got the right take on it, reach out to other 
devs in his own sector and ask them about their practice, then 
tailor a language with little syntactical overhead for that use 
scenario. Of course, it won't fly if he doesn't manage to attract 
people who are more into the semantics of computer languages, but 
I root for him anyway. I like his attitude.

On a related note I also read somewhere that Carmack is looking 
at GC for the gameplay data. Basically only a heap scanning, but 
compacting GC, that can run per frame. Seems the game logic 
usually fits in 5MB, so it might work.

> Definitely can agree, I think it has to do with the sentiment 
> that it is "too much like C++"

Yes, I think Jonathan got that part right. I guess also that any 
kind of "unique traits" that feels like "inventions" will be 
eagerly picked up and hold up as good ideas by enthusiasts. Even 
if they are just special cases of more general constructs or 
variations of existing concepts posing under a new name. Perhaps 
an important aspect of the sociology of computer languages. 
(Lispers tend to be terribly proud of their language of choice :)

>> 8. Not enough performance oriented process.
>
> Not sure what you are saying, are you saying there is not a big 
> enough focus on performance?

I think there is too much focus on features both in language and 
library. I'd personally prefer smaller and more benchmark 
focused. It is better to be very good at something limited, IMO.

I also think that the big win in the coming years come for the 
language that most successfully can make elegant low overhead 
access to SIMD instructions without having to resort to 
intrinsics. I have no idea what the syntax would be, but that 
seems to be the most promising area of language design in terms 
of performance IMO.