What are the worst parts of D?

[Manu via Digitalmars-d]

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.