On Saturday, February 10, 2018 20:57:44 John Gabriele via Digitalmars-d wrote:
> On Saturday, 10 February 2018 at 20:55:00 UTC, John Gabriele
>
> wrote:
> > {snip} It's not niche at all, it just doesn't have hoards of users. D is well-positioned to be hugely popular, but I think to succeed its leadership needs to be willing to fix things they want to fix and not worry about breaking backcompat.
>
> Augh! "hordes", not "hoards".

Clearly, someone is hoarding our hordes, which is why we don't see enough of them. ;)

- Jonathan M Davis

On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:
> I like D, but sometimes it's look like for me too complicated. Go have a lot of fans even it not simple, but primitive. But some D futures make it very hard to learning.
>
> Small list by me:
> 1. mixins
> 2. inout
> 3. too many attributes like: @safe @system @nogc etc
>
> Which language futures by your opinion make D harder?

Sorry for being pessimistic, but this has already been discussed many times here. This is just a waste of time and it doesn't produce any results.

Having coded in C++ all my life, I can definitely say C++ is way too complex. So D can't win it in that aspect. :-)

The main thing confused me a LOT, as ketmar rightly said, was struct (it was not TLS, it was not static, it was not GC). Other than that, there are a few that I can point in D that I consider are complex.

* auto decoding - given that ranges are the idiomatic way, it's simply unacceptable.
* shared
* immutable vs const
* lack of consistency and orthogonality. Past discussions: https://forum.dlang.org/post/iysrtqzytdnrxsqtfwvk@forum.dlang.org

From the perspective of language complexity, I'm already living with C++, so I can live with D as well. But the difficult thing to live with is

* Dearth of libraries (features, performance and quality)
* Dearth of libraries
* Dearth of libraries

Dub is getting some flak here. This is unsurprising because it is really hard to write a good package manager and build system. I use a lot of languages and not one has a satisfactory package manager. Mostly they try to do too much and get in the way or they do too little and people complain (I prefer the second option). And when there are 100+ dependencies, like with Go and Node, it just becomes impossible to say anything about the state of the system (security, anyone?).

Package management is mostly dependency management. This I handle with GNU Guix (and Nix) package managers. They are great at that. This also leaves people to choose any old build system. Inside GNU Guix the build system is consistent, which is really nice. I'll write a blog some time this year.

What you really want is to be able to discover packages (i.e., a website such as Dub provides), pull them into your tree (which is just a path and can be handled by git submodules, though I don't like those much either), and when you distribute: add them to Guix or Nix and provide those packages with build system and as binary deployments to others. These package managers give control over the full dependency graph, including shared libraries all the way down to glibc.

I am not posting this to plug these systems per se. Just saying that writing a generic package manager is hard and is better left to systems that solve handling the full dependency graph correctly. Personally, I am happy very happy with what Guix gives me. Can't think of a better way. I have no reason to use dub.

On Saturday, 10 February 2018 at 20:50:37 UTC, Jon Degenhardt wrote:
> On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:
>> Which language futures by your opinion make D harder?
>
> * Static arrays aren't not ranges. I continually forget to slice them when I want to use them as ranges. The compiler errors are often complex template instantiation failure messages.

File a bug report! This should be relatively straightforward
to improve the error message.

On Fri, 2018-02-09 at 17:20 -0500, Nick Sabalausky (Abscissa) via
Digitalmars-d wrote:
> 
[…]
> Been there, done that, put enormous work into it, a TON of arguing
> to
> little avail, found the code architecture difficult to work with,
> and
> ultimately my merged PRs barely made a dent at solving my issues.
> Gave
> up. I'm convinced the problems with dub are fundamental and often
> philosophical.

The vocal minority of the moment is very anti-Dub as build tool, hence Atila wrote Reggae, and may put renewed effort into D support for SCons, CMake, and Meson.

To have the debate now is different to having the debate then. Then there was no data, just effort that created Dub, Dub was the only constructive activity at the time.

Now we have a package system, that perhaps needs evolution, Dub as a build system, plus further work on SCons, CMake, Meson, the creation of Reggae, and Cargo which proves that what Dub was trying to do is not impossible.

> After my experience tring to improve dub, I'm 100% convinced what we
> need is a package manager designed from the ground up to NOT be
> anything
> but a package manager.

Given Cargo is that actually true?

It is though a crucial question, along with, should the D community line up behind Reggae as a build framework?

Clearly SCons, CMake, and Meson will continue to be there, but efforts to evolve them could be redirected in a combined effort to create a better standard system.

Whilst Cargo is the Rust default system, many use it just for package management, not as a build system – though I don't I just use Cargo.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 11/02/2018 10:54 AM, Russel Winder wrote:
> On Fri, 2018-02-09 at 17:20 -0500, Nick Sabalausky (Abscissa) via
> Digitalmars-d wrote:
>>
> […]
>> Been there, done that, put enormous work into it, a TON of arguing
>> to
>> little avail, found the code architecture difficult to work with,
>> and
>> ultimately my merged PRs barely made a dent at solving my issues.
>> Gave
>> up. I'm convinced the problems with dub are fundamental and often
>> philosophical.
> 
> The vocal minority of the moment is very anti-Dub as build tool, hence
> Atila wrote Reggae, and may put renewed effort into D support for
> SCons, CMake, and Meson.
> 
> To have the debate now is different to having the debate then. Then
> there was no data, just effort that created Dub, Dub was the only
> constructive activity at the time.

It wasn't.
I was working on my own build system with dependency management when dub was created. I stopped after dub was first released because it meet my every need for a D build manager.

On 2/9/2018 11:13 AM, Manu wrote:
> 1. Storage class as a concept separate to the type;
void test() {
    int x;
    static int y;

    typeof(x) != typeof(y) ???
}

On Sun, 2018-02-11 at 10:59 +0000, rikki cattermole via Digitalmars-d wrote:
> 
[…]

> I was working on my own build system with dependency management when
> dub
> was created. I stopped after dub was first released because it meet
> my
> every need for a D build manager.

Hopefully it still works for you.

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.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 11/02/2018 11:18 AM, Russel Winder wrote:
> On Sun, 2018-02-11 at 10:59 +0000, rikki cattermole via Digitalmars-d
> wrote:
>>
> […]
> 
>> I was working on my own build system with dependency management when
>> dub
>> was created. I stopped after dub was first released because it meet
>> my
>> every need for a D build manager.
> 
> Hopefully it still works for you.

Perfectly.

> 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.

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