What are the worst parts of D?

[Cliff via Digitalmars-d]

On Wednesday, 24 September 2014 at 22:49:08 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> On Wed, Sep 24, 2014 at 10:18:29PM +0000, Atila Neves via 
> Digitalmars-d wrote:
> [...]
>> If I were to write a build system today that had to spell out 
>> all of
>> its commands, I'd go with tup or Ninja. That CMake has support 
>> for
>> Ninja is the icing on the cake for me. I wrote a Ninja build 
>> system
>> generator the other day, that thing is awesome.
> [...]
>> P.S. I've thought of writing a build system in D, for which the
>> configuration language would be D. I still might. Right now, 
>> dub is
>> serving my needs.
>
> I've been thinking of that too! I have in mind a hybrid between 
> tup and
> SCons, integrating the best ideas of both and discarding the 
> bad parts.
>
> For example, SCons is notoriously bad at scalability: the need 
> to scan
> huge directory structures of large projects when all you want 
> is to
> rebuild a tiny subdirectory, is disappointing. This part should 
> be
> replaced by Tup-style OS file change notifications.
>
> However, Tup requires arcane shell commands to get anything 
> done --
> that's good if you're a Bash guru, but most people are not. For 
> this, I
> find that SCon's architecture of fully-customizable plugins may 
> work
> best: ship the system with prebaked rules for common tasks like
> compiling C/C++/D/Java/etc programs, packaging into tarballs / 
> zips,
> etc., and expose a consistent API for users to make their own 
> rules
> where applicable.
>
> If the scripting language is D, that opens up a whole new realm 
> of
> possibilities like using introspection to auto-derive build
> dependencies, which would be so cool it'd freeze the sun.
>
> Now throw in things like built-in parallelization ala SCons 
> (I'm not
> sure if tup does that too, I suspect it does), 
> 100%-reproducible builds,
> auto-packaging, etc., and we might have a contender for Andrei's
> "winner" build system.
>
>
>> P.S.S autotools is the worse GNU project I know of
>
> +100! It's a system of hacks built upon patches to broken 
> systems built
> upon other hacks, a veritable metropolis of cards that will 
> entirely
> collapse at the slightest missing toothpick in your shell 
> environment /
> directory structure / stray object files or makefiles leftover 
> from
> previous builds, thanks to 'make'. It's pretty marvelous for 
> what it
> does -- autoconfigure complex system-dependent parameters for 
> every
> existing flavor of Unix that you've never heard of -- when it 
> works,
> that is. When it doesn't, you're in for days -- no, weeks -- 
> no, months,
> of hair-pulling frustration trying to figure out where in the 
> metropolis
> of cards the missing toothpick went. The error messages help -- 
> in the
> same way stray hair or disturbed sand helps in a crime 
> investigation --
> if you know how to interpret them. Which ordinary people don't.
>
>
> T

If you have a passion and interest in this space and would like 
to collaborate, I would be thrilled.  We can also split this 
discussion off of this thread since it is not D specific.