On 7/9/14, 8:59 PM, logicchains wrote:
> On Thursday, 10 July 2014 at 02:12:18 UTC, Atila Neves wrote:
>> Rob Pike has said multiple times that the key/unique thing about Go is
>> "select" and that goroutines are the easy part. I'm not entirely sure
>> I grok what he means but we should if we're going to try and do what
>> they got right.
>
> Select is vital for Go in the sense that without it there'd be no way to
> do non-blocking send/receives on channels in Go. It's much more concise
> than the alternative, which would be something like `if chanA is empty
> then foo(chanA) else if chanB is empty then bar(chanB)`. It also avoids
> starvation by checking the channels in a random order - unlike the
> previous if-else chain, which would never call bar(chanB) if chanA was
> always empty.

That's what I think as well.

> It's been implemented in Rust[1] via a macro, and can be implemented in
> Haskell[2] without compiler support, so I'd be surprised if it wasn't
> already possible to implement in D. It wouldn't however be as useful as
> Go's until D gets message passing between fibres.

Yah.

> Actually, an important question that should be considered: does D want
> actor-style concurrency, like Erlang and Akka, or CSP-style concurrency,
> like Rust, Go and Haskell? Or both? Deciding this would allow efforts to
> be more focused.

We already have actor-style via std.concurrency. We also have fork-join parallelism via std.parallel. What we need is a library for CSP.


Andrei

On Thursday, 10 July 2014 at 05:58:56 UTC, Andrei Alexandrescu wrote:
> We already have actor-style via std.concurrency. We also have fork-join parallelism via std.parallel. What we need is a library for CSP.

The actor-style via std.concurrency is only between 'heavyweight' threads though, no? Even if lightweight threads may be overhyped, part of the appeal of Go and Erlang is that one can spawn tens of thousands of threads and it 'just works'. It allows the server model of 'one green thread/actor per client', which has a certain appeal in its simplicity. Akka similarly uses its own lightweight threads, not heavyweight JVM threads.

Think of it from the perspective of attracting Erlang programmers, or Java/Scala programmers who use Akka. If they tried out std.concurrency and found that it failed horribly when trying to spawn fifty thousand actors, they'd be unlikely to stick with the language.

Message passing between lightweight threads can also be much faster than message passing between heavyweight threads; take a look at the following message-passing benchmark and compare Haskell, Go and Erlang to the languages using OS threads: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=threadring

On 7/9/2014 8:12 PM, Timon Gehr wrote:
>> 3. have a design and a plan that gets there
>>
>> There's no law that says D refs must be exactly like Rust borrowed. We
>> can come up with a design that works best for D. D != Rust. Do you have
>> a design in mind?
>> ...
>
> Roughly, but not with 'ref'. It is also an issue of syntax at this point. I
> think we should get at least the basics fixed there before talking in-depth
> about semantics. (In any case, I still have one DIP pending in an unacceptable
> state that I couldn't find the time to write down properly yet.)

> Fundamentally, we need syntax for (examples provided for illustration, those are
> not proposals):
>
> - Parametric polymorphism
>
> Eg.: void foo[A](int x){ ... }

What does that do?


> - Lifetime parameters. (it's more future-proof if they are not introduced by
> simple identifiers.)
>
> Eg.: void foo[lifetime lt](int x){ ... }

??


> - Attaching a lifetime to a pointer, class reference, ref argument.
>
> Eg.: void foo[lifetime lt](int scope(lt)* x){ ...}
>       void foo[lifetime lt](scope(lt) C c){ ... }
>       void foo[lifetime lt](scope(lt) ref int x){ ... }
>       void foo[lifetime lt1,lifetime lt2](scope(lt1)(C)scope(lt2)[] a){ ... }
>
> (The last example talks about a slice where the array memory has different
> lifetimes than the class instances it contains.)

This seems awfully complicated.


> - Lifetime intersection:
>
> Eg.: scope(lt1&lt2)Tuple!(int*,int*) pair[lifetime lt1,lifetime lt2](int
> scope(lt1)* p1, int scope(lt1)* p2){ ... }
>
> (It can alternatively be done only implicitly at function boundaries.)
>
>
> - Specifying the lifetime of a struct/class upon construction:
>
> Eg.: struct S[lifetime lt1,lifetime lt2]{
>           ...
>           this(int scope(lt1)* x, int scope(lt2)* y)scope(lt1&lt2){ ... }
>       }
>

On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
>>> 8. NotNull!T type
>>>
>>> For those that want a non-nullable reference type. This should be doable
>>> as a library type.
>> No.
>
> Rationale?

Please, we've gone through this again and again and again and again.

On Wednesday, 9 July 2014 at 20:51:04 UTC, Walter Bright wrote:
> On 7/9/2014 1:35 PM, Andrei Alexandrescu wrote:
>> Hmmm... how about using u after that?
>
> Using u after that would either cause an exception to be thrown, or they'd get T.init as a value. I tend to favor the latter, but of course those decisions would have to be made as part of the design of Unique.

So runtime error or php style better anything than nothing for something that can be checked statically...

On Thursday, 10 July 2014 at 06:32:32 UTC, logicchains wrote:
> On Thursday, 10 July 2014 at 05:58:56 UTC, Andrei Alexandrescu wrote:
>> We already have actor-style via std.concurrency. We also have fork-join parallelism via std.parallel. What we need is a library for CSP.
>
> The actor-style via std.concurrency is only between 'heavyweight' threads though, no? Even if lightweight threads may be overhyped, part of the appeal of Go and Erlang is that one can spawn tens of thousands of threads and it 'just works'. It allows the server model of 'one green thread/actor per client', which has a certain appeal in its simplicity. Akka similarly uses its own lightweight threads, not heavyweight JVM threads.

As Sean wrote, please check [1] or if you need it right now, Vibe can offer what you need today...
---
Paolo


[1] https://github.com/D-Programming-Language/phobos/pull/1910

On 7/10/2014 12:03 AM, deadalnix wrote:
> So runtime error or php style better anything than nothing for something that
> can be checked statically...

I don't understand your comment.

On 7/9/2014 11:59 PM, deadalnix wrote:
> On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
>>>> 8. NotNull!T type
>>>>
>>>> For those that want a non-nullable reference type. This should be doable
>>>> as a library type.
>>> No.
>>
>> Rationale?
>
> Please, we've gone through this again and again and again and again.

Please point me to where it was.

Walter Bright:

> Exactly. I'm not seeing how this can work that well.

Do you have an example where this works badly? You can require the @notnull annotations on the arguments at module/package boundaries.

But I think this thread tries to face too many problems in parallel. Even just the borrowing/lifetime topic is plenty large for a single discussion thread. I suggest to create single-topic threads.

Bye,
bearophile

On 7/10/2014 12:23 AM, Walter Bright wrote:
> On 7/9/2014 11:59 PM, deadalnix wrote:
>> On Wednesday, 9 July 2014 at 19:50:18 UTC, Walter Bright wrote:
>>>>> 8. NotNull!T type
>>>>>
>>>>> For those that want a non-nullable reference type. This should be doable
>>>>> as a library type.
>>>> No.
>>>
>>> Rationale?
>>
>> Please, we've gone through this again and again and again and again.
>
> Please point me to where it was.

Or better yet, what is your proposal?