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.

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.

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-generics-overview.md here's some draft design, although I don't use Go so I can't say much about it

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 sidesteps the covariance / contravariance stuff in C# and Java, but no metaprogramming and the same recursive template limitations of D.

On Thu, 2018-11-29 at 14:02 -0800, H. S. Teoh via Digitalmars-d 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.

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

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

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.

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

On Mon, 2018-12-03 at 14:41 +0000, Ola Fosheim Grøstad 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 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...

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

The arguments on the mailing list seem to be ignored by the core Go team, so I
feel we can assume they have their preferred solution – which will likely be
the one Russ Cox has been writing about.

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