Which language futures make D overcompicated?

[Nick Sabalausky (Abscissa)]

On 02/09/2018 06:03 PM, H. S. Teoh wrote:
> On Fri, Feb 09, 2018 at 05:13:51PM -0500, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
>> 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.
> 
> The biggest up-front cost is to generate that initial list of import
> paths and libraries needed to get the thing to build.  It's not *hard*,
> but does require parsing the last few (very long) lines of dub output
> (IIRC you need -v to see it).  But since that list changes from time to
> time, I'm actually tempted to write a script to parse the dub output and
> generate the import/library list automatically.  Then it will become
> painless to build things this way. :-D

Yea, *that's* the stuff that gave me trouble. It was also the motivation 
for my "dub describe --data=..." PR, but afterwords I felt like that 
still wasn't quite as good as I wanted, and dub's internal code just 
didn't seem designed to handle that sort of thing anyway (though maybe 
that's improved now?).

> Yeah, more and more, it's giving me the impression of being a walled
> garden.  You either have to buy into it wholesale, or you're left out in
> the cold. :-(  It wouldn't have been such a bad proposal if said walled
> garden had nice things going for it... but given dub's limitations, it
> feels almost like a prison sentence.

Definitly. A big part of the problem was, at least in the early days, 
the author was very clear that it expressly wasn't intended to cover the 
needs of 100% of packages, just like 99% or whatever. On top of that, 
certain design considerations which were *intended* to avoid 
fragmentation within the dub package ecosystem had the unintended 
consequence of forcing a divide between "dub packages which have the 
luxury of playing by dub's rules" and "non-dub packages which *don't* 
have that luxury". I think that's ultimately what led to the probelms we 
have with dub, and I think solving them properly requires undoing years 
fundamental dub design was that built directly upon those early 
philosophies.