Re: [go-nuts] Generics - please provide real life problems

[Ian Lance Taylor]

On Wed, Dec 23, 2020 at 10:15 PM Martin Hanson
 wrote:
>
> I have been arguing passionately against adding generics to Go because
> I truly believe that it is going against the simplicity of Go and the
> philosophy behind the design of Go.
>
> I believe that the resilience of Go against unnecessary change is of
> vital importance. The experience provided by Ken Thompson, Rob Pike and
> Robert Griesemer in designing Go the way they did speaks for itself.
>
> I feel and believe it is of imperative importance to avoid adding things
> to Go that doesn't present a true and real life day-to-day problem
> and so far none of the examples the pro-generics camp has provided has
> been more than minor theoretical examples that do not present any real
> life problems.
>
> I therefore propose that the pro-generics camp provide real examples of
> problems they have faced that was such a big issue that it justifies
> adding generics to Go.
>
> If all we're presented are these small theoretical examples of sorting
> lists, etc., then clearly this is nothing but hype that needs to go
> away.

I wrote a number of examples under "What generics can bring to Go" in
https://blog.golang.org/why-generics .

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcV-21XyehX5xM%3DD4Rv92qra%2B9ZyNo8vuiPtG_gmVdz0TQ%40mail.gmail.com.

Re:[go-nuts] Generics - please provide real life problems

[Martin Hanson]

I'm sorry, but this is not real life problems. This is exactly the problem with 
this proposal. It's based on nothing but small theoretical examples.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/16410701608794283%40vla5-c5051da8689e.qloud-c.yandex.net.

Re:[go-nuts] Generics - please provide real life problems

[Martin Hanson]

I write this from my understanding of the "Proposal selection criteria", which 
clearly states, that in order for a proposal to be accepted, it has to "address 
an important issue for many people".

This is why I'm asking for real life problem examples, not theoretical ones.

I do not believe that adding generics solves any real life issues that is 
important for many people. These small examples with sorting lists etc. clearly 
do not present an important issue (real life problem) for many people.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/813181608794977%40iva3-77ae5995f07f.qloud-c.yandex.net.

Re:[go-nuts] Generics - please provide real life problems

[Martin Hanson]

Oh, I almost forgot, it also clearly does not "have minimal impact on everybody 
else", which is another proposal selection criteria. Go code becomes much more 
complex to read and understand from all the examples I have seen.

You can even find several YouTube videos with people trying to analyze and 
understand the Go generics code in the examples, and they are all struggling.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/910771608795256%40sas8-ed615920eca2.qloud-c.yandex.net.

Re: [go-nuts] Generics - please provide real life problems

[Igor Cananea]

While the example of ReverseSlice doesn't appear in my work experience, the
concept of writing functions for slices independent of type is pretty
common for me.

Not having to copy to/from []someInterface or having to write (or go
generate) multiple versions of the code differing only on the type would
allow me to delete quite a bit of code.

On Wed, Dec 23, 2020, 23:35 Martin Hanson 
wrote:

> Oh, I almost forgot, it also clearly does not "have minimal impact on
> everybody else", which is another proposal selection criteria. Go code
> becomes much more complex to read and understand from all the examples I
> have seen.
>
> You can even find several YouTube videos with people trying to analyze and
> understand the Go generics code in the examples, and they are all
> struggling.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/910771608795256%40sas8-ed615920eca2.qloud-c.yandex.net
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEX6X_B__7QpYSEG_gyp8aWnmjnpM5M-GmdfBp3Mw7mDiY5xeg%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Marcin Romaszewicz]

Those are simple examples of real world problems. I've been writing Go
since the very beginning, having worked at Google when it was released and
since I enjoy the language so much, I try to write all the backend server
code in Go that I can. In these years, I've had to write many code
generators to make my life a little easier, and they tend to be for data
structures or API models.

Generics would allow for writing less code, and re-using it more. As long
as it doesn't complicate the base language, why not? You don't have to use
them :)

On Wed, Dec 23, 2020 at 11:18 PM Martin Hanson 
wrote:

> I'm sorry, but this is not real life problems. This is exactly the problem
> with this proposal. It's based on nothing but small theoretical examples.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/16410701608794283%40vla5-c5051da8689e.qloud-c.yandex.net
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LtcJznVweM16fD4WKci8ixstUQnODJEgxeYUQvofAtp0w%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Sebastien Binet]

Hi,

I apologize but I must disagree.
Those *are* real life examples.
At least they're extracted from these.

Especially the 'chans' package (the set of generic functions that apply to any 
'chan T') or the 'mapreduce' one.

You can't discard those away from the back of your hand.

-s

Sent from ProtonMail mobile

 Original Message 
On Dec 24, 2020, 08:18, Martin Hanson wrote:

> I'm sorry, but this is not real life problems. This is exactly the problem 
> with this proposal. It's based on nothing but small theoretical examples.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/16410701608794283%40vla5-c5051da8689e.qloud-c.yandex.net.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/Gs3F-i4YWw_n4OxjJAWyZ47G9WKJAY7uj5tIHSGkOA-UDbqmaQuA8IeaCE9vBYoCV8hK6uJYt3eAMy_nPPYyg2wpgQaKa7f8d95h-Kc0D5o%3D%40sbinet.org.

Re: [go-nuts] Generics - please provide real life problems

['Axel Wagner' via golang-nuts]

On Thu, Dec 24, 2020 at 8:30 AM Martin Hanson 
wrote:

> I write this from my understanding of the "Proposal selection criteria",
> which clearly states, that in order for a proposal to be accepted, it has
> to "address an important issue for many people".
>

It does. There is absolutely zero doubt (and there hasn't even been any
doubt in my mind when I was still as staunchily opposed to generics as you
are now) that it's an important issue for many people - that's why it comes
up in literally any conversation you have about whether or not using Go.

There are many, *many* people who clearly consider this an important
problem. You clearly disagree with them, but at some point, you will *have*
to accept that disagreeing with people doesn't mean their opinion just
doesn't exist.

This is why I'm asking for real life problem examples, not theoretical ones.
>

No single problem will ever justify adding generics. The value of them is
in adding many small conveniences. I expect to use them every single day I
code in Go - most of the time because a function or type will be provided
by the stdlib, where it wasn't before. For example, I expect that there
will be generic stack and set implementations - I use both of them quite a
lot. You mention sorting and I do *that* in basically every Go program I
write and it will become slightly more convenient. I expect the heap
implementation will become more convenient to a degree where I actually
feel okay using it - a problem I've come across repeatedly, again.

None of these are big payoffs, they are all relatively small improvements
of not having to write a handful of extra lines of code. But small
improvements add up.

I do not believe that adding generics solves any real life issues that is
> important for many people. These small examples with sorting lists etc.
> clearly do not present an important issue (real life problem) for many
> people.
>

Can you justify that statement, given how many people complain about the Go
sorting API? I'm starting to wonder if you actually talk to people who are
not already fully bought into Go yet.


>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/813181608794977%40iva3-77ae5995f07f.qloud-c.yandex.net
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfECd-ELy7ix19Q9MVQZxsEnbO98OV3EJD2wTcj-EfxpGA%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

['Dan Kortschak' via golang-nuts]

I agree.

A lot of Gonum code would be greatly simplified with the availability
of generics, particularly the linear algebra part. The graph packages
would be richer and we could do more things with tensor-like
operations.

On Wed, 2020-12-23 at 23:54 -0800, Marcin Romaszewicz wrote:
> Those are simple examples of real world problems. I've been writing
> Go since the very beginning, having worked at Google when it was
> released and since I enjoy the language so much, I try to write all
> the backend server code in Go that I can. In these years, I've had to
> write many code generators to make my life a little easier, and they
> tend to be for data structures or API models. 
> 
> Generics would allow for writing less code, and re-using it more. As
> long as it doesn't complicate the base language, why not? You don't
> have to use them :)
> 
> On Wed, Dec 23, 2020 at 11:18 PM Martin Hanson <
> greencopperm...@yandex.com> wrote:
> > I'm sorry, but this is not real life problems. This is exactly the
> > problem with this proposal. It's based on nothing but small
> > theoretical examples.
> > 



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/06457ed1f86e399d7d00e3c7605d32130c96641c.camel%40kortschak.io.

Re: [go-nuts] Generics - please provide real life problems

[Uli Kunitz]

I second this. Linear Algebra code would dramatically benefit from 
generics. Code would become much more simpler if you could write Tensor and 
Matrix code independent of the type of the numeric values used by those 
types.
 Practical applications are graphics libraries, geography applications and 
machine learning.

Note also that access through interfaces is always slow. Depending on the 
way generics will be implemented, there could be huge performance benefits. 
Imagine sort code would not need to call a function for every element swap 
and comparison function. Sorting is a very practical application.

I agree with the original poster that there is a risk that generics will 
lead some folks to overuse the concept impacting the readability of the 
language. An advantage of Go right now is, that most of the problems have 
to be reduced to slices or maps. Generics could immediately lead to 
mushrooming of badly designed container types addressing minor concerns. In 
other languages generics are used for error return values.

A lot will depend how Generics are introduced in the standard library. I 
would recommend a conservative approach. Extend or replace the current 
container types first and faster sorting for slices. Generics for errors, 
all kinds of asynchronous shenanigans should be introduced after those new 
methods have been battle-tested outside of the standard library to filter 
bad approaches from the good ones.
On Thursday, December 24, 2020 at 11:21:10 AM UTC+1 kortschak wrote:

> I agree.
>
> A lot of Gonum code would be greatly simplified with the availability
> of generics, particularly the linear algebra part. The graph packages
> would be richer and we could do more things with tensor-like
> operations.
>
> On Wed, 2020-12-23 at 23:54 -0800, Marcin Romaszewicz wrote:
> > Those are simple examples of real world problems. I've been writing
> > Go since the very beginning, having worked at Google when it was
> > released and since I enjoy the language so much, I try to write all
> > the backend server code in Go that I can. In these years, I've had to
> > write many code generators to make my life a little easier, and they
> > tend to be for data structures or API models. 
> > 
> > Generics would allow for writing less code, and re-using it more. As
> > long as it doesn't complicate the base language, why not? You don't
> > have to use them :)
> > 
> > On Wed, Dec 23, 2020 at 11:18 PM Martin Hanson <
> > greenco...@yandex.com> wrote:
> > > I'm sorry, but this is not real life problems. This is exactly the
> > > problem with this proposal. It's based on nothing but small
> > > theoretical examples.
> > > 
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3dc07ed3-8587-4b9b-a68b-e5e7abaabd0an%40googlegroups.com.

Re: [go-nuts] Generics - please provide real life problems

[K. Alex Mills]

On Thu, Dec 24, 2020, 1:18 AM Martin Hanson 
wrote:

> I'm sorry, but this is not real life problems. This is exactly the problem
> with this proposal. It's based on nothing but small theoretical examples.
>

Sorry, I don't understand.

Here are some of the example applications which Ian mentions in the article.

   - Find smallest/largest element in slice
   - Find average/standard deviation of slice
   - Compute union/intersection of maps
   - Find shortest path in node/edge graph
   - Apply transformation function to slice/map, returning new slice/map
   - Read from a channel with a timeout
   - Combine two channels into a single channel
   - Call a list of functions in parallel, returning a slice of results
   - Call a list of functions, using a Context, return the result of the
   first function to finish, canceling and cleaning up extra goroutines

While they are all fairly low-level, these are all examples which have a
high degree of real-life utility. Some of these items have non-trivial
solutions which are easy to get wrong and difficult to optimize. In my
view, that increases the value of any solution to these problems which uses
generics.

Perhaps in complaining they are theoretical you are saying that you would
like to see concrete implementations of these problems rather than a
bulleted list. That's fair. However, I can understand why that wasn't part
of the original article, given that some of the implementations are not
blog-sized, and the proposal is still in flux. Maybe we can begin to
explore what the solutions can look like.

>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALJzkY8Doa1Fxe_U_283q%2BM1wrEc2AtyPHEiftPDYKL1W3%2BE%3DQ%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[David Riley]

Indeed. I'm working on a boolean logic package that has a number of different 
bitfield oriented backends, all of which will have a lot of very needlessly 
repetitive code without generics. If generics weren't coming "soon" I'd 
consider writing a generator to build it, but generics are the much more 
elegant solution. This is absolutely a real-world problem that I am having, 
right now, in the real world.


- Dave


> On Dec 24, 2020, at 5:20 AM, 'Dan Kortschak' via golang-nuts 
>  wrote:
> 
> I agree.
> 
> A lot of Gonum code would be greatly simplified with the availability
> of generics, particularly the linear algebra part. The graph packages
> would be richer and we could do more things with tensor-like
> operations.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/D9FC4D9B-BB55-4AA8-A9D5-6238E0C1FF84%40gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Jesper Louis Andersen]

On Thu, Dec 24, 2020 at 7:15 AM Martin Hanson 
wrote:

> I therefore propose that the pro-generics camp provide real examples of
> problems they have faced that was such a big issue that it justifies
> adding generics to Go.
>
>
Maintaining type safety is a lot easier with generics. Right now, my code
base is littered with places where I push/pull from interface{} and wrap it
in types to make it type safe for other parts of the code. That is a lot of
boilerplate code I've written. And I need to maintain said code as it
changes. With generics, I get a way to universally handle this, and I can
ditch most of the boilerplate code.

It mostly has to do with containers and data structures in my code. I need
a heap over any type which can be ordered, and its needs to drag around any
type of satellite data. Furthermore, I'd like to unbox satellite data,
which generics will kick in a door for in the future.

I'm also doing lots of TensorFlow, and if I had a proper shape-analysis
phase in my compiler,  Generics is a stepping stone toward that.

-- 
J.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiX%3D1uXVc162MQ6shoaQ4r%3D3sc1x1y01eqpTY3StyYuuyg%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Tristan Colgate]

If Go with generics wax released tomorrow  I have about 8 kubernetes
controllers that I'd be porting to use a type safe version  of the work
queue  to.
 This isn't theoretical, I will do this week 1 of generics being available.
It is all production code.

On Thu, 24 Dec 2020, 06:15 Martin Hanson, 
wrote:

> I have been arguing passionately against adding generics to Go because
> I truly believe that it is going against the simplicity of Go and the
> philosophy behind the design of Go.
>
> I believe that the resilience of Go against unnecessary change is of
> vital importance. The experience provided by Ken Thompson, Rob Pike and
> Robert Griesemer in designing Go the way they did speaks for itself.
>
> I feel and believe it is of imperative importance to avoid adding things
> to Go that doesn't present a true and real life day-to-day problem
> and so far none of the examples the pro-generics camp has provided has
> been more than minor theoretical examples that do not present any real
> life problems.
>
> I therefore propose that the pro-generics camp provide real examples of
> problems they have faced that was such a big issue that it justifies
> adding generics to Go.
>
> If all we're presented are these small theoretical examples of sorting
> lists, etc., then clearly this is nothing but hype that needs to go
> away.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/19560461608790506%40sas1-75175cadc2b3.qloud-c.yandex.net
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGZSGJOuB9G5DS%2BvO5X1RudTOWAzfOD2eBW36JwMPyNXdAZ_g%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Jan Mercl]

