What are the worst parts of D?

[Andrei Alexandrescu via Digitalmars-d]

On 9/24/14, 12:20 PM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Sep 24, 2014 at 03:16:58AM -0700, Walter Bright via Digitalmars-d wrote:
>> On 9/24/2014 2:56 AM, Vladimir Panteleev wrote:
>>> On Wednesday, 24 September 2014 at 06:57:14 UTC, Walter Bright
>>> wrote:
>>>> On 9/23/2014 11:24 PM, Jacob Carlborg wrote:
>>>>> On 24/09/14 06:31, Walter Bright wrote:
>>>>>
>>>>>> But it is a bit unreasonable to expect large project maintainers
>>>>>> to rebuild and check for bugs every day. It's why we have a beta
>>>>>> test program.
>>>>>
>>>>> The solution is to make it automatic.
>>>>
>>>>
>>>> There's no such thing as automatic testing of someone's moving
>>>> target large project with another moving compiler target.
>>>
>>> It doesn't exist because no one has created it yet :)
>>
>> I've never heard of a non-trivial project that didn't have constant
>> breakage of its build system. All kinds of reasons - add a file,
>> forget to add it to the manifest. Change the file contents, neglect to
>> update dependencies. Add new dependencies on some script, script fails
>> to run on one configuration.  And on and on.
>
> Most (all?) of these issues are solved by using a modern build system.
> (No, make is not a modern build system.)
>
>
>>>> Heck, the dmd release package build scripts break every single
>>>> release cycle.
>>>
>>> Digger succeeds in building all D versions in the last few years.
>>> It doesn't build a complete package like the packaging scripts,
>>> but the process of just building the compiler and standard
>>> library is fairly stable.
>>
>> Building of the compiler/library itself is stable because the
>> autotester won't pass it if they won't build. That isn't the problem -
>> the problem is the package scripts fail. (This is why I want the
>> package building to be part of the autotester.)
>
> That's a good idea. Packaging the compiler toolchain should be automated
> so that we don't have a packaging crisis every other release when
> inevitably some script fails to do what we thought it would, or git got
> itself into one of those wonderful obscure strange states that only an
> expert can untangle.

We of course agree on all these good things but it's all vacuous unless 
somebody champions it.

Andrei