www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Go 2, here we come!

reply JN <666total wp.pl> writes:
https://blog.golang.org/go2-here-we-come

"At GopherCon 2017, Russ Cox officially started the thought 
process on the next big version of Go with his talk The Future of 
Go (blog post). We have called this future language informally Go 
2, even though we understand now that it will arrive in 
incremental steps rather than with a big bang and a single major 
release. Still, Go 2 is a useful moniker, if only to have a way 
to talk about that future language, so let’s keep using it for 
now."


Might be interesting to see how Go implements new language 
features and how they deal with limiting breakage of existing 
code.
Nov 29 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 29, 2018 at 09:55:03PM +0000, JN via Digitalmars-d wrote:

 https://blog.golang.org/go2-here-we-come
 
 "At GopherCon 2017, Russ Cox officially started the thought process on
 the next big version of Go with his talk The Future of Go (blog post).
 We have called this future language informally Go 2, even though we
 understand now that it will arrive in incremental steps rather than
 with a big bang and a single major release. Still, Go 2 is a useful
 moniker, if only to have a way to talk about that future language, so
 let’s keep using it for now."
 
 
 Might be interesting to see how Go implements new language features
 and how they deal with limiting breakage of existing code.


I would be curious if they ever plan to add generics of some kind to the
language. If not, I shall remain uninterested in the language.


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system
vulnerabilities cannot touch Linux---is priceless. -- Frustrated system
administrator.
Nov 29 2018
parent reply JN <666total wp.pl> writes:
On Thursday, 29 November 2018 at 22:02:45 UTC, H. S. Teoh wrote:

 I would be curious if they ever plan to add generics of some 
 kind to the language. If not, I shall remain uninterested in 
 the language.


 T


"Ideas from the remaining proposals will likely influence Go 2’s 
libraries and languages. Two major themes have emerged early on: 
support for better error handling, and generics."

https://go.googlesource.com/proposal/+/master/design/go2draft-
enerics-overview.md here's some draft design, although I don't use Go so I
can't say much about it
Nov 29 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Thu, 29 Nov 2018 22:20:50 +0000, JN wrote:

 https://go.googlesource.com/proposal/+/master/design/go2draft-generics-


overview.md

 here's some draft design, although I don't use Go so I can't say much
 about it


I feel like I can!

The proposal has a number of downsides:

* "contract" instead of "constraint" or "concept", which are the widely 
used terms. Go devs can't stand to use terminology the way normal people 
do.
* Functions and types can be templated, but member functions can't.
* Constraints are defined with an example function (basically just `if 
(__traits(compiles, ...))` as the only template constraint type).
* Constraints can't refer to symbols defined in their own package.
* Constraints define everything you can do with a type.
* There is no compile-time introspection.
* There is no function overloading. (Preexisting condition maintained.)

The last three combine to make it very difficult to write nontrivial 
generic code. You can write map/reduce/filter, and you can write some more 
complex stuff.

There are three main benefits here:
* You can write a function that takes arrays, channels, functions, and 
maps of a generic type. (These are builtin parameterized types, and 
interface duck typing doesn't extend to their parameters because of 
covariance / contravariance issues.)
* You can avoid heap allocations and indirect calls sometimes.
* You can be a little less direct referring to concrete types. This is 
useful if, for instance, you're trying to write an alternate 
implementation of an API that refers to concrete types you can't 
instantiate.

Overall, this is about as good as we could have expected in Go. It 

metaprogramming and the same recursive template limitations of D.
Nov 29 2018
parent reply Basile B. <b2.temp gmx.com> writes:
On Friday, 30 November 2018 at 02:12:23 UTC, Neia Neutuladh wrote:

 On Thu, 29 Nov 2018 22:20:50 +0000, JN wrote:

 https://go.googlesource.com/proposal/+/master/design/go2draft-generics-


 overview.md

 here's some draft design, although I don't use Go so I can't 
 say much about it


 I feel like I can!

 The proposal has a number of downsides:

 * There is no function overloading. (Preexisting condition 
 maintained.)