On Sun, Dec 27, 2020 at 3:51 PM Jesper Louis Andersen
 wrote:

> I need a heap over any type which can be ordered, and its needs to drag 
> around any type of satellite data.

I'm confused. Isn't that what
https://golang.org/pkg/container/heap/#Interface provides already?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-Wo6TY0YrB4RLMPnnwayZwshC4EZbAENGMJv4LSdSbpaA%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Jesper Louis Andersen]

On Sun, Dec 27, 2020 at 7:51 PM Jan Mercl <0xj...@gmail.com> wrote:

> On Sun, Dec 27, 2020 at 3:51 PM Jesper Louis Andersen
>  wrote:
>
> > I need a heap over any type which can be ordered, and its needs to drag
> around any type of satellite data.
>
> I'm confused. Isn't that what
> https://golang.org/pkg/container/heap/#Interface provides already?
>
Almost. It requires me to cast, so I'm wrapping it in a set of functions
which makes that cast. With generics, I can get rid of that boilerplate.



-- 
J.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVXoC%3DF_CNSxE5cC6E%3D7s4WrhF-NzqAM7bEwoo63vAD2w%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Jan Mercl]

On Wed, Dec 30, 2020 at 3:09 PM Jesper Louis Andersen
 wrote:

> Almost. It requires me to cast, so I'm wrapping it in a set of functions 
> which makes that cast. With generics, I can get rid of that boilerplate.

(Casting? Method receivers have static types.) So some use cases boil
down to having to write a dozen or half lines of code vs following the
popular 25% vote and shifting Go towards where so many happily escaped
from.

Don't get me wrong. No doubt there are use cases which cannot be
solved reasonably without generics. No doubt there are many other
cases where generics will be an elegant and still readable solution
either.

I'm just not convinced that there will _not_ be a ton of bad code, bad
because abusing generics, floating around in the future which I will
have to read/cope with, if I would want to still use Go for 99% of my
tasks at that point.

FTR: Popular vote also demands exceptions or hidden execution control
for errors, operator overloading and other things that IMO Go avoided
intentionally. Because there's no good reason to have just yet another
Java/C++/you-name-it programming language.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-V2N3Y_nqE%2BuB_KbVCW5-R3%2B4W3iz2F6wnVdOBmZsJ2BQ%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Jesper Louis Andersen]

On Wed, Dec 30, 2020 at 3:37 PM Jan Mercl <0xj...@gmail.com> wrote:

>
> Don't get me wrong. No doubt there are use cases which cannot be
> solved reasonably without generics. No doubt there are many other
> cases where generics will be an elegant and still readable solution
> either.
>
>
I don't disagree on this view. More expressive power in a language is also
more power to make incomprehensible APIs. I've seen my fair share of
interface-heavy APIs which shouldn't have used interfaces in the first
place,
or should have been placed at a different layer of abstraction.

I've also seen my fair share of Haskell code where the problem is also
present.

-- 
J.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiX6CdGPx76z-QZ3jz-Rr8E-LX36%2B%2BD8p_fh5HF1CnUh%2Bg%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Kevin Chadwick]

On 12/30/20 2:36 PM, Jan Mercl wrote:
> Because there's no good reason to have just yet another
> Java/C++/you-name-it programming language.

I get that point but I have lots of reasons to prefer Go over those. Mostly
readability (but also using utf-16, is just wrong). I know Ian is reportedly
taking readability very seriously at the cost of implementation difficulty, at
least? I don't have the time to commit to analysis, myself. I expect that may
succumb a little to implementers requests during protoyping.


I would love Go to be a safe C that can run everywhere.

Alas, it isn't. The original developers pains were in using c++, not c and they
deserve to reap the benefits of their hard work.

Selfishly, I do hope generics won't have negative effects on runtime/binary size
WRT tinyGo and gomobile.


I was going to delete the rest, but it may explain my skepticism to a degree.

I am still of the opinion that I am yet to see strong arguments for Generics
tbh. Mostly it seems to be a way to fix interfaces, which I don't implement
anyway. When raising the simple case of casting strings to bytes, which
represent most things, the response was, not a pain point. I am happy writing
multiple functions as I expect at some point they will diverge and have the best
chance of being efficient in the process. I don't see why Kubernetes queue
handling isn't type safe already (lack of API control, laziness/work pressure?).
Many experiences may differ and I am surely missing a lot of the details.

I am simply hoping the team and communities will do such a good job of Generics
that we will become thankful for them, in the end. Possibly not. I am very
thankful for channels but not interfaces or methods, despite many attempts to
appreciate them I seem to disagree with the benefits proposed from so many
interfaces articles and videos that I have stopped wasting my time now (Calhouns
was probably the best of them). I simply prefer the c ways to solve the same
problems, atleast for my purposes. I seem to be in the minority there though as
the community seems to love, that which I find pointless. Interfaces even make
reading more difficult, if you care about the details but it doesn't affect me
too much, aside from some wasted time.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6eac705e-16b1-b8c1-9744-7ab64bea6087%40gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Ian Lance Taylor]

On Wed, Dec 30, 2020 at 6:38 AM Jan Mercl <0xj...@gmail.com> wrote:
>
> FTR: Popular vote also demands exceptions or hidden execution control
> for errors, operator overloading and other things that IMO Go avoided
> intentionally. Because there's no good reason to have just yet another
> Java/C++/you-name-it programming language.

I don't think this is accurate.  Surveys express a clear and
consistent desire for generics that is far ahead of requests for
operator overloading or other language features.  (To avoid
misunderstanding I'll say again that changes to the Go language are
not driven by polls.)

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUKg6VYHVXi672RbghN4XzEqKC5qtF%2B6t_DCmXEBXDpcg%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Jan Mercl]

On Wed, Dec 30, 2020 at 7:38 PM Ian Lance Taylor  wrote:

> I don't think this is accurate.  Surveys express a clear and
> consistent desire for generics that is far ahead of requests for
> operator overloading or other language features.

No ordering or quantitative comparison was implied. Just that one can
always find people wanting well known features from other languages.

> (To avoid
> misunderstanding I'll say again that changes to the Go language are
> not driven by polls.)

I know that. The point was actually about that very fact - and its
contrast wrt arguments like "folks want XYZ". But I may have not
expressed it clearly enough.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA40n-UQw1VK3r7ag9KzQnVVDHPgFSr8Rsc9psp8vib-YA7VwQ%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

"runtime type-casting"
"type safety something" 
"boilerplate"
"amount of code"
"benefit something"
"greatly simplified" (for whom?)

This topic has clearly shown that most people pro-generic have no *real 
world* problems that they struggle to solve, yet most of them don't even 
understand what *real world* problems are.

PS: What about "Clear is better than clever"? What about to try to apply 
some creativity rather than follow one single pattern?
среда, 30 декабря 2020 г. в 21:53:42 UTC+3, Jan Mercl: 

> On Wed, Dec 30, 2020 at 7:38 PM Ian Lance Taylor  wrote:
>
> > I don't think this is accurate. Surveys express a clear and
> > consistent desire for generics that is far ahead of requests for
> > operator overloading or other language features.
>
> No ordering or quantitative comparison was implied. Just that one can
> always find people wanting well known features from other languages.
>
> > (To avoid
> > misunderstanding I'll say again that changes to the Go language are
> > not driven by polls.)
>
> I know that. The point was actually about that very fact - and its
> contrast wrt arguments like "folks want XYZ". But I may have not
> expressed it clearly enough.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/49eaf9fd-ee2b-4b48-8ffc-43d9e805c510n%40googlegroups.com.

Re: [go-nuts] Generics - please provide real life problems

[David Riley]

This topic has shown little other than that a few people here are unwilling to 
consider points of view other than their own and declare that very real 
problems are not real.

You should listen to people who have been doing this much longer than you have 
before discarding all their points as "bullshit", and you should probably 
review the community code of conduct.

If you've got nothing constructive to contribute, why bother?


- Dave


> On Dec 30, 2020, at 3:53 PM, Space A.  wrote:
> 
> "runtime type-casting"
> "type safety something"
> "boilerplate"
> "amount of code"
> "benefit something"
> "greatly simplified" (for whom?)
> 
> This topic has clearly shown that most people pro-generic have no *real 
> world* problems that they struggle to solve, yet most of them don't even 
> understand what *real world* problems are.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/DA26E9B9-7B96-4730-BDBB-F2F52EF510FF%40gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

Nice.

> You should listen to people who have been doing this much longer than you
Thanks, are you sure you know for how long I've been doing *this* to be
able to compare?
> before discarding all their points as "bullshit"
Have *you* actually read and listened because this is not what I've said?
> and you should probably review the community code of conduct
So switching from subject to my personality and telling me what I should
and what shouldn't, to whom to listen, and what to read is something in
line with "code of conduct" which you appeal as the argument of last resort?


This was actually my first comment on this particular topic. So yea, I read
and listened before replying. I could have replied to everyone and
explained in detail, but I value the time of my opponents. And my own time,
tbh.


чт, 31 дек. 2020 г. в 00:03, David Riley :

> This topic has shown little other than that a few people here are
> unwilling to consider points of view other than their own and declare that
> very real problems are not real.
>
> You should listen to people who have been doing this much longer than you
> have before discarding all their points as "bullshit", and you should
> probably review the community code of conduct.
>
> If you've got nothing constructive to contribute, why bother?
>
>
> - Dave
>
>
> > On Dec 30, 2020, at 3:53 PM, Space A.  wrote:
> >
> > "runtime type-casting"
> > "type safety something"
> > "boilerplate"
> > "amount of code"
> > "benefit something"
> > "greatly simplified" (for whom?)
> >
> > This topic has clearly shown that most people pro-generic have no *real
> world* problems that they struggle to solve, yet most of them don't even
> understand what *real world* problems are.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADKwOTek6rrfmMziuj5poy4hAZJ%3DHXsyp-FB96RdUvZ%2BncoJYA%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[robert engels]

I don't know how Go users can be ‘anti interface’ - literally 95% of the stdlib 
is based on interfaces. If you use the stdlib, you use interfaces.

> On Dec 30, 2020, at 9:44 AM, Jesper Louis Andersen 
>  wrote:
> 
> On Wed, Dec 30, 2020 at 3:37 PM Jan Mercl <0xj...@gmail.com 
> > wrote:
> 
> Don't get me wrong. No doubt there are use cases which cannot be
> solved reasonably without generics. No doubt there are many other
> cases where generics will be an elegant and still readable solution
> either.
> 
> 
> I don't disagree on this view. More expressive power in a language is also
> more power to make incomprehensible APIs. I've seen my fair share of
> interface-heavy APIs which shouldn't have used interfaces in the first place,
> or should have been placed at a different layer of abstraction.
> 
> I've also seen my fair share of Haskell code where the problem is also 
> present.
> 
> -- 
> J.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiX6CdGPx76z-QZ3jz-Rr8E-LX36%2B%2BD8p_fh5HF1CnUh%2Bg%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8E6FD1E2-48E7-46F5-B5D1-422AF1E6F916%40ix.netcom.com.

Re: [go-nuts] Generics - please provide real life problems

[Amnon]

I would like a type-safe version of sync.Map().


On Wednesday, 30 December 2020 at 23:02:48 UTC ren...@ix.netcom.com wrote:

> I don't know how Go users can be ‘anti interface’ - literally 95% of the 
> stdlib is based on interfaces. If you use the stdlib, you use interfaces.
>
> On Dec 30, 2020, at 9:44 AM, Jesper Louis Andersen <
> jesper.lou...@gmail.com> wrote:
>
> On Wed, Dec 30, 2020 at 3:37 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>>
>> Don't get me wrong. No doubt there are use cases which cannot be
>> solved reasonably without generics. No doubt there are many other
>> cases where generics will be an elegant and still readable solution
>> either.
>>
>>
> I don't disagree on this view. More expressive power in a language is also
> more power to make incomprehensible APIs. I've seen my fair share of
> interface-heavy APIs which shouldn't have used interfaces in the first 
> place,
> or should have been placed at a different layer of abstraction.
>
> I've also seen my fair share of Haskell code where the problem is also 
> present.
>
> -- 
> J.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiX6CdGPx76z-QZ3jz-Rr8E-LX36%2B%2BD8p_fh5HF1CnUh%2Bg%40mail.gmail.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/483c3f92-097e-4954-b4df-135b6ab561e4n%40googlegroups.com.

Re: [go-nuts] Generics - please provide real life problems

[robert engels]

Agreed.

I had proposed a different approach, where the built-in map and slice could 
have alternative implementations chosen during make(). 95% of generics usage is 
collections. I think this would have retained the simplicity of Go a bit better 
than generics - but at the end of day - generics are not “difficult". Bad 
programmers write bad code without generics.

> On Dec 30, 2020, at 5:15 PM, Amnon  wrote:
> 
> I would like a type-safe version of sync.Map().
> 
> 
> On Wednesday, 30 December 2020 at 23:02:48 UTC ren...@ix.netcom.com wrote:
> I don't know how Go users can be ‘anti interface’ - literally 95% of the 
> stdlib is based on interfaces. If you use the stdlib, you use interfaces.
> 
> 
>> On Dec 30, 2020, at 9:44 AM, Jesper Louis Andersen > > wrote:
>> 
> 
>> On Wed, Dec 30, 2020 at 3:37 PM Jan Mercl <0xj...@gmail.com 
>> > wrote:
>> 
>> Don't get me wrong. No doubt there are use cases which cannot be
>> solved reasonably without generics. No doubt there are many other
>> cases where generics will be an elegant and still readable solution
>> either.
>> 
>> 
>> I don't disagree on this view. More expressive power in a language is also
>> more power to make incomprehensible APIs. I've seen my fair share of
>> interface-heavy APIs which shouldn't have used interfaces in the first place,
>> or should have been placed at a different layer of abstraction.
>> 
>> I've also seen my fair share of Haskell code where the problem is also 
>> present.
>> 
>> -- 
>> J.
>> 
> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com 
>> .
> 
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiX6CdGPx76z-QZ3jz-Rr8E-LX36%2B%2BD8p_fh5HF1CnUh%2Bg%40mail.gmail.com
>>  
>> .
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/483c3f92-097e-4954-b4df-135b6ab561e4n%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/00594B09-CB09-43F5-9ECA-328E2016846A%40ix.netcom.com.

Re: [go-nuts] Generics - please provide real life problems

[Tyler Compton]

Hi Martin,

You've been very willing in this thread to listen to feedback, and I
appreciate that. I hope it doesn't feel like I'm ganging up on you, but I
want to comment on one other point I disagree with in your original premise.

I believe that the resilience of Go against unnecessary change is of
> vital importance. The experience provided by Ken Thompson, Rob Pike and
> Robert Griesemer in designing Go the way they did speaks for itself.
>

