Generics - please provide real life problems

[Martin Hanson]

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.

[Ian Lance Taylor]

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

Ian

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

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

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

[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 <greenco...@yandex.com> 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...@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.

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

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

--

[wilk]

On 24-12-2020, Igor Cananea wrote:
> --0000000000009cfe9505b7311862
> Content-Type: text/plain; charset="UTF-8"

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

I like a lot how sort.Slice allow this. I did the same for all the need
of generics that I had.

--
wilk

[Axel Wagner]

On Thu, Dec 24, 2020 at 8:30 AM Martin Hanson <greenco...@yandex.com> 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...@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.

[Dan Kortschak]

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.

[wilk]

On 24-12-2020, Marcin Romaszewicz wrote:

> 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 :)

The only problem with Generics is when it will be abused. Maybe never,
how to know ?

The current draft has double sides. On one side it's really simple in the
way of Go, which is amazing for generic ! But on the other side,
because it'll be easy to use it can be abused.

--
wilk

[Sebastien Binet]

Like every other feature from Go.
Think channels and goroutines.
Or the reflect package. Or the unsafe one.
Or big large fat interfaces.
Or the empty interface.



-------- Original Message --------

--

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/rs1rb2%246mc%241%40ciao.gmane.io.

[wilk]

On 24-12-2020, Sebastien Binet wrote:
> This is a multi-part message in MIME format.
>
> --b1_GrUsz2qka8Vf9CMQa2ukahUpPKrwyxBqPmoLYzM
> Content-Type: text/plain; charset="UTF-8"

>
> Like every other feature from Go.
> Think channels and goroutines.
> Or the reflect package. Or the unsafe one.
> Or big large fat interfaces.
> Or the empty interface.

Yes. If generics will be used like that i believe it will not break the
simplicity and community of Go.

--
wilk

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

[K. Alex Mills]

On Thu, Dec 24, 2020, 1:18 AM 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.

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.

[Martin Hanson]

@Ian Lance Taylor, I feel I must apologize to you. I have just hunted
down every single mailing list post from you regarding the generics
issues and I have found that you have been extremely balanced and very
much protecting the Go philosophy and wanting to avoid any added
complexity etc.

I am sorry.

[Viktor Kojouharov]

>

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.

How about providing some evidence to back such an assertion, in  the same spirit of asking others to provide justification for the inclusion of generics. Belief should never be a justification criterion.

[Martin Hanson]

I have found this extremely useful (was posted on GitHub) and I post
this for any latecomers to this thread some time in the future:

https://github.com/golang/go/wiki/ExperienceReports#generics

Especially this document:

https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit

While I still believe that adding generics will increase complexity I
have an increased faith in the Go team that they will not, and have not
any time in the past, caved in to pressure and that if generics gets
added to Go, it is because they find a real usefulness for them, and
not just because of all the hype noise, and that they will provide a
solution with the least complexity.

I am sorry if I have offended anyone in these couple of threads, but I
feel strongly for leaving Go as Go is in order to prevent it from
getting convoluted like so many other languages.

[Howard C. Shaw III]

I do not have an example implemented with generics, but I do have examples that could use them. My renderview - https://github.com/TheGrum/renderview ; in particular this file: https://github.com/TheGrum/renderview/blob/master/renderparameter.go and my still unpublished audio library, visible in pre-release form in the processor.go file in https://github.com/TheGrum/rosarygen could both benefit from generics. Both have the pattern of having a struct that has multiple elements and a type flag, where only one of the elements will actually have a value at a time (though the struct that has that pattern in processor is not yet present in the rosarygen code). 

They certainly work, but they abandon compile-time type guarantees, dropping down to runtime type-casting. They are also brittle to extension. I can extend them, but it means adding cases to type-switches in certain bits of code. Someone using them as libraries could not do so very easily, or possibly at all.

[Ian Lance Taylor]

Thanks, but no need for an apology. I understand that people can
disagree for good reasons, and I don't take it personally.

Ian

[Tharaneedharan Vilwanathan]

Hi,

This is not a real life problem but I think this is a real life problem in the software industry and a problem for developers. I saw this for Swift (this is just an example):

