What are the worst parts of D?

[Manu via Digitalmars-d]

On 24 September 2014 17:43, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 9/23/2014 11:28 PM, Manu via Digitalmars-d wrote:
>>
>> 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.
>
>
> What change in particular?

The instances this has been used as a defence are innumerable.

Perhaps the one that's closest to me was that time when I spent months
arguing final-by-default, won unanimous support of the community, you
approved it, patch written, LGTM, merged, then Andrei appeared with
"When did this happen? I never would have agreed to this! Revert it
immediately!" (which apparently he has the authority to do, but that's
a separate matter).
He later said that "if it were that way from the start, I agree it
should have been that way". It was reverted because breaking change,
despite that it was an established fact that with virtual-by-default,
any effort to optimise a library is also a breaking change and a major
version increment. Most D code is yet to be written. We reject a
single breaking change now, and by doing so, commit to endless
breaking changes in the future.

Of course, there are many more. Things like C-style arrays should be
removed, @property looks like it will never be finished/fixed. I
expect changes to 'ref' will probably receive this same defence.
I'm sure everybody here can add extensively to this list. Phobos is
full of things that should be tidied up.


>> 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.
>
>
> There are 23 issues tagged with 'symdeb':
>
> https://issues.dlang.org/buglist.cgi?keywords=symdeb&list_id=109316&resolution=---
>
> If there are more untagged ones, please tag them.

The fact there's only 23 doesn't really mean anything, they're all
major usability problems.
I feel like I'm back in the early 90's when trying to iterate on my D code.
These issues have proven to be the most likely to send my professional
friends/colleagues running upon initial contact with D.

Here's some more:

https://issues.dlang.org/show_bug.cgi?id=12899
https://issues.dlang.org/show_bug.cgi?id=13198
https://issues.dlang.org/show_bug.cgi?id=13213
https://issues.dlang.org/show_bug.cgi?id=13227
https://issues.dlang.org/show_bug.cgi?id=13243
https://issues.dlang.org/show_bug.cgi?id=11541
https://issues.dlang.org/show_bug.cgi?id=11549
https://issues.dlang.org/show_bug.cgi?id=11902 **** MASSIVE NUISANCE
https://issues.dlang.org/show_bug.cgi?id=12163 **** MASSIVE NUISANCE
https://issues.dlang.org/show_bug.cgi?id=12244 **** MASSIVE NUISANCE

The last 3 make debugging of anything but the simplest D code
practically impossible/pointless.


Aside from that though, this somewhat leads back to my second point,
which is that symdeb issues in the compiler aren't enough. It needs to
be taken wholistically.
Cooperation between the compiler and tooling devs need to be actively
engaged to fix many of these issues.


>> 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 have to ask why all your code revolves about this one thing?

I suspect it's because I rely on far more C++ interop than the average
D user. I have half a decade of solid experience with D<->C++ interop,
perhaps more than anyone else here?
It's not 'all my code', but a sufficient quantity that it pops up and
bites me almost every day, particularly when I try and write any meta.