I wonder how do they do visitors in Go. If it's true that classes 
are not 100% necessary for that at least function overloads are 
needed to dispatch.
Nov 30 2018
parent Neia Neutuladh <neia ikeran.org> writes:
On Sat, 01 Dec 2018 03:32:29 +0000, Basile B. wrote:

 On Friday, 30 November 2018 at 02:12:23 UTC, Neia Neutuladh wrote:

 * There is no function overloading. (Preexisting condition maintained.)


 
 I wonder how do they do visitors in Go. If it's true that classes are
 not 100% necessary for that at least function overloads are needed to
 dispatch.


It's utterly straightforward:

    type Visitor interface {
        func VisitForeach(v *ForeachStmt)
        func VisitWhile(v *WhileStmt)
        func VisitIf(v *IfStmt)
    }

    func Visit(self *ForeachStmt)(Visitor visitor) {
        visitor.VisitForeach(self)
    }

The visitor pattern is a manual implementation of multiple dispatch, and 
this sort of name mangling is a manual implementation of function 
overloading.
Nov 30 2018
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2018-11-29 at 14:02 -0800, H. S. Teoh via Digitalmars-d wrote:

 [=E2=80=A6]
=20
 I would be curious if they ever plan to add generics of some kind to the
 language. If not, I shall remain uninterested in the language.


I believe you will find that some form of generics is the main and primary
reason for Go 2.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Nov 30 2018
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 30 November 2018 at 17:43:28 UTC, Russel Winder wrote:

 I believe you will find that some form of generics is the main 
 and primary reason for Go 2.


Mmm, yes, but they will probably try to keep it simple. They need 
to bring along all those Go programmers that went with Go because 
it was a simple language...
Dec 03 2018
parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2018-12-03 at 14:41 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-d
wrote:

 On Friday, 30 November 2018 at 17:43:28 UTC, Russel Winder wrote:

 I believe you will find that some form of generics is the main=20
 and primary reason for Go 2.


=20
 Mmm, yes, but they will probably try to keep it simple. They need=20
 to bring along all those Go programmers that went with Go because=20
 it was a simple language...


But they also have to make good on the promise to introduce generics if it =
was
shown interface was not up to the task, and there was a viable system, and =
to
stop everyone decrying the uselessness of Go because of lack of generics.

Now that Go seems to have a role of replacing Java in The Cloud, generics i=
s a
far more serious issue than it was three years ago =E2=80=93 there is nothi=
ng quite as
stimulating of action as big company spokespeople rather than private
individuals making disparaging remarks. So the Go team have more or less be=
en
forced to find an acceptable generics system, which they haven't tried
seriously before.

The arguments on the mailing list seem to be ignored by the core Go team, s=
o I
feel we can assume they have their preferred solution =E2=80=93 which will =
likely be
the one Russ Cox has been writing about.
=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Dec 03 2018
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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 seems to be 
stuck with old sins...
Dec 04 2018
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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...
Dec 04 2018
prev sibling parent reply Bienlein <jeti789 web.de> writes:
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
Dec 04 2018
parent reply Russel Winder <russel winder.org.uk> writes:
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=20
 Cloud, ...


=20
 Java is now also getting CSP-style concurrency as in Go, see this=20
 presentation by Mark Reinhold:
=20
 https://www.youtube.com/watch?time_continue=3D4125&v=3DnKJbDYRsO0s
=20
 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.=20

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.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Dec 04 2018
parent reply Bienlein <jeti789 web.de> writes:
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.
Dec 09 2018
parent reply Russel Winder <russel winder.org.uk> writes:
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=20
 wrote:

 Project Loom is really about bringing an evolution of Quasar=20
 into the JVM so as to avoid all the hacking around that Quasar=20
 currently has to do to work properly. I think this is a good=20
 thing, and about time it happened.
=20
 GPars had all this stuff in 2008. :-)
=20
 GPars is now effectively a dead project.


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


GPars is founded on Java concurrency so threadpools and fork/join. There wa=
s
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 h=
as
evolved over the years. What GPars does have is combinable futures.


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


=20
 They had a module to have something like green threads before=20
 Rust turned 1.0 and then canceled it before Rust 1.0 was=20
 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 smal=
l
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 i=
s
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=20
 the existign solution for fibers you could greate something that=20
 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.=20

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

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
Dec 09 2018
parent Bienlein <ffm2002 web.de> writes:
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.
Dec 09 2018