On Tuesday, 4 December 2018 at 07:41:18 UTC, Russel Winder wrote:
> Now that Go seems to have a role of replacing Java in The Cloud, generics is a far more serious issue than it was three years ago – there is nothing quite as stimulating of action as big company spokespeople rather than private individuals making disparaging remarks. So the Go team have more or less been forced to find an acceptable generics system, which they haven't tried seriously before.

Yes, my guess is that there have been internal complaints within Google, after all they hire people who know other languages...

The most interesting part was indeed that the opinions of the original team is not going to be given as much weight in Go 2!

So basically, Google leadership seem to force the Go team to address recurring complaints about error-handling and generics. At least, that seems likely.

At this point I'd say that is a very important point to make. Changing the language is important, but for me it is even more important that they are changing the process!

Other languages should follow suit. C++ did the same thing, and I think it was for the better. Although both C++ and Go seem to be stuck with old sins...

On Tuesday, 4 December 2018 at 07:41:18 UTC, Russel Winder wrote:
> Now that Go seems to have a role of replacing Java in The Cloud, ...

Java is now also getting CSP-style concurrency as in Go, see this presentation by Mark Reinhold:

https://www.youtube.com/watch?time_continue=4125&v=nKJbDYRsO0s

Project Loom starting at 1:08:47

On Tue, 2018-12-04 at 13:48 +0000, Bienlein via Digitalmars-d wrote:
> On Tuesday, 4 December 2018 at 07:41:18 UTC, Russel Winder wrote:
> > Now that Go seems to have a role of replacing Java in The Cloud, ...
> 
> Java is now also getting CSP-style concurrency as in Go, see this presentation by Mark Reinhold:
> 
> https://www.youtube.com/watch?time_continue=4125&v=nKJbDYRsO0s
> 
> Project Loom starting at 1:08:47

I haven't watched the video (sorry), but my understanding of the
situation is that:

Kotlin Coroutines already give you the necessary foundations for doing event loop, reactive, and the channels/lightweight processes/threadpool/executors things. So you can do all the goroutine type stuff on the JVM already.

Project Loom is really about bringing an evolution of Quasar into the JVM so as to avoid all the hacking around that Quasar currently has to do to work properly. I think this is a good thing, and about time it happened.

GPars had all this stuff in 2008. :-)

GPars is now effectively a dead project.

Channels/lightweight processes/executors/threadpools is now the norm in Rust as well. I hear even C++ will get this stuff soon.

-- 
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 Wednesday, 5 December 2018 at 06:47:44 UTC, Russel Winder wrote:
> Project Loom is really about bringing an evolution of Quasar into the JVM so as to avoid all the hacking around that Quasar currently has to do to work properly. I think this is a good thing, and about time it happened.
>
> GPars had all this stuff in 2008. :-)
>
> GPars is now effectively a dead project.

I'm not sure this is correct. From what I can see GPars had no green threads or something to mimic them like Kotlin Coroutines using fibers. Also, I can't see that GPars had continuations.

> Channels/lightweight processes/executors/threadpools is now the norm in Rust as well.

They had a module to have something like green threads before Rust turned 1.0 and then canceled it before Rust 1.0 was released. To my knowledge this module is still discontinued.

It would be cool if D would get continuations. Then together with the existign solution for fibers you could greate something that matches Go's CSP-style concurrency or Kotlin's Coroutines.

On Sun, 2018-12-09 at 18:57 +0000, Bienlein via Digitalmars-d wrote:
> On Wednesday, 5 December 2018 at 06:47:44 UTC, Russel Winder wrote:
> > Project Loom is really about bringing an evolution of Quasar into the JVM so as to avoid all the hacking around that Quasar currently has to do to work properly. I think this is a good thing, and about time it happened.
> > 
> > GPars had all this stuff in 2008. :-)
> > 
> > GPars is now effectively a dead project.
> 
> I'm not sure this is correct. From what I can see GPars had no green threads or something to mimic them like Kotlin Coroutines using fibers. Also, I can't see that GPars had continuations.

GPars is founded on Java concurrency so threadpools and fork/join. There was no need for a green threads implementation independent of what was provided by Java. The tasks of GPars are placed into a threadpool and are executed by executors. As for continuations, I am less sure, the meaning of this term has evolved over the years. What GPars does have is combinable futures.

> > Channels/lightweight processes/executors/threadpools is now the norm in Rust as well.
> 
> They had a module to have something like green threads before Rust turned 1.0 and then canceled it before Rust 1.0 was released. To my knowledge this module is still discontinued.

Almost everything to do with concurrency and parallelism was ripped out of Rust, other than threads on the principle of keep the standard library small and essential and put everything else into packages held on crates.io or in GitHub repositories and brought in by Cargo.

There are many packages for concurrency and parallelism, but the main one is futures. Actually the one you want is futures-preview for lots of silly reasons. futures-preview is really quite good.

> It would be cool if D would get continuations. Then together with the existign solution for fibers you could greate something that matches Go's CSP-style concurrency or Kotlin's Coroutines.

Or Rust futures-preview, or GPars, or Quasar.

The future is combinable futures. And channels.

It was also the past, but somehow shared memory multi-threading had a couple of decades of mindshare.

-- 
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 Monday, 10 December 2018 at 06:03:58 UTC, Russel Winder wrote:
> evolved over the years. What GPars does have is combinable futures.

This confirms what I was saying.