Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa)]

On 02/09/2018 02:01 PM, H. S. Teoh wrote:
> 
> Currently, my vibe.d project has a subdirectory containing an empty
> dummy dub project, the sole purpose of which is to declare vibe.d
> dependencies so that `dub build` in that subdirectory will fetch and
> build vibe.d and whatever else it may depend on, and build it into a
> linkable state.  Once that's done, I leave dub aside and use SCons to
> actually build and link my program with the libraries built by dub.
> This resulted in an instant improvement in my build times by (at least)
> half, as well as free me from needless network lookups when I'm actually
> coding locally and don't *need* to be upgrading dependent libraries.
> 

I'm kind of envious of that approach, and REALLY tempted to adopt it 
myself, but there are some unfortunate probelms with it (which are 
incidentally the exact same reasons I eventually conformed and 
begrudgingly strated using dub as my main build tool, as much as I 
dislike doing so):

1. From a compiler command-line perspective, trying to incorporate 
vibe.d in a project that isn't built with dub proved in my experience to 
be a royal pain. And then upgrading to newer versions of vibe.d had a 
tendency to break it in non-obvious ways.

2. If you want your project (especially if it's a lib) to participate in 
the the dub package repository ecosystem, you pretty much have to 
support dub as a build tool. Otherwise, anyone who DOES use dub as a 
build tool will have major trouble trying to use your lib.

So even as a package manager, dub is viral. And the unfortunate 
consequence of that is that it completely divides D package ecosystem in 
two.