Which language futures make D overcompicated?

[aberba]

On Sunday, 11 February 2018 at 11:47:25 UTC, rikki cattermole 
wrote:
> On 11/02/2018 11:40 AM, Jonathan M Davis wrote:
>> 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
>
> Dub can do everything that you have described.
> You are fully free to run cmake if you wish before the build.
I wish complaints about Dub would include exactly what was 
impossible with it. There's no reason to throw dub away and start 
something new. If one can run cmake before build in dub,  then a 
lot is possible. Those edge cases can be ironed out.

Dub fulfills all my use cases so I don't complain. Those here 
with not much issue with dub will also not complain. And that 
does not make it a minority opinion without stats to prove dub 
usage.

At point, dub will likely remain the default package management 
tool. The build functionality can be improved for those who deal 
with such stuff often. Manpower is what remains.


> Will it result in binaries that are decent? Probably not for 
> most use cases.
Can you file a bug report on this?

>
> Its a hard problem to solve, I just wish people respected dub's 
> scope more. Because it is very decently well scoped for its job 
> already.
Same opinion here.