This kind of sentiment is something I often see when discussing generics.
It's worth pointing out that the original creators you mentioned are still
at least somewhat involved with Go's development and would make it known if
they believe the current generics proposal violated the spirit of the
language. Generics have been left as an open question on the FAQ
 for a very long time. These things
don't make an argument for generics on their own, but they do suggest that
Go's original team was and is not dead set against generics, for what
that's worth.

On Wed, Dec 23, 2020 at 11:15 PM Martin Hanson 
wrote:

> I have been arguing passionately against adding generics to Go because
> I truly believe that it is going against the simplicity of Go and the
> philosophy behind the design of Go.
>
> I believe that the resilience of Go against unnecessary change is of
> vital importance. The experience provided by Ken Thompson, Rob Pike and
> Robert Griesemer in designing Go the way they did speaks for itself.
>
> I feel and believe it is of imperative importance to avoid adding things
> to Go that doesn't present a true and real life day-to-day problem
> and so far none of the examples the pro-generics camp has provided has
> been more than minor theoretical examples that do not present any real
> life problems.
>
> I therefore propose that the pro-generics camp provide real examples of
> problems they have faced that was such a big issue that it justifies
> adding generics to Go.
>
> If all we're presented are these small theoretical examples of sorting
> lists, etc., then clearly this is nothing but hype that needs to go
> away.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/19560461608790506%40sas1-75175cadc2b3.qloud-c.yandex.net
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0y2TqL6rCODoiJD%3D1n8wuGawM7jZw9-zfqD5Sx_oRttg%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Tyler Compton]

Space A,


> So switching from subject to my personality and telling me what I should
> and what shouldn't, to whom to listen, and what to read is something in
> line with "code of conduct" which you appeal as the argument of last resort?
>

I've seen how you carry yourself on this list, and you really should read
the code of conduct. I think your arguments would gain quite a bit more
traction on this list if you presented them in a more respectful way.

On Wed, Dec 30, 2020 at 3:47 PM Space A.  wrote:

> Nice.
>
> > You should listen to people who have been doing this much longer than you
> Thanks, are you sure you know for how long I've been doing *this* to be
> able to compare?
> > before discarding all their points as "bullshit"
> Have *you* actually read and listened because this is not what I've said?
> > and you should probably review the community code of conduct
> So switching from subject to my personality and telling me what I should
> and what shouldn't, to whom to listen, and what to read is something in
> line with "code of conduct" which you appeal as the argument of last resort?
>
>
> This was actually my first comment on this particular topic. So yea, I
> read and listened before replying. I could have replied to everyone and
> explained in detail, but I value the time of my opponents. And my own time,
> tbh.
>
>
> чт, 31 дек. 2020 г. в 00:03, David Riley :
>
>> This topic has shown little other than that a few people here are
>> unwilling to consider points of view other than their own and declare that
>> very real problems are not real.
>>
>> You should listen to people who have been doing this much longer than you
>> have before discarding all their points as "bullshit", and you should
>> probably review the community code of conduct.
>>
>> If you've got nothing constructive to contribute, why bother?
>>
>>
>> - Dave
>>
>>
>> > On Dec 30, 2020, at 3:53 PM, Space A.  wrote:
>> >
>> > "runtime type-casting"
>> > "type safety something"
>> > "boilerplate"
>> > "amount of code"
>> > "benefit something"
>> > "greatly simplified" (for whom?)
>> >
>> > This topic has clearly shown that most people pro-generic have no *real
>> world* problems that they struggle to solve, yet most of them don't even
>> understand what *real world* problems are.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CADKwOTek6rrfmMziuj5poy4hAZJ%3DHXsyp-FB96RdUvZ%2BncoJYA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu0nbJE9q3P46rEkRjo5nhWPkevJT1DYY2H39zkQhQEM%3Dw%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

Hi,
ok, so please read it finally and tell which point exactly you think was
against CoC and in what of my messages and in which exact thread, but do
not put my words out of context. And explain why you responded just now,
and to my message to a person who obviously *violated* its terms by
aggressively turning to my personality.

Do you protect this aggressive behavior just because you pro-generics and
silently hate everything I will say (and me personally)? Because if you do,
it's quite stupid. But I hope it's not.


чт, 31 дек. 2020 г. в 07:51, Tyler Compton :

> Space A,
>
>
>> So switching from subject to my personality and telling me what I should
>> and what shouldn't, to whom to listen, and what to read is something in
>> line with "code of conduct" which you appeal as the argument of last resort?
>>
>
> I've seen how you carry yourself on this list, and you really should read
> the code of conduct. I think your arguments would gain quite a bit more
> traction on this list if you presented them in a more respectful way.
>
> On Wed, Dec 30, 2020 at 3:47 PM Space A.  wrote:
>
>> Nice.
>>
>> > You should listen to people who have been doing this much longer than
>> you
>> Thanks, are you sure you know for how long I've been doing *this* to be
>> able to compare?
>> > before discarding all their points as "bullshit"
>> Have *you* actually read and listened because this is not what I've said?
>> > and you should probably review the community code of conduct
>> So switching from subject to my personality and telling me what I should
>> and what shouldn't, to whom to listen, and what to read is something in
>> line with "code of conduct" which you appeal as the argument of last resort?
>>
>>
>> This was actually my first comment on this particular topic. So yea, I
>> read and listened before replying. I could have replied to everyone and
>> explained in detail, but I value the time of my opponents. And my own time,
>> tbh.
>>
>>
>> чт, 31 дек. 2020 г. в 00:03, David Riley :
>>
>>> This topic has shown little other than that a few people here are
>>> unwilling to consider points of view other than their own and declare that
>>> very real problems are not real.
>>>
>>> You should listen to people who have been doing this much longer than
>>> you have before discarding all their points as "bullshit", and you should
>>> probably review the community code of conduct.
>>>
>>> If you've got nothing constructive to contribute, why bother?
>>>
>>>
>>> - Dave
>>>
>>>
>>> > On Dec 30, 2020, at 3:53 PM, Space A.  wrote:
>>> >
>>> > "runtime type-casting"
>>> > "type safety something"
>>> > "boilerplate"
>>> > "amount of code"
>>> > "benefit something"
>>> > "greatly simplified" (for whom?)
>>> >
>>> > This topic has clearly shown that most people pro-generic have no
>>> *real world* problems that they struggle to solve, yet most of them don't
>>> even understand what *real world* problems are.
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CADKwOTek6rrfmMziuj5poy4hAZJ%3DHXsyp-FB96RdUvZ%2BncoJYA%40mail.gmail.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CADKwOTeXFD8WoGeS4H1OwXnu5N0f-LqcUBGJmUYiCj3BWACkTA%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Kevin Chadwick]

On 12/30/20 6:38 PM, Ian Lance Taylor wrote:
> I don't think this is accurate.  Surveys express a clear and
> consistent desire for generics that is far ahead of requests for
> operator overloading or other language features.  (To avoid
> misunderstanding I'll say again that changes to the Go language are
> not driven by polls.)

Firstly, I appreciate that dev is not driven by polls but it may be that
internally to Google these desires are true too. It is natural to be less likely
to get an honest answer from many employees, of course.

If Generics is something wanted by the designers without or little debate aside
from the form, then just say so and end the discussion?

One thing brought up in a recent thread is that a past user of Generics in other
languages has found over time he has changed his mind/bias and now prefers his
code without them.

The existence of generics in other languages has likely increased the chances of
this request. Familiarity bias.

Also, whilst understanding that voluntary submission has it's benefits in terms
of avoiding suggestion; that data has already been acquired. I wonder what the
result would be given a number of options. I probably can't think of many of the
good requests, so this could be fuelled by past submissions. I can't remember
hitting a null pointer in my code but certainly have in stdlib network libraries
(missing an & etc.)


Null pointer panic avoidance via automatic error return (what happened before
panics?)

enhanced Gomobile support

enhanced tinygo support

Generics

Flutter, Go cooperation

...

No changes


p.s.

Personally, whilst I respect that I need to account for my familiarity bias. I
feel that Go already has some small rough edges, due to influences and
familiarity bias from some largely frontend languages.

Thank You all for my favourite language and Happy New Year!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2fdc3328-b65a-9de3-b9ba-75e9973cc20b%40gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Martin Schnabel]

hi Space,

i do not care about this discussion in general and learned to trust the 
go developers to be thoughtful and reasonable.


i wouldn't write this normally, but in case you are not aware it might 
actually help: i did read the last couple of your messages to this list 
again and came to the conclusion that i would not want to enter into a 
discussion with you based on the general tone of your messages, 
regardless of argument or subject.


i don't mean any disrespect. the advice by Tyler is well meaning and 
will certainly be good to follow generally and by everyone:


"I think your arguments would gain quite a bit more traction on this 
list if you presented them in a more respectful way."


a good exercise would be to review your messages from a different point 
of view. read them as if addressed to you and decide whether you would 
want to reply yourself.


anyway, have a happy new year everyone!

On 31.12.20 13:55, Space A. wrote:

Hi,
ok, so please read it finally and tell which point exactly you think was 
against CoC and in what of my messages and in which exact thread, but do 
not put my words out of context. And explain why you responded just now, 
and to my message to a person who obviously *violated* its terms by 
aggressively turning to my personality.


Do you protect this aggressive behavior just because you pro-generics 
and silently hate everything I will say (and me personally)? Because if 
you do, it's quite stupid. But I hope it's not.



чт, 31 дек. 2020 г. в 07:51, Tyler Compton >:


Space A,

So switching from subject to my personality and telling me what
I should and what shouldn't, to whom to listen, and what to read
is something in line with "code of conduct" which you appeal as
the argument of last resort?


I've seen how you carry yourself on this list, and you really should
read the code of conduct. I think your arguments would gain quite a
bit more traction on this list if you presented them in a more
respectful way.

On Wed, Dec 30, 2020 at 3:47 PM Space A. mailto:reexist...@gmail.com>> wrote:

Nice.

 > You should listen to people who have been doing this much
longer than you
Thanks, are you sure you know for how long I've been doing
*this* to be able to compare?
 > before discarding all their points as "bullshit"
Have *you* actually read and listened because this is not what
I've said?
 > and you should probably review the community code of conduct
So switching from subject to my personality and telling me what
I should and what shouldn't, to whom to listen, and what to read
is something in line with "code of conduct" which you appeal as
the argument of last resort?


This was actually my first comment on this particular topic. So
yea, I read and listened before replying. I could have replied
to everyone and explained in detail, but I value the time of my
opponents. And my own time, tbh.


чт, 31 дек. 2020 г. в 00:03, David Riley mailto:fraveyd...@gmail.com>>:

This topic has shown little other than that a few people
here are unwilling to consider points of view other than
their own and declare that very real problems are not real.

You should listen to people who have been doing this much
longer than you have before discarding all their points as
"bullshit", and you should probably review the community
code of conduct.

If you've got nothing constructive to contribute, why bother?


- Dave


 > On Dec 30, 2020, at 3:53 PM, Space A.
mailto:reexist...@gmail.com>> wrote:
 >
 > "runtime type-casting"
 > "type safety something"
 > "boilerplate"
 > "amount of code"
 > "benefit something"
 > "greatly simplified" (for whom?)
 >
 > This topic has clearly shown that most people pro-generic
have no *real world* problems that they struggle to solve,
yet most of them don't even understand what *real world*
problems are.

-- 
You received this message because you are subscribed to the

Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to golang-nuts+unsubscr...@googlegroups.com
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/golang-nuts/CADKwOTek6rrfmMziuj5poy4hAZJ%3DHXsyp-FB96RdUvZ%2BncoJYA%40mail.gmail.com

.

--
You rec

Re: [go-nuts] Generics - please provide real life problems

[robert engels]

95% was a recalled-guess. I previously linked to an academic paper that studied 
uses of generics in Java, and I believe that was the number - regardless it was 
a very, very high percentage.

Interestingly, I had a previous client that was a case-study in generics gone 
wrong. No kidding, they had created Couple..Sextuple using generics, so you 
would read code that literally looked like this.

x = new 
Sextuple,Integer,Pair>,Boolean>

Then you would put these in a generic map… Ugh. Prior to generics no one would 
of thought of doing something like this - they would have declared concrete 
classes, and container wrappers - similar to Go.

I’ll state for the record again, I was originally very dismayed that Go did not 
offer generics - after developing with it for a while that is far less of an 
issue to me than the error handling. I think the generics can be reasonably 
better solved by external code generators and go:generate - there are 
alternatives to “generics” as a language change.

> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> Hi,
> 
> On Thu, Dec 31, 2020 at 8:59 AM wilk  > wrote:
> If 95% of generics are collections the current draft is overkill.
> What about a simplified version with only one generic type (like we do
> with interface{}), without constraint as long as it can compile ?
> 
> • "Only one generic type" means you can't write generic maps or graph 
> structures
> • "Without constraints" means compilation cost goes up significantly (as the 
> compiler needs to completely redo type-checking and compilation for each 
> instantiation - instead of only checking that the function adheres to the 
> constraints and the type-arguments fulfill it at each call-site. i.e. you 
> make an NxM problem out of an N+M problem). It also makes good error messages 
> very hard. And the constraints need to be documented anyway (in a comment, if 
> nothing else), so that the user knows how to call the function - might as 
> well have a standardized, machine-checkable way to express that.
> 
> So even *if* we only consider containers, the complexity of the design isn't 
> accidental. There are very concrete (and IMO important) advantages to these 
> decisions.
> 
> That being said, I also, personally, don't consider type-safe containers the 
> main use-case of generics. It's certainly *one*, and one that can't be solved 
> without them. I definitely see the advantage of being able to implement 
> complex data-structures like lock-free concurrent maps or sorted maps as a 
> library and use them in really performance-sensitive code-paths. But I also 
> feel that my concerns about generics mainly stem from experiences with Java 
> and C++ where *everything* was expressed in terms of abstract generic 
> containers and algorithms, cluttering the code and requiring you to 
> understand subtle differences between different implementations of the 
> implementations of the abstract versions. So, personally, I really hope 
> containers are *not* 95% of the use-case of generics. In fact, if type-safe 
> containers *where* 95% of the use-case, I would still be very much opposed to 
> adding generics - I don't think we really *need* type-safety for containers, 
> as we are usually very well aware of what's stored in them.
> 
> Personally, the main use-case for generics I see (and I want to emphasize 
> that everyone sees different use-cases as more or less important, depending 
> on what kind of code they write) is the ability for concurrency as a library. 
> I think channels and goroutines are great concurrency primitives - but they 
> are primitives, that need to be composed to be useful. And this composition 
> is usually very subtle and hard to get right. So being able to solve these 
> composition problems once and re-use that solution, seems very exciting to 
> me. But, again, that focus comes from the kind of code I write.
> 
> The third use-case I see for generics is to catch bugs by being able to 
> express more complicated type-invariants in code. An example of that would be 
> type-safety for context.Value 
>  (or, similarly 
> but subtly different, optional interfaces of http.ResponseWriter). However, 
> for this use-case, I personally don't see the value-add vs. complexity 
> tradeoff 
> 
>  as very favorable - the type-system needs a *lot* more power to catch 
> significantly more bugs and more power translates into a lot of complexity.
> I don't think the current draft lets us express very powerful invariants. And 
> while I wouldn't really advocate to make that a target, I think it would be 
> interesting to see more discussion of this area - i.e. more case-studies of 
> where Go has type-safety problems and if the current design can address them.
> 
> 
> func add(x, y GenericType) GenericType {
>   return x + y

Re: [go-nuts] Generics - please provide real life problems

['Axel Wagner' via golang-nuts]

On Thu, Dec 31, 2020 at 5:46 PM robert engels  wrote:

> I’ll state for the record again, I was originally very dismayed that Go
> did not offer generics - after developing with it for a while that is far
> less of an issue to me than the error handling.
>

Just to illustrate that the plural of "anecdote" isn't "data": I was
originally very vehemently opposed to generics in Go, but after using Go
for a bunch of years, I've been missing them often enough that I think they
provide a net-benefit (despite my criticism of this specific design).

Generics just isn't a "if you use Go long enough you learn they are not
important" thing.


> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> Hi,
>
> On Thu, Dec 31, 2020 at 8:59 AM wilk  wrote:
>
>> If 95% of generics are collections the current draft is overkill.
>> What about a simplified version with only one generic type (like we do
>> with interface{}), without constraint as long as it can compile ?
>>
>
> • "Only one generic type" means you can't write generic maps or graph
> structures
> • "Without constraints" means compilation cost goes up significantly (as
> the compiler needs to completely redo type-checking and compilation for
> each instantiation - instead of only checking that the function adheres to
> the constraints and the type-arguments fulfill it at each call-site. i.e.
> you make an NxM problem out of an N+M problem). It also makes good error
> messages very hard. And the constraints need to be documented anyway (in a
> comment, if nothing else), so that the user knows how to call the function
> - might as well have a standardized, machine-checkable way to express that.
>
> So even *if* we only consider containers, the complexity of the design
> isn't accidental. There are very concrete (and IMO important) advantages to
> these decisions.
>
> That being said, I also, personally, don't consider type-safe containers
> the main use-case of generics. It's certainly *one*, and one that can't be
> solved without them. I definitely see the advantage of being able to
> implement complex data-structures like lock-free concurrent maps or sorted
> maps as a library and use them in really performance-sensitive code-paths.
> But I also feel that my concerns about generics mainly stem from
> experiences with Java and C++ where *everything* was expressed in terms of
> abstract generic containers and algorithms, cluttering the code and
> requiring you to understand subtle differences between different
> implementations of the implementations of the abstract versions. So,
> personally, I really hope containers are *not* 95% of the use-case of
> generics. In fact, if type-safe containers *where* 95% of the use-case, I
> would still be very much opposed to adding generics - I don't think we
> really *need* type-safety for containers, as we are usually very well aware
> of what's stored in them.
>
> Personally, the main use-case for generics I see (and I want to emphasize
> that everyone sees different use-cases as more or less important, depending
> on what kind of code they write) is the ability for concurrency as a
> library. I think channels and goroutines are great concurrency primitives -
> but they are primitives, that need to be composed to be useful. And this
> composition is usually very subtle and hard to get right. So being able to
> solve these composition problems once and re-use that solution, seems very
> exciting to me. But, again, that focus comes from the kind of code I write.
>
> The third use-case I see for generics is to catch bugs by being able to
> express more complicated type-invariants in code. An example of that would
> be type-safety for context.Value
>  (or,
> similarly but subtly different, optional interfaces of
> http.ResponseWriter). However, for this use-case, I personally don't see the
>  value-add vs. complexity tradeoff
> 
>  as very favorable - the type-system needs a *lot* more power to catch
> significantly more bugs and more power translates into a lot of complexity.
> I don't think the current draft lets us express very powerful invariants.
> And while I wouldn't really advocate to make that a target, I think it
> would be interesting to see more discussion of this area - i.e. more
> case-studies of where Go has type-safety problems and if the current design
> can address them.
>
>
>> func add(x, y GenericType) GenericType {
>>   return x + y
>> }
>>
>> add(1,2) // add can compile : func add(x, y int) is generated
>> add("abc", "def") // can compile : func add(x, y string) is generated
>>
>> add(1, "abc") // two differents type : error
>>
>> GenericType will be like interface{} but instead of casting it'll
>> generate on the fly, at compile time the function with the type of each
>> functions call.
>> I believe it's too easy and i mis

Re: [go-nuts] Generics - please provide real life problems

[robert engels]

Go has been in existence for 10+ years and has fairly wide adoption in some 
areas - so it is not hard to make the case that generics are “not an important 
thing” - depends on what you are trying to do with it and what your perspective 
on “the right way” is.


> On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> On Thu, Dec 31, 2020 at 5:46 PM robert engels  > wrote:
> I’ll state for the record again, I was originally very dismayed that Go did 
> not offer generics - after developing with it for a while that is far less of 
> an issue to me than the error handling.
> 
> Just to illustrate that the plural of "anecdote" isn't "data": I was 
> originally very vehemently opposed to generics in Go, but after using Go for 
> a bunch of years, I've been missing them often enough that I think they 
> provide a net-benefit (despite my criticism of this specific design).
> 
> Generics just isn't a "if you use Go long enough you learn they are not 
> important" thing.
> 
> 
>> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts 
>> mailto:golang-nuts@googlegroups.com>> wrote:
>> 
>> Hi,
>> 
>> On Thu, Dec 31, 2020 at 8:59 AM wilk > > wrote:
>> If 95% of generics are collections the current draft is overkill.
>> What about a simplified version with only one generic type (like we do
>> with interface{}), without constraint as long as it can compile ?
>> 
>> • "Only one generic type" means you can't write generic maps or graph 
>> structures
>> • "Without constraints" means compilation cost goes up significantly (as the 
>> compiler needs to completely redo type-checking and compilation for each 
>> instantiation - instead of only checking that the function adheres to the 
>> constraints and the type-arguments fulfill it at each call-site. i.e. you 
>> make an NxM problem out of an N+M problem). It also makes good error 
>> messages very hard. And the constraints need to be documented anyway (in a 
>> comment, if nothing else), so that the user knows how to call the function - 
>> might as well have a standardized, machine-checkable way to express that.
>> 
>> So even *if* we only consider containers, the complexity of the design isn't 
>> accidental. There are very concrete (and IMO important) advantages to these 
>> decisions.
>> 
>> That being said, I also, personally, don't consider type-safe containers the 
>> main use-case of generics. It's certainly *one*, and one that can't be 
>> solved without them. I definitely see the advantage of being able to 
>> implement complex data-structures like lock-free concurrent maps or sorted 
>> maps as a library and use them in really performance-sensitive code-paths. 
>> But I also feel that my concerns about generics mainly stem from experiences 
>> with Java and C++ where *everything* was expressed in terms of abstract 
>> generic containers and algorithms, cluttering the code and requiring you to 
>> understand subtle differences between different implementations of the 
>> implementations of the abstract versions. So, personally, I really hope 
>> containers are *not* 95% of the use-case of generics. In fact, if type-safe 
>> containers *where* 95% of the use-case, I would still be very much opposed 
>> to adding generics - I don't think we really *need* type-safety for 
>> containers, as we are usually very well aware of what's stored in them.
>> 
>> Personally, the main use-case for generics I see (and I want to emphasize 
>> that everyone sees different use-cases as more or less important, depending 
>> on what kind of code they write) is the ability for concurrency as a 
>> library. I think channels and goroutines are great concurrency primitives - 
>> but they are primitives, that need to be composed to be useful. And this 
>> composition is usually very subtle and hard to get right. So being able to 
>> solve these composition problems once and re-use that solution, seems very 
>> exciting to me. But, again, that focus comes from the kind of code I write.
>> 
>> The third use-case I see for generics is to catch bugs by being able to 
>> express more complicated type-invariants in code. An example of that would 
>> be type-safety for context.Value 
>>  (or, similarly 
>> but subtly different, optional interfaces of http.ResponseWriter). However, 
>> for this use-case, I personally don't see the value-add vs. complexity 
>> tradeoff 
>> 
>>  as very favorable - the type-system needs a *lot* more power to catch 
>> significantly more bugs and more power translates into a lot of complexity.
>> I don't think the current draft lets us express very powerful invariants. 
>> And while I wouldn't really advocate to make that a target, I think it would 
>> be interesting to see more discussion of this area - i.e. more case-studies 
>> of where Go has 

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

> hi Space, 
Hey,

> i do not care about this discussion in general 
> i would not want to enter into a discussion with you 

So it's up to you, isn't it? Should I invite you? Or maybe anyone else 
should? I don't know you and don't care about your existence (as you said, 
I don't mean any disrespect, just a fact). I would say that in my 
experience whether you or anyone else enters a discussion depends on 
whether you have anything in mind, on the subject and appropriate 
arguments, or not. Interestingly, but nobody in this and adjacent thread 
who set him(-her)self against generics didn't attempt any personal attack. 
And in this thread you're 3rd person who have nothing to say in general, 
but a lot to say about me. =) Not knowing me at all, even my name. 

So have you read my comment, do you have any arguments regarding my point 
that most of people here who are pro-generics don't understand what *real 
world* problems are and not facing this class of problems? Lets' talk about 
this. All of this (copied):
> > "runtime type-casting" 
> > "type safety something" 
> > "boilerplate" 
> > "amount of code" 
> > "benefit something" 
> > "greatly simplified" (for whom?) 

translates to not more than just a simple implication that "generics are 
better". As simple as that. So the problems people trying to "solve" are a 
kind of very general, imaginary and ephemeral things like:
"generics are better than runtime"
"generics are better than interfaces"
"generics produces less code which is better"
"generics produces smarter code" (Clear is better than clever? No, never 
heard!)
 "generics gives better performance"
etc

and so one so forth. Which are just not correct.

*Not* *a* *single* *real* *world* *problem* in any of presented case. Did I 
miss one? Please point on it! So why shouldn't I or anyone else say it's a 
*bullshit* after all (but I didn't)? After all your attacks?

And all you can say: "i would not want to enter into a discussion with you 
based on the general tone of your messages, regardless of argument or 
subject ". 

Ok, do not.


четверг, 31 декабря 2020 г. в 17:58:24 UTC+3, mb0: 

> hi Space, 
>
> i do not care about this discussion in general and learned to trust the 
> go developers to be thoughtful and reasonable. 
>
> i wouldn't write this normally, but in case you are not aware it might 
> actually help: i did read the last couple of your messages to this list 
> again and came to the conclusion that i would not want to enter into a 
> discussion with you based on the general tone of your messages, 
> regardless of argument or subject. 
>
> i don't mean any disrespect. the advice by Tyler is well meaning and 
> will certainly be good to follow generally and by everyone: 
>
> "I think your arguments would gain quite a bit more traction on this 
> list if you presented them in a more respectful way." 
>
> a good exercise would be to review your messages from a different point 
> of view. read them as if addressed to you and decide whether you would 
> want to reply yourself. 
>
> anyway, have a happy new year everyone! 
>
> On 31.12.20 13:55, Space A. wrote: 
> > Hi, 
> > ok, so please read it finally and tell which point exactly you think was 
> > against CoC and in what of my messages and in which exact thread, but do 
> > not put my words out of context. And explain why you responded just now, 
> > and to my message to a person who obviously *violated* its terms by 
> > aggressively turning to my personality. 
> > 
> > Do you protect this aggressive behavior just because you pro-generics 
> > and silently hate everything I will say (and me personally)? Because if 
> > you do, it's quite stupid. But I hope it's not. 
> > 
> > 
> > чт, 31 дек. 2020 г. в 07:51, Tyler Compton  > >: 
> > 
> > Space A, 
> > 
> > So switching from subject to my personality and telling me what 
> > I should and what shouldn't, to whom to listen, and what to read 
> > is something in line with "code of conduct" which you appeal as 
> > the argument of last resort? 
> > 
> > 
> > I've seen how you carry yourself on this list, and you really should 
> > read the code of conduct. I think your arguments would gain quite a 
> > bit more traction on this list if you presented them in a more 
> > respectful way. 
> > 
> > On Wed, Dec 30, 2020 at 3:47 PM Space A.  > > wrote: 
> > 
> > Nice. 
> > 
> > > You should listen to people who have been doing this much 
> > longer than you 
> > Thanks, are you sure you know for how long I've been doing 
> > *this* to be able to compare? 
> > > before discarding all their points as "bullshit" 
> > Have *you* actually read and listened because this is not what 
> > I've said? 
> > > and you should probably review the community code of conduct 
> > So switching from subject to my personality and telling me what 
> > I should and what shouldn't, to whom to listen, and what to read 
> > is something in line with "code of conduct" whi

Re: [go-nuts] Generics - please provide real life problems

[roger peppe]

Here's one real life example that I came across recently.

I have a CRUD API that supports a bunch of different entity types. They all
support a superset of the same operations.
Each method represents a single HTTP call.

If the generics proposal was implemented, I'd be able to define a common
interface between them all.
Something like this:

type CRUD[Entity any] interface {
Find(ctx context.Context, filter Filter) ([]Entity, error)
FindOne(ctx context.Context, filter Filter) ([]Entity,
error)
Create(ctx context.Context, entity Entity) (Entity, error)
Update(ctx context.Context, entity Entity) (Entity, error)
Delete(ctx context.Context, id string) error
}

The Find operation allows the specification of a start-count window of
results to return.
It would be really nice to be able to define a generic function like this:

func FindAll[Entity any](api CRUD[Entity], filter Filter) ([]Entity,
error)

which would iterate return a slice of all the entities regardless of how
many underlying
calls to Find are needed.

Currently I can't easily do that. I could change the methods so that they
just returned interface
values instead of the respective entity types, but that would make the API
harder and more
error-prone to use. I could use reflection, but that code would be even
harder to read and maintain.

Currently I might end up using code generation, but that has its own issues
(I'd have to write
a code generator, or use some kind of template scheme, in which case the
actual source wouldn't
be amenable to gofmt and static checking).

  cheers,
rog.

On Thu, 24 Dec 2020 at 06:15, Martin Hanson 
wrote:

> I have been arguing passionately against adding generics to Go because
> I truly believe that it is going against the simplicity of Go and the
> philosophy behind the design of Go.
>
> I believe that the resilience of Go against unnecessary change is of
> vital importance. The experience provided by Ken Thompson, Rob Pike and
> Robert Griesemer in designing Go the way they did speaks for itself.
>
> I feel and believe it is of imperative importance to avoid adding things
> to Go that doesn't present a true and real life day-to-day problem
> and so far none of the examples the pro-generics camp has provided has
> been more than minor theoretical examples that do not present any real
> life problems.
>
> I therefore propose that the pro-generics camp provide real examples of
> problems they have faced that was such a big issue that it justifies
> adding generics to Go.
>
> If all we're presented are these small theoretical examples of sorting
> lists, etc., then clearly this is nothing but hype that needs to go
> away.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/19560461608790506%40sas1-75175cadc2b3.qloud-c.yandex.net
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJhgachY138vaOHWp90Zg6xV6QcqkTAhajGxXPCHWUQeaaz5kg%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Ian Lance Taylor]

On Thu, Dec 31, 2020 at 4:56 AM Space A.  wrote:
>
> ok, so please read it finally and tell which point exactly you think was 
> against CoC and in what of my messages and in which exact thread, but do not 
> put my words out of context. And explain why you responded just now, and to 
> my message to a person who obviously *violated* its terms by aggressively 
> turning to my personality.
>
> Do you protect this aggressive behavior just because you pro-generics and 
> silently hate everything I will say (and me personally)? Because if you do, 
> it's quite stupid. But I hope it's not.


Let's please take a step back and not try to litigate whether a
comment violates the Code of Conduct.

Please just always remember:  Be friendly.  Be charitable.  Be
respectful.  Criticize ideas, not people.  Even then, avoid saying
that ideas are "stupid."

Thanks.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVmUvCnkgK6yb%2BCxwYOf_M4Lc_YOAOnX7Wbvj8o03whbA%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Ian Lance Taylor]

