What are the worst parts of D?

[user via Digitalmars-d]

On Wednesday, 24 September 2014 at 06:28:21 UTC, Manu via
Digitalmars-d wrote:
> On 20 September 2014 22:39, Tofu Ninja via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> There was a recent video[1] by Jonathan Blow about what he 
>> would want in a
>> programming language designed specifically for game 
>> development. Go, Rust,
>> and D were mentioned and his reason for not wanting to use D 
>> is is that it
>> is "too much like C++" although he does not really go into it 
>> much and it
>> was a very small part of the video it still brings up some 
>> questions.
>>
>> What I am curious is what are the worst parts of D? What sort 
>> of things
>> would be done differently if we could start over or if we were 
>> designing a
>> D3? I am not asking to try and bash D but because it is 
>> helpful to know
>> what's bad as well as good.
>>
>> I will start off...
>> GC by default is a big sore point that everyone brings up
>> "is" expressions are pretty wonky
>> Libraries could definitely be split up better
>>
>> What do you think are the worst parts of D?
>>
>> [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ
>
> Personally, after years of use, my focus on things that really 
> annoy
> me has shifted away from problems with the language, and firmly
> towards basic practicality and productivity concerns.
> I'm for addressing things that bother the hell out of me every 
> single
> day. I should by all reason be more productive in D, but after 
> 6 years
> of experience, I find I definitely remain less productive, 
> thanks
> mostly to tooling and infrastructure.
>
> 1. Constant rejection of improvements because "OMG breaking 
> change!".
> Meanwhile, D has been breaking my code on practically every 
> release
> for years. I don't get this, reject changes that are 
> deliberately
> breaking changes which would make significant improvements, but 
> allow
> breaking changes anyway because they are bug fixes? If the 
> release
> breaks code, then accept that fact and make some real proper 
> breaking
> changes that make D substantially better! It is my opinion that 
> D
> adopters don't adopt D because it's perfect just how it is and 
> they
> don't want it to improve with time, they adopt D *because they 
> want it
> to improve with time*! That implies an acceptance (even a 
> welcoming)
> of breaking changes.
>
> 2. Tooling is still insufficient. I use Visual Studio, and while
> VisualD is good, it's not great. Like almost all tooling 
> projects,
> there is only one contributor, and I think this trend presents 
> huge
> friction to adoption. Tooling is always factored outside of the 
> D
> community and their perceived realm of responsibility. I'd like 
> to see
> tooling taken into the core community and issues/bugs treated 
> just as
> seriously as issues in the compiler/language itself.
>
> 3. Debugging is barely ever considered important. I'd love to 
> see a
> concerted focus on making the debug experience excellent. Iain 
> had a
> go at GDB, I understand there is great improvement there. 
> Sadly, we
> recently lost the developer of Mago (a Windows debugger). 
> There's lots
> of work we could do here, and I think it's of gigantic impact.
>
> 4. 'ref' drives me absolutely insane. It seems so trivial, but 
> 6 years
> later, I still can't pass an rvalue->ref (been discussed 
> endlessly),
> create a ref local, and the separation from the type system 
> makes it a
> nightmare in generic code. This was a nuisance for me on day-1, 
> and
> has been grinding me down endlessly for years. It has now far 
> eclipsed
> my grudges with the GC/RC, or literally anything else about the
> language on account of frequency of occurrence; almost daily.


i couldn't agree more. i would like to add, that coming from D1's
clean and nice syntax - D2 becomes a syntactic monster, that is
highly irritating and hard to get used to. its littered with @
like a scripting language. that really sucks!