https://github.com/raywenderlich/swift-algorithm-club

I was always wondering if Go can have something like this. One can just start using it. Absent generics, it is clumsy to provide a solution in Go like the one in the above link.

Does it make sense? Or am I missing something?

Regards

dharani

--
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/CAOyqgcXSTfERSeNPiBpSJAw28%3DqygeC5dHQrK_sz9ONOTWf-EA%40mail.gmail.com.

[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

[Reto]

You are repeatedly starting new threads, keeping the same subject as already existing ones.
Don't do that please, if you respond to a certain topic keep the thread intact.

That way all the conversation is in a single place.

[Martin Hanson]

> You are repeatedly starting new threads, keeping the same subject as already existing ones.
> Don't do that please, if you respond to a certain topic keep the thread intact.
>
> That way all the conversation is in a single place.

What are you on about!? This is my second post on this list, and even though both are about
generics, they are adequately different to be kept about otherwise it becomes a big mess.

This one is about life examples of problems generics solve, which many people has been very
kind to provide some really good examples of. Thanks all!

[Martin Hanson]

Your patience is inspiring! Thank you!

[Dan Kortschak]

On Fri, 2020-12-25 at 18:11 +0100, Martin Hanson wrote:
>
> What are you on about!? This is my second post on this list, and even
> though both are about
> generics, they are adequately different to be kept about otherwise it
> becomes a big mess.

Some mailers do not properly handle headers necessary for list
threading (providing a References: header to referred-to message). This
appears to be the case with the mailer(s) you are using; the two theads
that you are writing into appear as 5 on my mailer (this most recent
reply being it's own thread for example - it provided no references to
previous messages but should have referred to <
20201225130054....@feather.localdomain>).

[Jesper Louis Andersen]

On Thu, Dec 24, 2020 at 7:15 AM Martin Hanson <greenco...@yandex.com> 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.

[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, <greenco...@yandex.com> 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...@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.

[Jan Mercl]

On Sun, Dec 27, 2020 at 3:51 PM Jesper Louis Andersen
<jesper.lou...@gmail.com> 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?

[Oliver Smith]

What's the Big-O on determining whether N functions are

a/ identical,
b/ similar but expressing potentially unique behavior,
c/ subtly varied.

identical, assuming x and y have the same type:

    func (t *T) fX() bool {
      return t.x == t.z
    }
    func (t *T) fY() bool {
      return t.y == t.z
    }

similar but expressing potentially unique behavior:

    func (t *T) fA() bool {
      return t.A == 0
    }
    func (t *T) fB() bool {

      return t.B == false

    }
    func (t *T) fC() bool {
      return t.C == 0.0
    }

subtly varied:

    func (t *T) fU() bool {
      return t.U == 0
    }
    func (t *T) fV() bool {
      return t.V < E

    }

Sure. For 2-3 functions this is easy enough. But if when you need to handle each of bool, int8, uint8, int16, uint16, float32, int32, uint32, float64, int64, and uint64 you have 11 functions to compare. What if you have to repeat them for 5 structs? What if you have to also handle pointer-to cases?

Some years ago, I had the "pleasure" of reducing over 30,nnn lines of C 'specializations' of AVL trees with somewhere over 5nn lines of macro and 7nn lines of instantiation. And then 6 months later replacing the ~1500 remaining lines with ~320 lines of a templated C++ class.

The macro version found 17 cases where a c&p error, typo or unmaintained correlation was resulting in undefined behavior that was causing flakiness; the C++ version version ended up giving a 30% performance gain (if the C version used 130 cycles, the C++ version might use only 100).

In a more recent codebase, cognitive load and code-as-documentation had resulted in a decoupling of rationale for why a particular cast was taking place. It was entirely reasonable for other engineers to simply see it as part of the interface.

The reality was that the original engineer had been forced to specify a type for the sake of specifying a type to describe an operation (store value). They'd committed a type-choice based on the last state of the code during their testing, which was based on a log api.

It then became the type used by every clone of the same function required to support varied types (there were 16 put and 16 get functions).

This cast was mostly harmless, but it had used up about 200 engineer hours just in the last 6 months because the side-effect was "flaky" (actually deterministic, it just depended on the exact numbers given).

https://play.golang.org/p/p8_dUOLOpsT

So, instead of a bunch of unique functions or a collection of type switches, you can simply write as close to:

    dst.value = dst.value.cast(src.value)

or

    if dst.value.(type) == src.value.(type) { dst.value = src.value } else { panic("you're nuts") }

as possible. Now both the compiler and the human reader can tell what you actually meant rather than reverse engineering it from dozens of lines of code.

-Oliver

[Hein Meling]

Here is another example.
I haven’t worked out the details yet, but I envision that I can avoid generating this QuorumSpec interface in our Gorums framework: https://github.com/relab/gorums/blob/master/cmd/protoc-gen-gorums/dev/zorums_qspec_gorums.pb.go

And instead use generics... I hope that this can reduce the amount generated code, which is also inflexible.

I think there are plenty of important cases that will see improved type safety and reduce the fragility of code bases.

Best,

:) Hein

[Jesper Louis Andersen]

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.

[Jan Mercl]

On Wed, Dec 30, 2020 at 3:09 PM Jesper Louis Andersen
<jesper.lou...@gmail.com> 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.

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

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

[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

[Jan Mercl]

On Wed, Dec 30, 2020 at 7:38 PM Ian Lance Taylor <ia...@golang.org> 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.

[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:

[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

[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 <frave...@gmail.com>:

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

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

[Amnon]

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

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

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/483c3f92-097e-4954-b4df-135b6ab561e4n%40googlegroups.com.

[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 <greenco...@yandex.com> 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...@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.

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

--
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/CADKwOTek6rrfmMziuj5poy4hAZJ%3DHXsyp-FB96RdUvZ%2BncoJYA%40mail.gmail.com.

[wilk]

On 30-12-2020, robert engels wrote:
>
> --Apple-Mail=_053BD88E-EE7F-423A-AE3D-712B500390F8
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain; charset="UTF-8"
>
> Agreed.
>
> I had proposed a different approach, where the built-in map and slice could=
> have alternative implementations chosen during make(). 95% of generics usa=
> ge 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 =E2=80=
>=9Cdifficult". Bad programmers write bad code without generics.

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 ?

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 miss something already discussed...

--
wilk

[Axel Wagner]

Hi,

On Thu, Dec 31, 2020 at 8:59 AM wilk <wi...@flibuste.net> 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 miss something already discussed...

--
wilk

--
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/rsk0bb%24tg6%241%40ciao.gmane.io.

[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 <xav...@gmail.com>:

[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!

[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 <xav...@gmail.com

> <mailto:xav...@gmail.com>>:

> <mailto:frave...@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.

> <reexi...@gmail.com <mailto:reexi...@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...@googlegroups.com

> <mailto:golang-nuts...@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

> <https://groups.google.com/d/msgid/golang-nuts/CADKwOTek6rrfmMziuj5poy4hAZJ%3DHXsyp-FB96RdUvZ%2BncoJYA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

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

> <mailto:golang-nuts...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/golang-nuts/CADKwOTeXFD8WoGeS4H1OwXnu5N0f-LqcUBGJmUYiCj3BWACkTA%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CADKwOTeXFD8WoGeS4H1OwXnu5N0f-LqcUBGJmUYiCj3BWACkTA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[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<Long,Long,Map<Long,String>,Integer,Pair<String,Map<Long,Long>>,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.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGDOqWgEE2a_B9%2BqXftPc6ebBPcs_DcpsrqOvR%2BpCZ9SQ%40mail.gmail.com.

[Axel Wagner]

On Thu, Dec 31, 2020 at 5:46 PM robert engels <ren...@ix.netcom.com> 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.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFp0ozY5BAUudH-upa7neRjdtUQ%2Bk-o-%2BGox0q0%2BhJwEQ%40mail.gmail.com.

[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!)

<nobody told but I'm expecting this> "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:

[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 <greenco...@yandex.com> 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...@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.

[Ian Lance Taylor]

On Thu, Dec 31, 2020 at 4:56 AM Space A. <reexi...@gmail.com> 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

[Ian Lance Taylor]

On Thu, Dec 31, 2020 at 5:42 AM Kevin Chadwick <m8il...@gmail.com> 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

[Alex Besogonov]

On Wednesday, December 23, 2020 at 10:16:00 PM UTC-8 Martin Hanson wrote:

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.

My personal example: ordered containers. My code works with physical simulations and it needs to be fully deterministic. This means that I can't use simple maps because their iteration order is random (on purpose!).

As a result, a lot of my code looked like this:

struct ElectricNode {

    ChildrenList []ResistiveNode

    ChildrenMap map[string]ResistiveNode

};

When I wanted to remove an element I have to write something like:

newList := make([]ResistiveNode, len(node.ChildrenList)-1)

for _, i := range node.ChildrenList {

   if i.Name != nameToRemove {

      newList = append(newList, i);

   }

}

node.ChildrenList = newList

delete(node.ChildrenMap, nameToRemove);

I had a couple of reflective helpers that did this work through reflection, but it was not clean and had broken more than once during refactorings. I actually gave up on Go for this project and rewrote it in Python, resulting in 10x (ten times) less lines of code.

[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

[Wojciech S. Czarnecki]

Dnia 2020-12-31, o godz. 13:41:34
Kevin Chadwick <m8il...@gmail.com> 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

[Axel Wagner]

On Thu, Dec 31, 2020 at 6:51 PM robert engels <ren...@ix.netcom.com> 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?

[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 <golan...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF1g1J9gD%2Bz3A%2Bsw-Qf5gkT81uK%2BMiXiAvGZyo_zhLjYA%40mail.gmail.com.

[wilk]

On 31-12-2020, Alex Besogonov wrote:

> I had a couple of reflective helpers that did this work through reflection,
> but it was not clean and had broken more than once during refactorings. I
> actually gave up on Go for this project and rewrote it in Python, resulting
> in 10x (ten times) less lines of code.

The question is not how many lines of code to start but how to maintain
this code.
I found myself playing a lot with the magical possibilities of Python to
have very concise code but after years they become completely impossible
Maintain!

That said, i don't say that for your example, i can see where generics
will help to have maintainable code... Two sides...

I believe we have to choose where to put the cursor between the minimum
of generics possibilities for the maximum maintainability...

--
wilk

[Axel Wagner]

On Fri, Jan 1, 2021 at 8:15 AM Robert Engels <ren...@ix.netcom.com> 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).

[Markus Heukelom]

>> On Thursday, December 31, 2020 at 11:27:06 AM UTC+1 axel.wa...@googlemail.com wrote:

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

One thing that comes to mind that is not supported by the current proposal is the ability to express that T must be (any) struct. For example, I have a ORM function that scans a sql row into a struct (using reflection in its implementation):

// dest must be a pointer to a struct or an error is returned 

func ScanIntoStruct(row *sql.Row, dest interface{})  error {}

If you could somehow express that dest must be a pointer to a struct I could move one type of runtime-error into a compile-time error type (i.e. the purpose of generics):

// sketch code

func ScanIntoStruct[S struct](row *sql.Row, dest *S)  // NOTE: implementation still calls an internal function that is not generic and uses reflection 

Another example is where you write a library that creates an RPC service from any function that you provide:

func ExposeAsRPC[T func](name string, f T) {}

Again, this would then prevent ExposeASPRC to be called with anything but a function. Note however that the signature of f could be anything. This would be helpful to if you want to expose a Go function in a scripting language etc. 

I am not saying this a big "type-safey" problem, just an example of something I have encountered. 

On the other hand, I don't see a lot of cases myself where I would want to call some method on T in a generic function, mainly because there's already interfaces and helper function for this in Go if you need it.  For example, you could say that a generic priority queue must call a method Priority() on T, but that could be done in an equally type-safe way by asking for a helper function to be provided with T (ie. func (T) int) with the container.  There's the graph example in the generics proposal but I think that that can have a likewise type-safe solution that doesn't need the ability to call a method on T.  

On the other hand I agree that an "interface" in its meaning of a "declaration of a method set" applies equally well to compile time and runtime. So the current argument is (I think) that generics is just the application of interfaces at compile time instead of runtime. The issue I have with this is that it complicates (at least) the language around the concept of "interface" at lot (just think about all the documentation around interface that needs to be rewritten, and if someone asks a question on a interface you first need to address if it's used runtime or compile time, etc). A second issue is that, in my opinion, it does not agree very well with the idea of "one way of doing things" / orthogonality in Go (as explained above). 

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

The context.Value example is maybe an example of something that to me feels (at least initially) as a suspicious application of generics. If context.Context is made generic (if this is what is meant) then all functions that use it, such as in the sql package, are forced to be generic too:

    func (c *Conn) QueryContext[T any](ctx context.Context[T], query string, args ...interface{}) (*Rows, error)

Before you know it everything is generic.... On the other hand,  maybe this is something that you just need to get used to and be very happy with after. My initial reaction would be that the right choice here would be to make context not generic as Value is only a "extra" customer user value that is not part of its main functionality/purpose. However, it would possibly be tempting to factor interface{} into a T if you don't think too much about it.

-Markus

[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 <golan...@googlegroups.com>:

You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/bj6kMQBTqUY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGgD6C5T5qh747pEwzy1mjmGToYZj2jEE8koMckPk0vNA%40mail.gmail.com.

[Axel Wagner]

Hi,

On Fri, Jan 1, 2021 at 1:41 PM Markus Heukelom <markus....@gain.pro> wrote:

One thing that comes to mind that is not supported by the current proposal is the ability to express that T must be (any) struct. 

[…]

Another example is where you write a library that creates an RPC service from any function that you provide:

Personally, given that in both of these cases you still need to use `reflect` and there's still a lot of type-errors that can happen, I feel the wins here are relatively minor. There definitely are some and if they could be added more or less "for free", I'd definitely support that. But I don't see, personally, how that could be done.

As an example, a similar case is expressing that an argument must be a pointer - for example, for json.Unmarshal. It has a similar level of benefit (json.Unmarshal also still needs to use reflect to actually set fields or values) - but in that case, there is already a "free" way to achieve it with the design (that is, use `func Unmarshal[type T any](b []byte, p *T) error`).

 

On the other hand, I don't see a lot of cases myself where I would want to call some method on T in a generic function, mainly because there's already interfaces and helper function for this in Go if you need it.  For example, you could say that a generic priority queue must call a method Priority() on T, but that could be done in an equally type-safe way by asking for a helper function to be provided with T (ie. func (T) int) with the container.  There's the graph example in the generics proposal but I think that that can have a likewise type-safe solution that doesn't need the ability to call a method on T.

You could argue, that you don't actually *need* methods or interfaces at all. Instead of passing an `io.Reader`, you could pass a `func(p []byte) (int, error)`. And instead of passing an `io.ReadCloser` you could pass that func and a `func() error`. At the end of the day, an interface is just a table of functions.

But I hope we can agree that the method and interface mechanism provide a convenient way to package up data and code in a way usable by the callee.

On the other hand I agree that an "interface" in its meaning of a "declaration of a method set" applies equally well to compile time and runtime. So the current argument is (I think) that generics is just the application of interfaces at compile time instead of runtime.

I think the argument is rather "we want a way to constrain types and interfaces already provide a familiar way to express such constraints".

It's just about re-using a familiar mechanic, instead of introducing a new one (in fact, the previous incarnation of contracts *would* have introduced a new mechanic and that was one of the main criticisms of it).

 

The issue I have with this is that it complicates (at least) the language around the concept of "interface" at lot (just think about all the documentation around interface that needs to be rewritten, and if someone asks a question on a interface you first need to address if it's used runtime or compile time, etc).

I do think interfaces change, but only to accommodate type-lists. I'm not a huge fan of that aspect of the design myself.

I don't think the documentation around interfaces need to change at all apart from that. Their usage to express constraints is quite orthogonal to their usage as types and personally, I don't predict much confusion happening around that.

 

A second issue is that, in my opinion, it does not agree very well with the idea of "one way of doing things" / orthogonality in Go (as explained above). 

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

The context.Value example is maybe an example of something that to me feels (at least initially) as a suspicious application of generics. If context.Context is made generic (if this is what is meant) then all functions that use it, such as in the sql package, are forced to be generic too:

    func (c *Conn) QueryContext[T any](ctx context.Context[T], query string, args ...interface{}) (*Rows, error)

Before you know it everything is generic.... On the other hand,  maybe this is something that you just need to get used to and be very happy with after. My initial reaction would be that the right choice here would be to make context not generic as Value is only a "extra" customer user value that is not part of its main functionality/purpose. However, it would possibly be tempting to factor interface{} into a T if you don't think too much about it.

I definitely agree that, especially as I presented it, Context.Value is not a good use of generics. I was really just interested in exploring the possibility, to come to that conclusion. Context.Value is widely criticized as not being type-safe and generics are widely advertised as solving type-safety issues - so I thought it would be useful, to look at the costs involved in using generics to solve a type-safety issue (that isn't just limited to containers).

 

My general feeling, right now, is that there aren't a lot of type-safety issues generics (or at least this generics design) *can* solve, that aren't containers or generic algorithms (as in "things you'd find in an algorithms text book"). But I'd be interested to be proven wrong :)

-Markus

--
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/28dfab48-9413-4658-9272-bcc79f73153fn%40googlegroups.com.

[Axel Wagner]

On Fri, Jan 1, 2021 at 2:14 PM Space A. <reexi...@gmail.com> 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.

[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 <axel.wa...@googlemail.com>:

[David Riley]

On Dec 31, 2020, at 11:54 AM, 'Axel Wagner' via golang-nuts <golan...@googlegroups.com> wrote:
>
> On Thu, Dec 31, 2020 at 5:46 PM robert engels <ren...@ix.netcom.com> 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

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

[Markus Heukelom]

On Fri, Jan 1, 2021 at 2:16 PM Axel Wagner <axel.wa...@googlemail.com> wrote:

Hi,

On Fri, Jan 1, 2021 at 1:41 PM Markus Heukelom <markus....@gain.pro> wrote:

One thing that comes to mind that is not supported by the current proposal is the ability to express that T must be (any) struct. 

[…]

Another example is where you write a library that creates an RPC service from any function that you provide:

Personally, given that in both of these cases you still need to use `reflect` and there's still a lot of type-errors that can happen, I feel the wins here are relatively minor. There definitely are some and if they could be added more or less "for free", I'd definitely support that. But I don't see, personally, how that could be done.

As an example, a similar case is expressing that an argument must be a pointer - for example, for json.Unmarshal. It has a similar level of benefit (json.Unmarshal also still needs to use reflect to actually set fields or values) - but in that case, there is already a "free" way to achieve it with the design (that is, use `func Unmarshal[type T any](b []byte, p *T) error`).

 

On the other hand, I don't see a lot of cases myself where I would want to call some method on T in a generic function, mainly because there's already interfaces and helper function for this in Go if you need it.  For example, you could say that a generic priority queue must call a method Priority() on T, but that could be done in an equally type-safe way by asking for a helper function to be provided with T (ie. func (T) int) with the container.  There's the graph example in the generics proposal but I think that that can have a likewise type-safe solution that doesn't need the ability to call a method on T.

You could argue, that you don't actually *need* methods or interfaces at all. Instead of passing an `io.Reader`, you could pass a `func(p []byte) (int, error)`. And instead of passing an `io.ReadCloser` you could pass that func and a `func() error`. At the end of the day, an interface is just a table of functions.

That's true (although an interface is more than a table of functions: it  also a value and type pointer tuple at runtime - ie. you can use it as a variant  etc.). My argument is that for generics it is -possibly- not that inconvenient to go without methods (i.e. most of the benefit lies elsewhere). Yes, it can be convenient or elegant in some cases but it comes with quite high cost (in my view) wrt complicating the interface concept with little benefit to type-safety (as opposed to generics in itself).  It is more complicated because  now you also need to understand sum-types and that methods are not allowed if you have a type list etc etc. This in addition to understanding the mechanics when interfaces can be nil (think  of the pointer pit fall etc) and how to use type assertions in switch etc. 

Another benefit of not allowing method calls on T is that you don't have to choose whether to use io.Reader as a type parameter or as a runtime interface when you design a function. That lack of not having to make that choice is in my view  beneficial because it simplifies the programming effort (less choices to make) and avoids discussions and opinion camps. The drawback is that you lose some expressiveness / conciseness in writing some generic containers (or algorithms). 

 

On the other hand I agree that an "interface" in its meaning of a "declaration of a method set" applies equally well to compile time and runtime. So the current argument is (I think) that generics is just the application of interfaces at compile time instead of runtime.

I think the argument is rather "we want a way to constrain types and interfaces already provide a familiar way to express such constraints".

It's just about re-using a familiar mechanic, instead of introducing a new one (in fact, the previous incarnation of contracts *would* have introduced a new mechanic and that was one of the main criticisms of it).

  

The issue I have with this is that it complicates (at least) the language around the concept of "interface" at lot (just think about all the documentation around interface that needs to be rewritten, and if someone asks a question on a interface you first need to address if it's used runtime or compile time, etc).

I do think interfaces change, but only to accommodate type-lists. I'm not a huge fan of that aspect of the design myself.

If no methods calls on T are allowed, then interfaces and generics can be decoupled and just type lists could suffice (with "comparable" being the only built-in special type list for comparable types):

// sketch 

type Ordered generic {float64,int,string,...}

type Any generic {}

func Max[T Ordered](a, b T) T {}

type Bimap[K, V comparable] struct {

   forward map[K][V]

   reverse map[V][K]

}

etc.

Btw, you lose "sum-types" here of course. 

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

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGgD6C5T5qh747pEwzy1mjmGToYZj2jEE8koMckPk0vNA%40mail.gmail.com.

[Ian Lance Taylor]

On Fri, Jan 1, 2021 at 10:25 AM robert engels <ren...@ix.netcom.com> 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

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

> --
> 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/CAOyqgcXSganwnS-uKZkv8HcvHNPZd%3DMsVidwmVWAD5_OQ4TU0g%40mail.gmail.com.

[Ian Lance Taylor]

On Fri, Jan 1, 2021 at 12:40 PM robert engels <ren...@ix.netcom.com> 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

[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().

[wilk]

+1

>
> Fair enough.

It could be a first step (genrics only in the stdlib) before opening
generics to everybody.

--
wilk

[Kevin Chadwick]

>> Fair enough.
>
>It could be a first step (genrics only in the stdlib) before opening
>generics to everybody.

This stdlib trial approach might allow a spec to mature without the compatibility promise? Is there a danger that it evolves to favour implementers over readers?

Should support for empty interfaces go? Simplifying interfaces job and documentation? Unfortunately external web articles rarely die. Fortunately Gos docs are very good and the authoritive source.

Take this with a pinch of salt as my experience is far less than the designers being scripting, web, c and more recently Go and Dart and in smaller code bases. However I have always endeavoured to write readable code, often rewriting c with too much pointer use and either needless or complex abstraction. I'm afraid to say that even the recent examples and even robs talk, have actually hardened my concern that interfaces, methods and now Generics tend to make code less readable with largely pointless abstraction compared to multiple simple functions (I don't mean passing functions as objects either). Perhaps at the expense of memory copying wrt avoiding methods (I guess methods came about because pointers suck). Personally, I find that I do not appreciate the OOP approach.

[Jesper Louis Andersen]

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.

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

--
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/CAGrdgiVJe_2L5QZ13v-SBZq2C7_e6nX8JDCAE23BcpWqGyH99Q%40mail.gmail.com.

[robert engels]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAJhgaci-M2iL%3DjPL2KB3BbhzRahBz4pjDUPjkiTAF_jjza6FAw%40mail.gmail.com.

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

 

[Jesper Louis Andersen]

On Sun, Jan 3, 2021 at 6:32 PM roger peppe <rogp...@gmail.com> 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.

[Jesper Louis Andersen]

On Mon, Jan 4, 2021 at 9:20 AM Volker Dobler <dr.volke...@gmail.com> 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.

[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)