On Thu, Dec 31, 2020 at 5:42 AM Kevin Chadwick  wrote:
>
> On 12/30/20 6:38 PM, Ian Lance Taylor wrote:
> > I don't think this is accurate.  Surveys express a clear and
> > consistent desire for generics that is far ahead of requests for
> > operator overloading or other language features.  (To avoid
> > misunderstanding I'll say again that changes to the Go language are
> > not driven by polls.)
>
> Firstly, I appreciate that dev is not driven by polls but it may be that
> internally to Google these desires are true too. It is natural to be less 
> likely
> to get an honest answer from many employees, of course.

I'm confident that Google employees are entirely willing to honestly
express their feelings about Go.  There is no company mandate to use
Go, or to like it.  (Of course I have no way to prove this.)  I
haven't seen any reason to think that Google employees are either more
or less likely to prefer adding generics to Go than people outside of
Google.  It's not necessarily obvious, but there are Google employees
on golang-nuts arguing that Go doesn't need generics.


> If Generics is something wanted by the designers without or little debate 
> aside
> from the form, then just say so and end the discussion?

I don't think it's that simple.  For a long time now the Go FAQ has
said "Generics are convenient but they come at a cost in complexity in
the type system and run-time. We haven't yet found a design that gives
value proportionate to the complexity, although we continue to think
about it."  What we are considering now is whether the current design
draft gives value proportionate to the complexity.  I like to think
that it does, but obviously I am biased.  And the only way to avoid
that bias is to open up the discussion to the community, which is what
we've been doing over the last couple of years.

In other words, sure, we could say "we want generics."  And I think
that for many of the language designers that is a true statement.  But
it's also true that we only want generics if the language can remain
sufficiently simple and easy to use.  So the bare statement "we want
generics" doesn't get us anywhere useful.  It doesn't end the
discussion.  It just starts it.


> Also, whilst understanding that voluntary submission has it's benefits in 
> terms
> of avoiding suggestion; that data has already been acquired. I wonder what the
> result would be given a number of options. I probably can't think of many of 
> the
> good requests, so this could be fuelled by past submissions. I can't remember
> hitting a null pointer in my code but certainly have in stdlib network 
> libraries
> (missing an & etc.)
>
>
> Null pointer panic avoidance via automatic error return (what happened before
> panics?)
>
> enhanced Gomobile support
>
> enhanced tinygo support
>
> Generics
>
> Flutter, Go cooperation
>
> ...
>
> No changes

These are all very different kinds of things.  For example, I think
it's a category error to think that working on generics somehow means
that we have worse Gomobile support.  To the best of my knowledge, the
people working on generics have never worked on Gomobile, and
vice-versa.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWBiPpMnzkAkfB2tb8VvTM8m1FyXVhHt6iRzv2Pyvfzew%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[da...@suarezhouse.net]

Real use cases have been provided it appears for both why generics can be 
good and how they can be used negligently (love the sextuple example BTW).  
I know many things in programming can be used the wrong way but does 
generics potentially cross a threshold where the writer should add an 
import to ensure that the writer is a "library" writer and not someone that 
doesn't understand the benefits?  

A simple import like unsafe that would be a "marker" (probably called 
something better) that would be sufficient to have new programmers not 
assume they should always use generics while enabling more advanced users 
to declare they are intentionally writing generic functions might be an 
easy middle ground. Potentially the marker may also enable some future 
optimizations.

Forgive me if that has already been suggested in a thread that I missed.  
If it has, would love to know why adding a marker as a way to maintain the 
simplicity that others fear will be lost was not something that makes sense 
here.   

Sincerely,
David

On Thursday, December 31, 2020 at 2:02:53 PM UTC-6 Ian Lance Taylor wrote:

> On Thu, Dec 31, 2020 at 5:42 AM Kevin Chadwick  wrote:
> >
> > On 12/30/20 6:38 PM, Ian Lance Taylor wrote:
> > > I don't think this is accurate. Surveys express a clear and
> > > consistent desire for generics that is far ahead of requests for
> > > operator overloading or other language features. (To avoid
> > > misunderstanding I'll say again that changes to the Go language are
> > > not driven by polls.)
> >
> > Firstly, I appreciate that dev is not driven by polls but it may be that
> > internally to Google these desires are true too. It is natural to be 
> less likely
> > to get an honest answer from many employees, of course.
>
> I'm confident that Google employees are entirely willing to honestly
> express their feelings about Go. There is no company mandate to use
> Go, or to like it. (Of course I have no way to prove this.) I
> haven't seen any reason to think that Google employees are either more
> or less likely to prefer adding generics to Go than people outside of
> Google. It's not necessarily obvious, but there are Google employees
> on golang-nuts arguing that Go doesn't need generics.
>
>
> > If Generics is something wanted by the designers without or little 
> debate aside
> > from the form, then just say so and end the discussion?
>
> I don't think it's that simple. For a long time now the Go FAQ has
> said "Generics are convenient but they come at a cost in complexity in
> the type system and run-time. We haven't yet found a design that gives
> value proportionate to the complexity, although we continue to think
> about it." What we are considering now is whether the current design
> draft gives value proportionate to the complexity. I like to think
> that it does, but obviously I am biased. And the only way to avoid
> that bias is to open up the discussion to the community, which is what
> we've been doing over the last couple of years.
>
> In other words, sure, we could say "we want generics." And I think
> that for many of the language designers that is a true statement. But
> it's also true that we only want generics if the language can remain
> sufficiently simple and easy to use. So the bare statement "we want
> generics" doesn't get us anywhere useful. It doesn't end the
> discussion. It just starts it.
>
>
> > Also, whilst understanding that voluntary submission has it's benefits 
> in terms
> > of avoiding suggestion; that data has already been acquired. I wonder 
> what the
> > result would be given a number of options. I probably can't think of 
> many of the
> > good requests, so this could be fuelled by past submissions. I can't 
> remember
> > hitting a null pointer in my code but certainly have in stdlib network 
> libraries
> > (missing an & etc.)
> >
> >
> > Null pointer panic avoidance via automatic error return (what happened 
> before
> > panics?)
> >
> > enhanced Gomobile support
> >
> > enhanced tinygo support
> >
> > Generics
> >
> > Flutter, Go cooperation
> >
> > ...
> >
> > No changes
>
> These are all very different kinds of things. For example, I think
> it's a category error to think that working on generics somehow means
> that we have worse Gomobile support. To the best of my knowledge, the
> people working on generics have never worked on Gomobile, and
> vice-versa.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/672538d4-d313-4e60-bc39-bbe56f0c401dn%40googlegroups.com.

Re: [go-nuts] Generics - please provide real life problems

[Wojciech S. Czarnecki]

Dnia 2020-12-31, o godz. 13:41:34
Kevin Chadwick  napisał(a):

> Thank You all for my favourite language and Happy New Year!

Happy New Year! 

Kevin, forgive me that I'd chosen your *nonpartisan* message to cool this 
particular thread
and insert here an announcement of the third way to Go generics, kinda [1].

For the web users [Signature Switch - third path to Go generics] thread link 
is: 
[1] https://groups.google.com/g/golang-nuts/c/dQ6TUxk5-Pc/m/aRu0vvD-CAAJ

Please read whole https://play.golang.org/p/Q1ry4KPoOOJ document before reply.

P.S. This message also goes via bcc to the some people who participated 
in this and former (Gene...away!) firehose threads - I would like to know your
opinion about and I hope no one would mind this one doubled mail :)
If you do mind - I kindly apologize for the inconvenience.

Thank you. And Happy New Year!


-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20210101004322.25e2a729%40xmint.

Re: [go-nuts] Generics - please provide real life problems

['Axel Wagner' via golang-nuts]

On Thu, Dec 31, 2020 at 6:51 PM robert engels  wrote:

> Go has been in existence for 10+ years and has fairly wide adoption in
> some areas - so it is not hard to make the case that generics are “not an
> important thing”
>

