Which language futures make D overcompicated?

[Jonathan M Davis]

On Sunday, February 11, 2018 11:26:30 rikki cattermole via Digitalmars-d 
wrote:
> On 11/02/2018 11:18 AM, Russel Winder wrote:
> > Clearly though there is a problem with Dub as a build system for many
> > of it's users – or rather people who try and reject.
>
> Put simply, they expect far too much.
> Dub's scope is limited, lets not forget that.

The problem with that is that if dub is the way to build D projects in
general, then it needs to be able to do pretty much whatever you need to do
for pretty much any project - even if that involves backdoors. You need to
be able to do arbitrary stuff with your builds.

It's not as critical for applications so long as dub provides an easy way to
link in any libraries that it pulls in, but dub needs to be able to build
libraries no matter what crazy stuff you need to do, otherwise, those
libraries can't interact with the dub ecosystem, and dub is how D projects
in general pull in their dependencies.

So, for instance, if your D library has to build C or C++ code and link that
in as part of what it does, that needs to be possible with dub, even if dub
itself doesn't handling building code that isn't D. Also, if you need to
generate code as part of your build and then build those files, that needs
to be possible. And the way that dub is set up at this point, that sort of
stuff is rather difficult to do.

dub wouldn't have to be all that powerful if it were simply a handy build
tool for the average use case, but when it's tied in to package management
for D libraries and is the primary way that D projects pull in libraries, it
needs to be far more than a simple build tool. And right now, it's not far
enough away from being a simple build tool.

- Jonathan M Davis