On Fri, 2018-02-09 at 14:04 +0000, rumbu via Digitalmars-d wrote:
> 
[…]
> 1. Keeps data in the %APPDATA%/Roaming folder. Connecting my computer to the company network means that AD will sync zillions of files on the company profile server. This issue is 4 years old: https://github.com/dlang/dub/issues/229

Have you put forward a pull request to fix it, and tests obviously.

4 year old issues just mean no-one cares about it enough to do something.

4 year old pull requests is time to fork the project with a new team of developers.

> 2. It's painfully slow.
> 3. As a library provider, you have a lot to learn about
> configuration file format (2 formats).

Neither of which are really acceptable. :-(

> 4. Not integrated in Visual Studio. I know, I am a lazy and convenient Windows user and the small black window called cmd scares the sh*t out of me.

Isn't that a "create a VS plugin" problem?

-- 
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 Fri, 2018-02-09 at 13:51 +0000, Atila Neves via Digitalmars-d wrote:
> On Friday, 9 February 2018 at 13:34:01 UTC, tetyys wrote:
> > On Friday, 9 February 2018 at 13:10:16 UTC, rumbu wrote:
> > > 
> > > And not a language feature but I hate dub. Just saying.
> > 
> > Why do people hate dub? I think it's a great package manager and build tool
> 
> Great package manager? Yes.
> 
> Great build tool? No. For anything that's not trivial it's an exercise in frustration, pain, tears, waiting for builds to finish, and workarounds for bugs.

Of course whilst people just moan nothing changes. It strikes me as time to actively evolve Dub or replace it.

> Atila
-- 
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 Friday, 9 February 2018 at 15:46:56 UTC, Mike Parker wrote:
> On Friday, 9 February 2018 at 15:37:12 UTC, Ralph Doncaster wrote:
>
>
>> I think you are proving my point.  You say there is no difference between:
>> const MAX_IN = 20;
>> vs
>> immutable MAX_IN = 20;
>>
>> So now I have to try both, and look at the generated code to be sure.
>
> Or read the docs:
>
> https://dlang.org/spec/const3.html
>
>> p.s. I prefer const since it is easier for C/C++ coders to understand.  Using immutable invites the coder to go down the whole rat hole of trying to understand how is it different than const.
>
> It's not a rathole. The document page above explains the differences rather well. They only happen to be identical when initialized with compile-time constants.

Well this part of the docs is a rathole to me:
https://dlang.org/spec/const3.html#implicit_qualifier_conversions

It might be clear and simple to you, but it's not to me.  And I'm a rather advanced developer.
While there are lots of things I like about D compared to C++ such as getting rid of #include hell, there's too many "messy" things and the learning curve is too steep for me to consider suggesting it for any consulting projects.  I think it could've been better if there was more focus on keeping the language (and standard library) clean and simple instead of making it more like a swiss army knife.

On Friday, 9 February 2018 at 15:53:47 UTC, Russel Winder wrote:
> Have you put forward a pull request to fix it, and tests obviously.
>
> 4 year old issues just mean no-one cares about it enough to do something.
>
> 4 year old pull requests is time to fork the project with a new team of developers.

Dub is not dead, it just has limited resources.
In fact, we fixed quite an annoying ecosystem bug a few days ago:

https://github.com/dlang/dub/pull/1339

@Russel: AFAICT there wasn't a PR.

On Friday, 9 February 2018 at 15:55:27 UTC, Russel Winder wrote:
>> 
>> Great build tool? No. For anything that's not trivial it's an exercise in frustration, pain, tears, waiting for builds to finish, and workarounds for bugs.
>
> Of course whilst people just moan nothing changes. It strikes me as time to actively evolve Dub or replace it.
>


He's written a build tool:

https://github.com/atilaneves/reggae

On Friday, 9 February 2018 at 16:05:52 UTC, Ralph Doncaster wrote:

> It might be clear and simple to you, but it's not to me.  And I'm a rather advanced developer.
> While there are lots of things I like about D compared to C++ such as getting rid of #include hell, there's too many "messy" things and the learning curve is too steep for me to consider suggesting it for any consulting projects.  I think it could've been better if there was more focus on keeping the language (and standard library) clean and simple instead of making it more like a swiss army knife.

When I read things like that page, I think "Haskell's not that bad".

So far a strategy that has worked for me is to ignore most of that stuff. Must be my C background.

> On Friday, 9 February 2018 at 15:06:49 UTC, rumbu wrote:

All understood, but just to get your mind set better, I would have two quick follow-up questions if you don't mind.

On Friday, 9 February 2018 at 15:06:49 UTC, rumbu wrote:
>rough C# translation:
> 
> async void spawnedFunc()
> {
>     int i = await receive();
> }

OK, but that's because Phobos has no eventloop.
With Vibe.d it looks like this:


```d
auto val = async({
     return 32;
}).getResult;
```

Is this really so different or what exactly do you miss from the language?

> C#:
>
> IEnumerable<int> Fibonacci(int limit)
> {
>    int a = 1, b = 1;
>    while (a < limit)
>    {
>      yield return a;  //syntactic sugar
>      var t = a;
>      a = b;
>      b = t + b;
>    }
> }

So your point is that std.concurrency.Generator isn't so nice? Not advertised?
Or do you simply want to have a keyword that wraps a function into generator like function* in ES6?

---
auto fib = (int limit){
    import std.concurrency;
    return new Generator!int((){
        int a = 1, b = 1;
        while (a < limit)
        {
            a.yield; //syntactic sugar
            auto t = a;
            a = b;
            b = t + b;
        }
    });
};
---

https://run.dlang.io/is/xQl0Ir

On Friday, 9 February 2018 at 16:05:52 UTC, Ralph Doncaster wrote:
> On Friday, 9 February 2018 at 15:46:56 UTC, Mike Parker wrote:
>> On Friday, 9 February 2018 at 15:37:12 UTC, Ralph Doncaster wrote:
>>
>>
>>> I think you are proving my point.  You say there is no difference between:
>>> const MAX_IN = 20;
>>> vs
>>> immutable MAX_IN = 20;
>>>
>>> So now I have to try both, and look at the generated code to be sure.
>>
>> Or read the docs:
>>
>> https://dlang.org/spec/const3.html
>>
>>> p.s. I prefer const since it is easier for C/C++ coders to understand.  Using immutable invites the coder to go down the whole rat hole of trying to understand how is it different than const.
>>
>> It's not a rathole. The document page above explains the differences rather well. They only happen to be identical when initialized with compile-time constants.
>
> Well this part of the docs is a rathole to me:
> https://dlang.org/spec/const3.html#implicit_qualifier_conversions
>
> It might be clear and simple to you, but it's not to me.  And I'm a rather advanced developer.
> While there are lots of things I like about D compared to C++ such as getting rid of #include hell, there's too many "messy" things and the learning curve is too steep for me to consider suggesting it for any consulting projects.  I think it could've been better if there was more focus on keeping the language (and standard library) clean and simple instead of making it more like a swiss army knife.

The graphic is way too complicated.
Forget inout, it's seldomly used and there have even attempts to remove it from the language.

Without inout:

- any type can be implicitly converted to const X
- shared can't be implicitly removed
- immutable can't be implicitly removed

There's also: https://dlang.org/articles/const-faq.html

On Friday, 9 February 2018 at 16:33:21 UTC, bachmeier wrote:
> On Friday, 9 February 2018 at 16:05:52 UTC, Ralph Doncaster wrote:
>
>> It might be clear and simple to you, but it's not to me.  And I'm a rather advanced developer.
>> While there are lots of things I like about D compared to C++ such as getting rid of #include hell, there's too many "messy" things and the learning curve is too steep for me to consider suggesting it for any consulting projects.  I think it could've been better if there was more focus on keeping the language (and standard library) clean and simple instead of making it more like a swiss army knife.
>
> When I read things like that page, I think "Haskell's not that bad".
>
> So far a strategy that has worked for me is to ignore most of that stuff. Must be my C background.

What I enjoy most is assembler programming in RISC-like instruction sets.  Due to the cost of silicon, it's much less common for them have multiple different instructions for doing exactly the same thing.

On Friday, 9 February 2018 at 16:44:32 UTC, Seb wrote:
> Forget inout, it's seldomly used and there have even attempts to remove it from the language.

inout rox. I think this is more of a documentation discoverability problem. We should be having people read the spec, which is written toward compiler authors [!], when they want to just know how to use it.

Here's the basic rules of thumb:

If you don't need to change a variable:

1) use immutable when declaring a new variable

immutable myvar = "never gonna change";

2) if you are returning a member variable or function argument, use inout on both

class myclass {
   Object member;
   inout(Object) getMember() inout {
       return member;
   }
}

inout(char)* identity(inout(char)* s) {
   return s;
}


inout is like const, just paired return value to arg, so notice that inout will appear twice in the typical signature when you use it.

3) use const when declaring function parameters. Exception: if you need to store the passed reference or pass it to another thread, then immutable may be the better choice.

void inspect(const char[] data) {}



Implicit conversion flowcharts are useful for a deeper understanding but are unnecessary for most effective use...