This has been brought up in That Other Thread, so let me copy what I said
there (you didn't respond to that particular point, even though you replied
to the E-Mail, so I assume you've already read it):

Of course, this doesn't answer how we'd have managed *with* them.

We did manage for decades without general purpose CPUs. We did manage for
several decades without functions, coroutines or hashtables. We did manage
for decades without portable programming languages or multi-tasking
operating systems. We managed for many decades without the internet or the
world wide web.

In hindsight, though,  "we managed so long without them" doesn't appear to
be a very convincing argument to not have them today.


> - depends on what you are trying to do with it and what your perspective
> on “the right way” is.
>

This seems to indicate some progress in mutual understanding - by saying
that it depends on what you do with the language, you seem to imply that
you understand that other people's use-case might benefit from generics. Am
I reading this correctly?


>
>
> On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> On Thu, Dec 31, 2020 at 5:46 PM robert engels 
> wrote:
>
>> I’ll state for the record again, I was originally very dismayed that Go
>> did not offer generics - after developing with it for a while that is far
>> less of an issue to me than the error handling.
>>
>
> Just to illustrate that the plural of "anecdote" isn't "data": I was
> originally very vehemently opposed to generics in Go, but after using Go
> for a bunch of years, I've been missing them often enough that I think they
> provide a net-benefit (despite my criticism of this specific design).
>
> Generics just isn't a "if you use Go long enough you learn they are not
> important" thing.
>
>
>> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>> Hi,
>>
>> On Thu, Dec 31, 2020 at 8:59 AM wilk  wrote:
>>
>>> If 95% of generics are collections the current draft is overkill.
>>> What about a simplified version with only one generic type (like we do
>>> with interface{}), without constraint as long as it can compile ?
>>>
>>
>> • "Only one generic type" means you can't write generic maps or graph
>> structures
>> • "Without constraints" means compilation cost goes up significantly (as
>> the compiler needs to completely redo type-checking and compilation for
>> each instantiation - instead of only checking that the function adheres to
>> the constraints and the type-arguments fulfill it at each call-site. i.e.
>> you make an NxM problem out of an N+M problem). It also makes good error
>> messages very hard. And the constraints need to be documented anyway (in a
>> comment, if nothing else), so that the user knows how to call the function
>> - might as well have a standardized, machine-checkable way to express that.
>>
>> So even *if* we only consider containers, the complexity of the design
>> isn't accidental. There are very concrete (and IMO important) advantages to
>> these decisions.
>>
>> That being said, I also, personally, don't consider type-safe containers
>> the main use-case of generics. It's certainly *one*, and one that can't be
>> solved without them. I definitely see the advantage of being able to
>> implement complex data-structures like lock-free concurrent maps or sorted
>> maps as a library and use them in really performance-sensitive code-paths.
>> But I also feel that my concerns about generics mainly stem from
>> experiences with Java and C++ where *everything* was expressed in terms of
>> abstract generic containers and algorithms, cluttering the code and
>> requiring you to understand subtle differences between different
>> implementations of the implementations of the abstract versions. So,
>> personally, I really hope containers are *not* 95% of the use-case of
>> generics. In fact, if type-safe containers *where* 95% of the use-case, I
>> would still be very much opposed to adding generics - I don't think we
>> really *need* type-safety for containers, as we are usually very well aware
>> of what's stored in them.
>>
>> Personally, the main use-case for generics I see (and I want to emphasize
>> that everyone sees different use-cases as more or less important, depending
>> on what kind of code they write) is the ability for concurrency as a
>> library. I think channels and goroutines are great concurrency primitives -
>> but they are primitives, that need to be composed to be useful. And this
>> composition is usually very subtle and hard to get right. So being able to
>> solve these composition problems once and re-use that solution, seems very
>> exciting to me. But, again, that focus comes fro

Re: [go-nuts] Generics - please provide real life problems

[Robert Engels]

Of course. But you don’t design a language (or any other product) for the 5% - 
you design it for the 95 (80?} percent - if you want you have customers/users 
and stay relevant (in business). 

> On Dec 31, 2020, at 8:39 PM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> 
>> On Thu, Dec 31, 2020 at 6:51 PM robert engels  wrote:
> 
>> Go has been in existence for 10+ years and has fairly wide adoption in some 
>> areas - so it is not hard to make the case that generics are “not an 
>> important thing”
> 
> This has been brought up in That Other Thread, so let me copy what I said 
> there (you didn't respond to that particular point, even though you replied 
> to the E-Mail, so I assume you've already read it):
> 
> Of course, this doesn't answer how we'd have managed *with* them.
> 
> We did manage for decades without general purpose CPUs. We did manage for 
> several decades without functions, coroutines or hashtables. We did manage 
> for decades without portable programming languages or multi-tasking operating 
> systems. We managed for many decades without the internet or the world wide 
> web.
> 
> In hindsight, though,  "we managed so long without them" doesn't appear to be 
> a very convincing argument to not have them today.
>  
>> - depends on what you are trying to do with it and what your perspective on 
>> “the right way” is.
> 
> This seems to indicate some progress in mutual understanding - by saying that 
> it depends on what you do with the language, you seem to imply that you 
> understand that other people's use-case might benefit from generics. Am I 
> reading this correctly?
>  
>> 
>> 
>>> On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts 
>>>  wrote:
>>> 
 On Thu, Dec 31, 2020 at 5:46 PM robert engels  
 wrote:
>>> 
 I’ll state for the record again, I was originally very dismayed that Go 
 did not offer generics - after developing with it for a while that is far 
 less of an issue to me than the error handling.
>>> 
>>> Just to illustrate that the plural of "anecdote" isn't "data": I was 
>>> originally very vehemently opposed to generics in Go, but after using Go 
>>> for a bunch of years, I've been missing them often enough that I think they 
>>> provide a net-benefit (despite my criticism of this specific design).
>>> 
>>> Generics just isn't a "if you use Go long enough you learn they are not 
>>> important" thing.
>>> 
 
> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> Hi,
> 
> On Thu, Dec 31, 2020 at 8:59 AM wilk  wrote:
>> If 95% of generics are collections the current draft is overkill.
>> What about a simplified version with only one generic type (like we do
>> with interface{}), without constraint as long as it can compile ?
> 
> • "Only one generic type" means you can't write generic maps or graph 
> structures
> • "Without constraints" means compilation cost goes up significantly (as 
> the compiler needs to completely redo type-checking and compilation for 
> each instantiation - instead of only checking that the function adheres 
> to the constraints and the type-arguments fulfill it at each call-site. 
> i.e. you make an NxM problem out of an N+M problem). It also makes good 
> error messages very hard. And the constraints need to be documented 
> anyway (in a comment, if nothing else), so that the user knows how to 
> call the function - might as well have a standardized, machine-checkable 
> way to express that.
> 
> So even *if* we only consider containers, the complexity of the design 
> isn't accidental. There are very concrete (and IMO important) advantages 
> to these decisions.
> 
> That being said, I also, personally, don't consider type-safe containers 
> the main use-case of generics. It's certainly *one*, and one that can't 
> be solved without them. I definitely see the advantage of being able to 
> implement complex data-structures like lock-free concurrent maps or 
> sorted maps as a library and use them in really performance-sensitive 
> code-paths. But I also feel that my concerns about generics mainly stem 
> from experiences with Java and C++ where *everything* was expressed in 
> terms of abstract generic containers and algorithms, cluttering the code 
> and requiring you to understand subtle differences between different 
> implementations of the implementations of the abstract versions. So, 
> personally, I really hope containers are *not* 95% of the use-case of 
> generics. In fact, if type-safe containers *where* 95% of the use-case, I 
> would still be very much opposed to adding generics - I don't think we 
> really *need* type-safety for containers, as we are usually very well 
> aware of what's stored in them.
> 
> Personally, the main use-case for generics I see (and I want to emphasize 
> that everyone sees 

Re: [go-nuts] Generics - please provide real life problems

['Axel Wagner' via golang-nuts]

On Fri, Jan 1, 2021 at 8:15 AM Robert Engels  wrote:

> Of course. But you don’t design a language (or any other product) for the
> 5% - you design it for the 95 (80?} percent - if you want you have
> customers/users and stay relevant (in business).
>

I take it. I don't have data to make quantitative statements, so I can't
argue whether or not generics are useful in 5%, or 25% or 90%.
But at least you and me seem to agree that there *are* real life use-cases
for generics (which is what this thread tried to call into question).



>
> On Dec 31, 2020, at 8:39 PM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> 
> On Thu, Dec 31, 2020 at 6:51 PM robert engels 
> wrote:
>
>> Go has been in existence for 10+ years and has fairly wide adoption in
>> some areas - so it is not hard to make the case that generics are “not an
>> important thing”
>>
>
> This has been brought up in That Other Thread, so let me copy what I said
> there (you didn't respond to that particular point, even though you replied
> to the E-Mail, so I assume you've already read it):
>
> Of course, this doesn't answer how we'd have managed *with* them.
>
> We did manage for decades without general purpose CPUs. We did manage for
> several decades without functions, coroutines or hashtables. We did manage
> for decades without portable programming languages or multi-tasking
> operating systems. We managed for many decades without the internet or the
> world wide web.
>
> In hindsight, though,  "we managed so long without them" doesn't appear to
> be a very convincing argument to not have them today.
>
>
>> - depends on what you are trying to do with it and what your perspective
>> on “the right way” is.
>>
>
> This seems to indicate some progress in mutual understanding - by saying
> that it depends on what you do with the language, you seem to imply that
> you understand that other people's use-case might benefit from generics. Am
> I reading this correctly?
>
>
>>
>>
>> On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>> On Thu, Dec 31, 2020 at 5:46 PM robert engels 
>> wrote:
>>
>>> I’ll state for the record again, I was originally very dismayed that Go
>>> did not offer generics - after developing with it for a while that is far
>>> less of an issue to me than the error handling.
>>>
>>
>> Just to illustrate that the plural of "anecdote" isn't "data": I was
>> originally very vehemently opposed to generics in Go, but after using Go
>> for a bunch of years, I've been missing them often enough that I think they
>> provide a net-benefit (despite my criticism of this specific design).
>>
>> Generics just isn't a "if you use Go long enough you learn they are not
>> important" thing.
>>
>>
>>> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
>>> Hi,
>>>
>>> On Thu, Dec 31, 2020 at 8:59 AM wilk  wrote:
>>>
 If 95% of generics are collections the current draft is overkill.
 What about a simplified version with only one generic type (like we do
 with interface{}), without constraint as long as it can compile ?

>>>
>>> • "Only one generic type" means you can't write generic maps or graph
>>> structures
>>> • "Without constraints" means compilation cost goes up significantly (as
>>> the compiler needs to completely redo type-checking and compilation for
>>> each instantiation - instead of only checking that the function adheres to
>>> the constraints and the type-arguments fulfill it at each call-site. i.e.
>>> you make an NxM problem out of an N+M problem). It also makes good error
>>> messages very hard. And the constraints need to be documented anyway (in a
>>> comment, if nothing else), so that the user knows how to call the function
>>> - might as well have a standardized, machine-checkable way to express that.
>>>
>>> So even *if* we only consider containers, the complexity of the design
>>> isn't accidental. There are very concrete (and IMO important) advantages to
>>> these decisions.
>>>
>>> That being said, I also, personally, don't consider type-safe containers
>>> the main use-case of generics. It's certainly *one*, and one that can't be
>>> solved without them. I definitely see the advantage of being able to
>>> implement complex data-structures like lock-free concurrent maps or sorted
>>> maps as a library and use them in really performance-sensitive code-paths.
>>> But I also feel that my concerns about generics mainly stem from
>>> experiences with Java and C++ where *everything* was expressed in terms of
>>> abstract generic containers and algorithms, cluttering the code and
>>> requiring you to understand subtle differences between different
>>> implementations of the implementations of the abstract versions. So,
>>> personally, I really hope containers are *not* 95% of the use-case of
>>> generics. In fact, if type-safe containers *where* 95% of the use-case, I
>>> would still 

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

You will always find use cases for anything even for absolutely useless
things. Because real life is full of paradoxes, and people are always
irrational. And you may be adding features again and again and you still
will have more to add. This way anything including programming language
becomes a bloated mess. So magic here is being able to say "stop". Code in
these bloated ecosystems over time becomes unreadable so that in many many
cases it's easier to rewrite even very complex applications with thousands
of man hours spent on, just from the scratch, than to try to read,
understand and improve it evolutionarily. That's the reality. On the other
hand Go has never been posed to benefit everyone. Covering each and every
use case is not in its values. "Less is exponentially more".

пт, 1 янв. 2021 г. в 13:24, 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com>:

> On Fri, Jan 1, 2021 at 8:15 AM Robert Engels 
> wrote:
>
>> Of course. But you don’t design a language (or any other product) for the
>> 5% - you design it for the 95 (80?} percent - if you want you have
>> customers/users and stay relevant (in business).
>>
>
> I take it. I don't have data to make quantitative statements, so I can't
> argue whether or not generics are useful in 5%, or 25% or 90%.
> But at least you and me seem to agree that there *are* real life use-cases
> for generics (which is what this thread tried to call into question).
>
>
>
>>
>> On Dec 31, 2020, at 8:39 PM, 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>> 
>> On Thu, Dec 31, 2020 at 6:51 PM robert engels 
>> wrote:
>>
>>> Go has been in existence for 10+ years and has fairly wide adoption in
>>> some areas - so it is not hard to make the case that generics are “not an
>>> important thing”
>>>
>>
>> This has been brought up in That Other Thread, so let me copy what I said
>> there (you didn't respond to that particular point, even though you replied
>> to the E-Mail, so I assume you've already read it):
>>
>> Of course, this doesn't answer how we'd have managed *with* them.
>>
>> We did manage for decades without general purpose CPUs. We did manage for
>> several decades without functions, coroutines or hashtables. We did manage
>> for decades without portable programming languages or multi-tasking
>> operating systems. We managed for many decades without the internet or the
>> world wide web.
>>
>> In hindsight, though,  "we managed so long without them" doesn't appear
>> to be a very convincing argument to not have them today.
>>
>>
>>> - depends on what you are trying to do with it and what your perspective
>>> on “the right way” is.
>>>
>>
>> This seems to indicate some progress in mutual understanding - by saying
>> that it depends on what you do with the language, you seem to imply that
>> you understand that other people's use-case might benefit from generics. Am
>> I reading this correctly?
>>
>>
>>>
>>>
>>> On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
>>> On Thu, Dec 31, 2020 at 5:46 PM robert engels 
>>> wrote:
>>>
 I’ll state for the record again, I was originally very dismayed that Go
 did not offer generics - after developing with it for a while that is far
 less of an issue to me than the error handling.

>>>
>>> Just to illustrate that the plural of "anecdote" isn't "data": I was
>>> originally very vehemently opposed to generics in Go, but after using Go
>>> for a bunch of years, I've been missing them often enough that I think they
>>> provide a net-benefit (despite my criticism of this specific design).
>>>
>>> Generics just isn't a "if you use Go long enough you learn they are not
>>> important" thing.
>>>
>>>
 On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts <
 golang-nuts@googlegroups.com> wrote:

 Hi,

 On Thu, Dec 31, 2020 at 8:59 AM wilk  wrote:

> If 95% of generics are collections the current draft is overkill.
> What about a simplified version with only one generic type (like we do
> with interface{}), without constraint as long as it can compile ?
>

 • "Only one generic type" means you can't write generic maps or graph
 structures
 • "Without constraints" means compilation cost goes up significantly
 (as the compiler needs to completely redo type-checking and compilation for
 each instantiation - instead of only checking that the function adheres to
 the constraints and the type-arguments fulfill it at each call-site. i.e.
 you make an NxM problem out of an N+M problem). It also makes good error
 messages very hard. And the constraints need to be documented anyway (in a
 comment, if nothing else), so that the user knows how to call the function
 - might as well have a standardized, machine-checkable way to express that.

 So even *if* we only consider containers, the complexity of the design
 isn't accidental. There are v

Re: [go-nuts] Generics - please provide real life problems

['Axel Wagner' via golang-nuts]

On Fri, Jan 1, 2021 at 2:14 PM Space A.  wrote:

> So magic here is being able to say "stop".
>

The real magic is being able to discern what the things are that can be
useful enough to justify their cost, not just to stop. Stopping is trivial
- you could just set the Go repository to archive mode and it will never
change again.

This thread, however, asserted that there are *no* real-world use-cases for
generics. That's clearly wrong. The next thread might try to instead make
the argument that there are not *enough* real-world use-cases. As I said, I
can't really argue about that, I'm lacking quantitative data. But I'm
looking forward to someone providing that.

Code in these bloated ecosystems over time becomes unreadable so that in
> many many cases it's easier to rewrite even very complex applications with
> thousands of man hours spent on, just from the scratch, than to try to
> read, understand and improve it evolutionarily. That's the reality. On the
> other hand Go has never been posed to benefit everyone. Covering each and
> every use case is not in its values. "Less is exponentially more".
>
> пт, 1 янв. 2021 г. в 13:24, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com>:
>
>> On Fri, Jan 1, 2021 at 8:15 AM Robert Engels 
>> wrote:
>>
>>> Of course. But you don’t design a language (or any other product) for
>>> the 5% - you design it for the 95 (80?} percent - if you want you have
>>> customers/users and stay relevant (in business).
>>>
>>
>> I take it. I don't have data to make quantitative statements, so I can't
>> argue whether or not generics are useful in 5%, or 25% or 90%.
>> But at least you and me seem to agree that there *are* real life
>> use-cases for generics (which is what this thread tried to call into
>> question).
>>
>>
>>
>>>
>>> On Dec 31, 2020, at 8:39 PM, 'Axel Wagner' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
>>> 
>>> On Thu, Dec 31, 2020 at 6:51 PM robert engels 
>>> wrote:
>>>
 Go has been in existence for 10+ years and has fairly wide adoption in
 some areas - so it is not hard to make the case that generics are “not an
 important thing”

>>>
>>> This has been brought up in That Other Thread, so let me copy what I
>>> said there (you didn't respond to that particular point, even though you
>>> replied to the E-Mail, so I assume you've already read it):
>>>
>>> Of course, this doesn't answer how we'd have managed *with* them.
>>>
>>> We did manage for decades without general purpose CPUs. We did manage
>>> for several decades without functions, coroutines or hashtables. We did
>>> manage for decades without portable programming languages or multi-tasking
>>> operating systems. We managed for many decades without the internet or the
>>> world wide web.
>>>
>>> In hindsight, though,  "we managed so long without them" doesn't appear
>>> to be a very convincing argument to not have them today.
>>>
>>>
 - depends on what you are trying to do with it and what your
 perspective on “the right way” is.

>>>
>>> This seems to indicate some progress in mutual understanding - by saying
>>> that it depends on what you do with the language, you seem to imply that
>>> you understand that other people's use-case might benefit from generics. Am
>>> I reading this correctly?
>>>
>>>


 On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts <
 golang-nuts@googlegroups.com> wrote:

 On Thu, Dec 31, 2020 at 5:46 PM robert engels 
 wrote:

> I’ll state for the record again, I was originally very dismayed that
> Go did not offer generics - after developing with it for a while that is
> far less of an issue to me than the error handling.
>

 Just to illustrate that the plural of "anecdote" isn't "data": I was
 originally very vehemently opposed to generics in Go, but after using Go
 for a bunch of years, I've been missing them often enough that I think they
 provide a net-benefit (despite my criticism of this specific design).

 Generics just isn't a "if you use Go long enough you learn they are not
 important" thing.


> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> Hi,
>
> On Thu, Dec 31, 2020 at 8:59 AM wilk  wrote:
>
>> If 95% of generics are collections the current draft is overkill.
>> What about a simplified version with only one generic type (like we do
>> with interface{}), without constraint as long as it can compile ?
>>
>
> • "Only one generic type" means you can't write generic maps or graph
> structures
> • "Without constraints" means compilation cost goes up significantly
> (as the compiler needs to completely redo type-checking and compilation 
> for
> each instantiation - instead of only checking that the function adheres to
> the constraints and the type-arguments fulfill it at each call-site. i

Re: [go-nuts] Generics - please provide real life problems

[Space A.]

> The real magic is being able to discern what the things are that can be
useful enough to justify their cost, not just to stop. Stopping is trivial
- you could just set the Go repository to archive mode and it will never
change again.
One of the key Go values is simplicity. Keeping langage spec relatively
small and code clean and readable. So if you justify from that angle you
should say stop to any form of generic programming.

> This thread, however, asserted that there are *no* real-world use-cases
for generics. That's clearly wrong. The next thread might try to instead
make the argument that there are not *enough* real-world use-cases. As I
said, I can't really argue about that, I'm lacking quantitative data. But
I'm looking forward to someone providing that.

There is no real world problem *in this thread*. That's true. However,
there are some in the universe, that's for sure. Even if there weren't you
could have always invented one. =) Problem is not in proving that, but that
generics will be used mostly to fight with ephemeral "interfaces are bad",
"we have a type safety problem" (what?), reducing amount of "repetitive"
code, abandoning "clear is better than clever" principle, and for infinite
micro optimizations for every single nanosecond.


пт, 1 янв. 2021 г. в 16:20, Axel Wagner :

> On Fri, Jan 1, 2021 at 2:14 PM Space A.  wrote:
>
>> So magic here is being able to say "stop".
>>
>
> The real magic is being able to discern what the things are that can be
> useful enough to justify their cost, not just to stop. Stopping is trivial
> - you could just set the Go repository to archive mode and it will never
> change again.
>
> This thread, however, asserted that there are *no* real-world use-cases
> for generics. That's clearly wrong. The next thread might try to instead
> make the argument that there are not *enough* real-world use-cases. As I
> said, I can't really argue about that, I'm lacking quantitative data. But
> I'm looking forward to someone providing that.
>
> Code in these bloated ecosystems over time becomes unreadable so that in
>> many many cases it's easier to rewrite even very complex applications with
>> thousands of man hours spent on, just from the scratch, than to try to
>> read, understand and improve it evolutionarily. That's the reality. On the
>> other hand Go has never been posed to benefit everyone. Covering each and
>> every use case is not in its values. "Less is exponentially more".
>>
>> пт, 1 янв. 2021 г. в 13:24, 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com>:
>>
>>> On Fri, Jan 1, 2021 at 8:15 AM Robert Engels 
>>> wrote:
>>>
 Of course. But you don’t design a language (or any other product) for
 the 5% - you design it for the 95 (80?} percent - if you want you have
 customers/users and stay relevant (in business).

>>>
>>> I take it. I don't have data to make quantitative statements, so I can't
>>> argue whether or not generics are useful in 5%, or 25% or 90%.
>>> But at least you and me seem to agree that there *are* real life
>>> use-cases for generics (which is what this thread tried to call into
>>> question).
>>>
>>>
>>>

 On Dec 31, 2020, at 8:39 PM, 'Axel Wagner' via golang-nuts <
 golang-nuts@googlegroups.com> wrote:

 
 On Thu, Dec 31, 2020 at 6:51 PM robert engels 
 wrote:

> Go has been in existence for 10+ years and has fairly wide adoption in
> some areas - so it is not hard to make the case that generics are “not an
> important thing”
>

 This has been brought up in That Other Thread, so let me copy what I
 said there (you didn't respond to that particular point, even though you
 replied to the E-Mail, so I assume you've already read it):

 Of course, this doesn't answer how we'd have managed *with* them.

 We did manage for decades without general purpose CPUs. We did manage
 for several decades without functions, coroutines or hashtables. We did
 manage for decades without portable programming languages or multi-tasking
 operating systems. We managed for many decades without the internet or the
 world wide web.

 In hindsight, though,  "we managed so long without them" doesn't appear
 to be a very convincing argument to not have them today.


> - depends on what you are trying to do with it and what your
> perspective on “the right way” is.
>

 This seems to indicate some progress in mutual understanding - by
 saying that it depends on what you do with the language, you seem to imply
 that you understand that other people's use-case might benefit from
 generics. Am I reading this correctly?


>
>
> On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> On Thu, Dec 31, 2020 at 5:46 PM robert engels 
> wrote:
>
>> I’ll state for the record again, I was originally very dismayed 

Re: [go-nuts] Generics - please provide real life problems

[David Riley]

On Dec 31, 2020, at 11:54 AM, 'Axel Wagner' via golang-nuts 
 wrote:
> 
> On Thu, Dec 31, 2020 at 5:46 PM robert engels  wrote:
> I’ll state for the record again, I was originally very dismayed that Go did 
> not offer generics - after developing with it for a while that is far less of 
> an issue to me than the error handling.
> 
> Just to illustrate that the plural of "anecdote" isn't "data": I was 
> originally very vehemently opposed to generics in Go, but after using Go for 
> a bunch of years, I've been missing them often enough that I think they 
> provide a net-benefit (despite my criticism of this specific design).
> 
> Generics just isn't a "if you use Go long enough you learn they are not 
> important" thing.

This is more or less my position on it as well.  From time to time, I find 
myself thinking "I could do this easier and more elegantly in C++", which is 
never a great place to be.  The lack of generics mostly causes me to create 
repeated, identical code for things that are almost the same (e.g. bitfield 
code for uint32 and uint64 variants) which is invariably more error prone and 
just isn't great.

I've been programming in C and C++ for about 25 years, which is not nearly as 
long as some people here, but it's enough to say that I understand the 
tradeoffs involved with preprocessor macros and templating.  C++ is not 
generally worth using without the STL, and Java usability was honestly greatly 
improved with the addition of generics (until this year, I hadn't done any 
serious Java work since before they were added, and I find myself liking it a 
lot better; recall that before generics, Java used an interface{}-like or void 
*-like approach with Object, which was not very fun).

I'm not going to waste any more time with the increasingly hostile folks who 
are denying the existence of real-world use cases in the face of real-world use 
cases, but I will gladly discuss the ways in which a generics scheme will make 
my real-world problems a lot smaller.


- Dave

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/67FC3C39-496B-4931-9789-61BFAC5D9777%40gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Henry]

I share some of the OP's concerns. At the moment, I am horrified at the 
syntax of some of the more advanced generics examples in the proposals, 
particularly when you throw contracts, methods and stuffs into the mix. 
There are just way too many brackets to my liking. In a typical IDEs, they 
use different colors, line breaks, and all sorts of guides to indicate 
which bracket belongs to which, because *brackets hinder readability*, 
especially when you have too many of them in a single line. Stop throwing 
more brackets.

I have no problem with the concept of generics itself, but I don't see a 
clean way to implement a full-blown generics into Go syntax-wise.
 
I prefer features to simplify writing generators. Generators not only solve 
generics problem, it also solves the need for macros, etc. 
On Friday, January 1, 2021 at 8:37:59 PM UTC+7 Space A. wrote:

> > The real magic is being able to discern what the things are that can be 
> useful enough to justify their cost, not just to stop. Stopping is trivial 
> - you could just set the Go repository to archive mode and it will never 
> change again. 
> One of the key Go values is simplicity. Keeping langage spec relatively 
> small and code clean and readable. So if you justify from that angle you 
> should say stop to any form of generic programming.
>
> > This thread, however, asserted that there are *no* real-world use-cases 
> for generics. That's clearly wrong. The next thread might try to instead 
> make the argument that there are not *enough* real-world use-cases. As I 
> said, I can't really argue about that, I'm lacking quantitative data. But 
> I'm looking forward to someone providing that. 
>
> There is no real world problem *in this thread*. That's true. However, 
> there are some in the universe, that's for sure. Even if there weren't you 
> could have always invented one. =) Problem is not in proving that, but that 
> generics will be used mostly to fight with ephemeral "interfaces are bad", 
> "we have a type safety problem" (what?), reducing amount of "repetitive" 
> code, abandoning "clear is better than clever" principle, and for infinite 
> micro optimizations for every single nanosecond. 
>
>
> пт, 1 янв. 2021 г. в 16:20, Axel Wagner :
>
>> On Fri, Jan 1, 2021 at 2:14 PM Space A.  wrote:
>>
>>> So magic here is being able to say "stop".
>>>
>>
>> The real magic is being able to discern what the things are that can be 
>> useful enough to justify their cost, not just to stop. Stopping is trivial 
>> - you could just set the Go repository to archive mode and it will never 
>> change again.
>>
>> This thread, however, asserted that there are *no* real-world use-cases 
>> for generics. That's clearly wrong. The next thread might try to instead 
>> make the argument that there are not *enough* real-world use-cases. As I 
>> said, I can't really argue about that, I'm lacking quantitative data. But 
>> I'm looking forward to someone providing that.
>>
>> Code in these bloated ecosystems over time becomes unreadable so that in 
>>> many many cases it's easier to rewrite even very complex applications with 
>>> thousands of man hours spent on, just from the scratch, than to try to 
>>> read, understand and improve it evolutionarily. That's the reality. On the 
>>> other hand Go has never been posed to benefit everyone. Covering each and 
>>> every use case is not in its values. "Less is exponentially more".
>>>
>>> пт, 1 янв. 2021 г. в 13:24, 'Axel Wagner' via golang-nuts <
>>> golan...@googlegroups.com>:
>>>
 On Fri, Jan 1, 2021 at 8:15 AM Robert Engels  
 wrote:

> Of course. But you don’t design a language (or any other product) for 
> the 5% - you design it for the 95 (80?} percent - if you want you have 
> customers/users and stay relevant (in business). 
>

 I take it. I don't have data to make quantitative statements, so I 
 can't argue whether or not generics are useful in 5%, or 25% or 90%.
 But at least you and me seem to agree that there *are* real life 
 use-cases for generics (which is what this thread tried to call into 
 question).

  

>
> On Dec 31, 2020, at 8:39 PM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
> 
> On Thu, Dec 31, 2020 at 6:51 PM robert engels  
> wrote:
>
>> Go has been in existence for 10+ years and has fairly wide adoption 
>> in some areas - so it is not hard to make the case that generics are 
>> “not 
>> an important thing”
>>
>
> This has been brought up in That Other Thread, so let me copy what I 
> said there (you didn't respond to that particular point, even though you 
> replied to the E-Mail, so I assume you've already read it):
>
> Of course, this doesn't answer how we'd have managed *with* them.
>
> We did manage for decades without general purpose CPUs. We did manage 
> for several decades without functions, coroutine

Re: [go-nuts] Generics - please provide real life problems

[robert engels]

100% - I use generics all the time in Java - but do these cases warrant the 
inclusion of generics in Go? There is more to that than use cases - which is 
why this thread is a bit misdirected. Go is strange in that way - it has a few 
built-in type safe containers that are very versatile. If these were more 
versatile then the number of generics use cases not covered really drops.

To Ian’s point, what if I could declare a map that had the semantics of a 
concurrent hash map without adding generics? I think something like this gives 
Go a leg up, rather than just making it “closer to Java” as some complain. Go’s 
“other containers (i.e. sync.Map)” are very similar to Java pre-generics - and 
better software engineers wrote wrappers then instead of dealing with 
interface{}/Object everywhere.

At the end of the day, I think the debate should be over and Go should add them 
in the next release. The sooner the better. Once it becomes part of the 
language people will learn it, use it, or not. Since it is backwards compatible 
I wouldn’t even wait for Go2. Sometimes the best thing to do is just move on 
and deal.

> On Jan 1, 2021, at 4:23 AM, 'Axel Wagner' via golang-nuts 
>  wrote:
> 
> On Fri, Jan 1, 2021 at 8:15 AM Robert Engels  > wrote:
> Of course. But you don’t design a language (or any other product) for the 5% 
> - you design it for the 95 (80?} percent - if you want you have 
> customers/users and stay relevant (in business). 
> 
> I take it. I don't have data to make quantitative statements, so I can't 
> argue whether or not generics are useful in 5%, or 25% or 90%.
> But at least you and me seem to agree that there *are* real life use-cases 
> for generics (which is what this thread tried to call into question).
> 
>  
> 
>> On Dec 31, 2020, at 8:39 PM, 'Axel Wagner' via golang-nuts 
>> mailto:golang-nuts@googlegroups.com>> wrote:
>> 
>> 
>> On Thu, Dec 31, 2020 at 6:51 PM robert engels > > wrote:
>> Go has been in existence for 10+ years and has fairly wide adoption in some 
>> areas - so it is not hard to make the case that generics are “not an 
>> important thing”
>> 
>> This has been brought up in That Other Thread, so let me copy what I said 
>> there (you didn't respond to that particular point, even though you replied 
>> to the E-Mail, so I assume you've already read it):
>> 
>> Of course, this doesn't answer how we'd have managed *with* them.
>> 
>> We did manage for decades without general purpose CPUs. We did manage for 
>> several decades without functions, coroutines or hashtables. We did manage 
>> for decades without portable programming languages or multi-tasking 
>> operating systems. We managed for many decades without the internet or the 
>> world wide web.
>> 
>> In hindsight, though,  "we managed so long without them" doesn't appear to 
>> be a very convincing argument to not have them today.
>>  
>> - depends on what you are trying to do with it and what your perspective on 
>> “the right way” is.
>> 
>> This seems to indicate some progress in mutual understanding - by saying 
>> that it depends on what you do with the language, you seem to imply that you 
>> understand that other people's use-case might benefit from generics. Am I 
>> reading this correctly?
>>  
>> 
>> 
>>> On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts 
>>> mailto:golang-nuts@googlegroups.com>> wrote:
>>> 
>>> On Thu, Dec 31, 2020 at 5:46 PM robert engels >> > wrote:
>>> I’ll state for the record again, I was originally very dismayed that Go did 
>>> not offer generics - after developing with it for a while that is far less 
>>> of an issue to me than the error handling.
>>> 
>>> Just to illustrate that the plural of "anecdote" isn't "data": I was 
>>> originally very vehemently opposed to generics in Go, but after using Go 
>>> for a bunch of years, I've been missing them often enough that I think they 
>>> provide a net-benefit (despite my criticism of this specific design).
>>> 
>>> Generics just isn't a "if you use Go long enough you learn they are not 
>>> important" thing.
>>> 
>>> 
 On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts 
 mailto:golang-nuts@googlegroups.com>> wrote:
 
 Hi,
 
 On Thu, Dec 31, 2020 at 8:59 AM wilk >>> > wrote:
 If 95% of generics are collections the current draft is overkill.
 What about a simplified version with only one generic type (like we do
 with interface{}), without constraint as long as it can compile ?
 
 • "Only one generic type" means you can't write generic maps or graph 
 structures
 • "Without constraints" means compilation cost goes up significantly (as 
 the compiler needs to completely redo type-checking and compilation for 
 each instantiation - instead of only checking that the function adheres to 
 the constraints and the type-arguments fulfill it at e

Re: [go-nuts] Generics - please provide real life problems

[Ian Lance Taylor]

On Fri, Jan 1, 2021 at 10:25 AM robert engels  wrote:
>
> To Ian’s point, what if I could declare a map that had the semantics of a 
> concurrent hash map without adding generics? I think something like this 
> gives Go a leg up, rather than just making it “closer to Java” as some 
> complain. Go’s “other containers (i.e. sync.Map)” are very similar to Java 
> pre-generics - and better software engineers wrote wrappers then instead of 
> dealing with interface{}/Object everywhere.

It's an interesting idea, and I've thought about it a lot.  But as far
as I can tell, it's a contradiction in terms.  The goal for
compile-time-type-safe containers is to be able to write the
implementation of a data structure such that the implementation is
independent of the types stored in that data structure.  And that is
the definition of generics: "Generic programming enables the
representation of algorithms and data structures in a generic form,
with concrete elements of the code (such as types) factored out."  We
can talk a lot about how to get there, but once we are there, no
matter what it looks like in the end, we will have implemented
generics.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXSganwnS-uKZkv8HcvHNPZd%3DMsVidwmVWAD5_OQ4TU0g%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[robert engels]

I was thinking more of an internal api - maybe stdlib authors only - writing 
code similar to map.go to create an alternate map type, and allow selecting of 
that map type in the make() call. It would be more difficult to write the 
collections implementation, and the methods available are fixed to the current 
Go map syntax - but I think it would address a large segment of the need for 
generics without adding generics. I think many of the other use cases can be 
dealt with using interfaces - maybe having many of them predeclared in the 
stdlib for consistency.

So then the issue becomes a purely technical one - how to write these 
implementations and have them integrated into the build.

> On Jan 1, 2021, at 2:18 PM, Ian Lance Taylor  wrote:
> 
> On Fri, Jan 1, 2021 at 10:25 AM robert engels  wrote:
>> 
>> To Ian’s point, what if I could declare a map that had the semantics of a 
>> concurrent hash map without adding generics? I think something like this 
>> gives Go a leg up, rather than just making it “closer to Java” as some 
>> complain. Go’s “other containers (i.e. sync.Map)” are very similar to Java 
>> pre-generics - and better software engineers wrote wrappers then instead of 
>> dealing with interface{}/Object everywhere.
> 
> It's an interesting idea, and I've thought about it a lot.  But as far
> as I can tell, it's a contradiction in terms.  The goal for
> compile-time-type-safe containers is to be able to write the
> implementation of a data structure such that the implementation is
> independent of the types stored in that data structure.  And that is
> the definition of generics: "Generic programming enables the
> representation of algorithms and data structures in a generic form,
> with concrete elements of the code (such as types) factored out."  We
> can talk a lot about how to get there, but once we are there, no
> matter what it looks like in the end, we will have implemented
> generics.
> 
> Ian
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXSganwnS-uKZkv8HcvHNPZd%3DMsVidwmVWAD5_OQ4TU0g%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3D94752F-7C5A-4643-8745-A96DB2E88E6B%40ix.netcom.com.

Re: [go-nuts] Generics - please provide real life problems

[Ian Lance Taylor]

On Fri, Jan 1, 2021 at 12:40 PM robert engels  wrote:
>
> I was thinking more of an internal api - maybe stdlib authors only - writing 
> code similar to map.go to create an alternate map type, and allow selecting 
> of that map type in the make() call. It would be more difficult to write the 
> collections implementation, and the methods available are fixed to the 
> current Go map syntax - but I think it would address a large segment of the 
> need for generics without adding generics. I think many of the other use 
> cases can be dealt with using interfaces - maybe having many of them 
> predeclared in the stdlib for consistency.
>
> So then the issue becomes a purely technical one - how to write these 
> implementations and have them integrated into the build.

Fair enough.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcX9TJXAPBeye5tHvLjaxddaKdctSKzWfzpuxWAUhndRBw%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[robert engels]

Thinking about this some more, I am not sure it is viable. Important 
operations, like “putIfAbsent” would not be possible with the current Go map 
syntax.

That being said, many of the Java collections interfaces declare “optional” 
methods, and I guess that could be used here. It would be easy to implement 
“putIfAbsent” with the standard map, and the standard map does have some 
methods - like len() - so maybe it’s possible. If the map implementation did 
not implement a method it would be a runtime panic().

> On Jan 1, 2021, at 2:40 PM, robert engels  wrote:
> 
> I was thinking more of an internal api - maybe stdlib authors only - writing 
> code similar to map.go to create an alternate map type, and allow selecting 
> of that map type in the make() call. It would be more difficult to write the 
> collections implementation, and the methods available are fixed to the 
> current Go map syntax - but I think it would address a large segment of the 
> need for generics without adding generics. I think many of the other use 
> cases can be dealt with using interfaces - maybe having many of them 
> predeclared in the stdlib for consistency.
> 
> So then the issue becomes a purely technical one - how to write these 
> implementations and have them integrated into the build.
> 
>> On Jan 1, 2021, at 2:18 PM, Ian Lance Taylor  wrote:
>> 
>> On Fri, Jan 1, 2021 at 10:25 AM robert engels  wrote:
>>> 
>>> To Ian’s point, what if I could declare a map that had the semantics of a 
>>> concurrent hash map without adding generics? I think something like this 
>>> gives Go a leg up, rather than just making it “closer to Java” as some 
>>> complain. Go’s “other containers (i.e. sync.Map)” are very similar to Java 
>>> pre-generics - and better software engineers wrote wrappers then instead of 
>>> dealing with interface{}/Object everywhere.
>> 
>> It's an interesting idea, and I've thought about it a lot.  But as far
>> as I can tell, it's a contradiction in terms.  The goal for
>> compile-time-type-safe containers is to be able to write the
>> implementation of a data structure such that the implementation is
>> independent of the types stored in that data structure.  And that is
>> the definition of generics: "Generic programming enables the
>> representation of algorithms and data structures in a generic form,
>> with concrete elements of the code (such as types) factored out."  We
>> can talk a lot about how to get there, but once we are there, no
>> matter what it looks like in the end, we will have implemented
>> generics.
>> 
>> Ian
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXSganwnS-uKZkv8HcvHNPZd%3DMsVidwmVWAD5_OQ4TU0g%40mail.gmail.com.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/B3A67E98-519D-493F-99F4-5FCC1ADBC9D9%40ix.netcom.com.

Re: [go-nuts] Generics - please provide real life problems

[Jesper Louis Andersen]

On Thu, Dec 31, 2020 at 9:45 PM da...@suarezhouse.net 
wrote:

> Real use cases have been provided it appears for both why generics can be
> good and how they can be used negligently (love the sextuple example BTW).


Some future language will invent the idea that you should be able to create
anonymous product types on the fly and use those as return values when you
want multiple return values. They'll even realize once you have anonymous
product types, every function just needs to take a single argument and
return a single argument, since you can just use an anonymous product type
(i.e., a tuple) if you want to pass multiple things. People will even
realize that when you compile this, you don't have to pass a pointer to
said tuple but can make a choice on calling convention which passes such
tuples in registers to speed up the system and be as fast as any other
language.

Then people will have reinvented Standard ML from 1991.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVJe_2L5QZ13v-SBZq2C7_e6nX8JDCAE23BcpWqGyH99Q%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[roger peppe]

FWIW I'm certain that the lack of tuples in Go was a very deliberate
decision - one of Go's more significant ancestors, Limbo, had tuples.
Anonymous product types have their disadvantages too (you don't get to name
the members, so code can end up significantly harder to understand), which
I suspect is why Go didn't get them.

> People will even realize that when you compile this, you don't have to
pass a pointer to said tuple but can make a choice on calling convention
which passes such tuples in registers to speed up the system and be as fast
as any other language.

I believe that the new register calling convention will do this for structs
FWIW.


On Sun, 3 Jan 2021 at 13:25, Jesper Louis Andersen <
jesper.louis.ander...@gmail.com> wrote:

>
> On Thu, Dec 31, 2020 at 9:45 PM da...@suarezhouse.net <
> da...@suarezhouse.net> wrote:
>
>> Real use cases have been provided it appears for both why generics can be
>> good and how they can be used negligently (love the sextuple example BTW).
>
>
> Some future language will invent the idea that you should be able to
> create anonymous product types on the fly and use those as return values
> when you want multiple return values. They'll even realize once you have
> anonymous product types, every function just needs to take a single
> argument and return a single argument, since you can just use an anonymous
> product type (i.e., a tuple) if you want to pass multiple things. People
> will even realize that when you compile this, you don't have to pass a
> pointer to said tuple but can make a choice on calling convention which
> passes such tuples in registers to speed up the system and be as fast as
> any other language.
>
> Then people will have reinvented Standard ML from 1991.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVJe_2L5QZ13v-SBZq2C7_e6nX8JDCAE23BcpWqGyH99Q%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJhgaci-M2iL%3DjPL2KB3BbhzRahBz4pjDUPjkiTAF_jjza6FAw%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[robert engels]

I do believe (hope) David was kidding. Anonymous product types (and similar 
constructs) are the root of all evil.

> On Jan 3, 2021, at 11:32 AM, roger peppe  wrote:
> 
> FWIW I'm certain that the lack of tuples in Go was a very deliberate decision 
> - one of Go's more significant ancestors, Limbo, had tuples.
> Anonymous product types have their disadvantages too (you don't get to name 
> the members, so code can end up significantly harder to understand), which I 
> suspect is why Go didn't get them.
> 
> > People will even realize that when you compile this, you don't have to pass 
> > a pointer to said tuple but can make a choice on calling convention which 
> > passes such tuples in registers to speed up the system and be as fast as 
> > any other language.
> 
> I believe that the new register calling convention will do this for structs 
> FWIW.
> 
> 
> On Sun, 3 Jan 2021 at 13:25, Jesper Louis Andersen 
> mailto:jesper.louis.ander...@gmail.com>> 
> wrote:
> 
> On Thu, Dec 31, 2020 at 9:45 PM da...@suarezhouse.net 
>   > wrote:
> Real use cases have been provided it appears for both why generics can be 
> good and how they can be used negligently (love the sextuple example BTW).
> 
> Some future language will invent the idea that you should be able to create 
> anonymous product types on the fly and use those as return values when you 
> want multiple return values. They'll even realize once you have anonymous 
> product types, every function just needs to take a single argument and return 
> a single argument, since you can just use an anonymous product type (i.e., a 
> tuple) if you want to pass multiple things. People will even realize that 
> when you compile this, you don't have to pass a pointer to said tuple but can 
> make a choice on calling convention which passes such tuples in registers to 
> speed up the system and be as fast as any other language.
> 
> Then people will have reinvented Standard ML from 1991.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiVJe_2L5QZ13v-SBZq2C7_e6nX8JDCAE23BcpWqGyH99Q%40mail.gmail.com
>  
> .
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAJhgaci-M2iL%3DjPL2KB3BbhzRahBz4pjDUPjkiTAF_jjza6FAw%40mail.gmail.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/E02530D4-7E72-4B1B-AE9A-A86E59F38A4C%40ix.netcom.com.

Re: [go-nuts] Generics - please provide real life problems

[Volker Dobler]

On Sunday, 3 January 2021 at 18:43:22 UTC+1 ren...@ix.netcom.com wrote:

> I do believe (hope) David was kidding. Anonymous product types (and 
> similar constructs) are the root of all evil.
>

Yes, you need dependent product types. Especially anonymous ones.
(Just be be clear: I _am_ kidding.)

V.
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/76956443-dd1e-4b4e-8207-1e991984b690n%40googlegroups.com.

Re: [go-nuts] Generics - please provide real life problems

[Jesper Louis Andersen]

On Sun, Jan 3, 2021 at 6:32 PM roger peppe  wrote:

> FWIW I'm certain that the lack of tuples in Go was a very deliberate
> decision - one of Go's more significant ancestors, Limbo, had tuples.
> Anonymous product types have their disadvantages too (you don't get to
> name the members, so code can end up significantly harder to understand),
> which I suspect is why Go didn't get them.
>
>
In a certain sense, Go already has anonymous product types! For instance:

func main() {
  x := struct{ a, b string }{"Hello", "playground"}
  fmt.Println(x)
}
Also, note we do get to name the members of said product members. In
Standard ML, a struct[0] is what you have in the core language and "tuples"
are more or less a syntactic sugar construction on top which decomposes
into structs. Fields are projection-accessed through their positions,
1,2,... In general I agree with you, and if you return multiple values from
a function it's important to name them. A good example is returning a
Public/Secret key-pair. Both tends to be byte-arrays of equal size, so the
types are the same and a user can easily mess them up. There are two ways
to solve that conundrum: either return a struct where the field names
describe what's in there, or mint new types so they can't be interchanged
(one can use phantom types here for added benefit).

There's an important development in the same general area of a programming
languages: row polymorphism. Here, we observe that if a function only
references certain fields in an anonymous struct, it doesn't matter if the
function gets called with a struct containing more fields. Getting this to
work is possible, though some of the resolution rules are quite unintuitive
(like subtyping in general, you tend to run into co-/contra-variance).

A good example of row polymorphism use is in the Elm programming language.
Web programming often requires you to "glue" different parts together and
Elm's "Extensible Records" are exactly row polymorphism. It allows the
programmer to build functions which only require a small part of a larger
structure to operate, and the larger structure to evolve independently of
the functions. It can remove a lot of the chore of going around and doing
type-level mechanical fixup[1]

> People will even realize that when you compile this, you don't have to
> pass a pointer to said tuple but can make a choice on calling convention
> which passes such tuples in registers to speed up the system and be as fast
> as any other language.
>
> I believe that the new register calling convention will do this for
> structs FWIW.
>
>
Yes! See above as to why. Structs are isomorphic to tuples if you mod out
naming.

[0] In Standard ML, they are called "records", though they are more or less
equivalent to structs.
[1] Essentially, this is what refactoring tools automate.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiV0pgf1dScxeuFHLbcxFEH26eOhffzEWwM2wR2%3DQFiHSQ%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Jesper Louis Andersen]

On Mon, Jan 4, 2021 at 9:20 AM Volker Dobler 
wrote:

> On Sunday, 3 January 2021 at 18:43:22 UTC+1 ren...@ix.netcom.com wrote:
>
>> I do believe (hope) David was kidding. Anonymous product types (and
>> similar constructs) are the root of all evil.
>>
>
> Yes, you need dependent product types. Especially anonymous ones.
>

Haha!

It would be quite the effort to add those. You need a partial evaluator for
your language in order to solve equality questions in the type system. The
slightly serious part though is that if you want to handle tensor algebras
correctly you are probably looking at either full dependent types or a
large subset thereof which works on arithmetic (I believe a lot of research
was done by Frank Pfenning and Hongwei Xi in the arithmetic-only area. Also
see the ATS language).

To be even more serious, you probably want the dual construction, namely
dependent sums. They generalize product types. There's a similarity of
those to Go's interfaces though with some subtle differences. Most
importantly, interfaces are "opaque" in that they only concern themselves
about behavior and not the actual underlying interface type. Whereas in a
dependent sum you have "transparency" in that you do get to access and
exploit the underlying type. For abstraction you want the opaqueness.


-- 
J.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiUeDRoet3DXNkwUQorJ8WD82Q16j3ZJLvPsmTK4A1kD6g%40mail.gmail.com.

Re: [go-nuts] Generics - please provide real life problems

[Howard C. Shaw III]

I posted two real world problems where Generics would be useful to me, 
earlier in the thread. Saw no response, and now continued claims that no 
real world problems have been provided? I'm not sure if that is 
disingenuous, or merely an artifact of the client someone is using causing 
replies that split the thread in some other people's clients so that not 
all the responses are visible, which resulted in an accusation of starting 
multiple threads that was hashed out a bit ago. 

The post was dated Dec 24, 2020, 12:50:53 PM. (CST)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2622f58c-9a78-43aa-9e7a-fea989faed87n%40googlegroups.com.