Expectations for generics in Go 1.18 • Hacker News Board

Re: Expectations for generics in Go 1.18

#51

Post by thewakalix » Thu, Oct 28, 2021, 4:21 AM UTC

edflsafoiewq wrote: post #35

jimbob45 wrote: post #6

Does anyone know the impetus for using [] in generics? I know Nim opted for the same syntax and I assume it has some parsing/tokenizing benefit like the switch to using “fn” a la Zig or Rust. However, the syntax seems needlessly ambiguous with array notation sharing the same operator. I know I’m not alone because I’ve seen others mirror my concerns on Nim forums [0]. [0] https://github.com/nim-lang/Nim/issues/3502

Eiffel is the first language I know of to use [] for generics. It's consistent with the interpretation of [] as "subscripting"; the generic is a family parameterized by types, and the subscript selects one element of the family.

What’s even more consistent is using juxtaposition to represent all parameterization, on the value and type levels. Haskell does this!

Re: Expectations for generics in Go 1.18

#52

Post by 0x500x79 » Thu, Oct 28, 2021, 4:23 AM UTC

mseepgood wrote: post #46

ethbr0 wrote: post #43

Earlier quoted context omitted.

Why not use characters from the Canadian Aboriginal Syllabics block? ᐸ & ᐳ

Are we going to ask this for every Unicode character pair? They have answered all these questions in the design document: https://go.googlesource.com/proposal/+/refs/heads/master/des... They thought about generics for 12 years. It's unlikely that someone who thought about it for 3 minutes on Hacker News has some epiphany that wasn't taken into consideration.

I think this is a joke from another thread: https://www.reddit.com/r/rust/comments/5penft/parallelizing_....

Also, I think it is fair to challenge the decisions here seeing as how there have been a few things chosen in Go's history that ignores prior art from other programming languages.

Re: Expectations for generics in Go 1.18

#53

Post by [deleted] » Thu, Oct 28, 2021, 4:25 AM UTC

mseepgood wrote: post #46

ethbr0 wrote: post #43

Earlier quoted context omitted.

Why not use characters from the Canadian Aboriginal Syllabics block? ᐸ & ᐳ

Are we going to ask this for every Unicode character pair? They have answered all these questions in the design document: https://go.googlesource.com/proposal/+/refs/heads/master/des... They thought about generics for 12 years. It's unlikely that someone who thought about it for 3 minutes on Hacker News has some epiphany that wasn't taken into consideration.

[deleted]

Re: Expectations for generics in Go 1.18

#54

Post by johnisgood » Thu, Oct 28, 2021, 4:27 AM UTC

benhoyt wrote: post #4

dgunay wrote: post #2

Very reasonable caveats for a feature as big as generics. Personally, I'm super excited for the potential generics has to make error handling in Go less noisy, so I'll be attempting to use it ASAP.

Isn't the "noise problem" with Go error handling the control flow rather than the lack of generics? You want to return early (and potentially add context to the error) if there was an error, otherwise continue on. How are you thinking of solving this with generics? The previous try() proposal added new control flow. That's part of the reason it was criticized so heavily -- it hid a control flow construct in something…

I want the "if err != nil" back!

Re: Expectations for generics in Go 1.18

#55

Post by arp242 » Thu, Oct 28, 2021, 4:29 AM UTC

blondin wrote: post #40

mseepgood wrote: post #8

Earlier quoted context omitted.

> Does anyone know the impetus for using [] in generics? Yes: https://go.googlesource.com/proposal/+/refs/heads/master/des...

is it really the case that parsers can't tell the greater than sign in "a, b = w (z)" without type information? or is it simply difficult to parse for some parsers?

It's a problem all languages with need to solve one way or the other; see e.g. https://blog.dyvil.org/syntax/2016/04/19/angle-bracket-gener...

So for C# it's resolved "by examining the token after the closing >: If it is one of (, ), ], :, ;, ,, ., ?, == or !=, the expression is parsed as a generic method call."

I assume this works reasonably well; however, it's not hard to see how this might be a problem in some cases where the parser gets it wrong.

Re: Expectations for generics in Go 1.18

#56

Post by samtheprogram » Thu, Oct 28, 2021, 4:31 AM UTC

From the outside, it seems like adding generics to Go seems similarly controversial and slow as the Python jump to version 3 — although Go generics haven’t even landed yet.

Generics have the potential to impact a decent amount of the standard library. Although I’m not surprised that they are not doing a major version bump given the isolation of the feature at this stage, it will be interesting to observe its uptake in the community and whether fragmentation occurs over what is supported and what isn’t given their recommendation of isolating generics-related code in third party libraries.

Re: Expectations for generics in Go 1.18

#57

Post by edflsafoiewq » Thu, Oct 28, 2021, 4:32 AM UTC

thewakalix wrote: post #51

edflsafoiewq wrote: post #35

Earlier quoted context omitted.

Eiffel is the first language I know of to use [] for generics. It's consistent with the interpretation of [] as "subscripting"; the generic is a family parameterized by types, and the subscript selects one element of the family.

What’s even more consistent is using juxtaposition to represent all parameterization, on the value and type levels. Haskell does this!

That errs to the side of too much consistency for me. I'd like a nice balance; a small amount of syntax... but not too small. After all, morally x.a, x[a], and x(a) are all the same thing.

Re: Expectations for generics in Go 1.18

#58

Post by hota_mazi » Thu, Oct 28, 2021, 4:35 AM UTC

> Because we will not know what the best practices are for using generics,

Well, you could... take a look at languages created these past twenty years that support generics, learn lessons from that, and see how these lessons could apply to Go.

But well, the Go team is not exactly known for paying much attention to the state of programming language theory, so I guess that's out.

Re: Expectations for generics in Go 1.18

#59

Post by stouset » Thu, Oct 28, 2021, 4:38 AM UTC

mseepgood wrote: post #44

mohanmcgeek wrote: post #41

Earlier quoted context omitted.

> How are you thinking of solving this with generics? People can now create Try or Option monads instead of returning the error. This was the one of the reasons anti generics people were anti generics

But that will make error handling more verbose.

Speaking as a user of languages that have exactly this, it can’t possibly be any worse than the situation in Go right now.

Re: Expectations for generics in Go 1.18

#60

Post by benhoyt » Thu, Oct 28, 2021, 4:49 AM UTC

samtheprogram wrote: post #56

From the outside, it seems like adding generics to Go seems similarly controversial and slow as the Python jump to version 3 — although Go generics haven’t even landed yet. Generics have the potential to impact a decent amount of the standard library. Although I’m not surprised that they are not doing a major version bump given the isolation of the feature at this stage, it will be interesting to observe its uptake i…

I don't think it's anything like the Python jump from 2 to 3. That changed the behavior of a lot of code (unicode vs bytes, various syntax changes, import changes, etc), and there was no way to automatically upgrade a codebase (2to3 didn't really work).

With the addition of generics to Go, they've been careful to ensure it's fully backwards compatible, so all existing code will still work as is. Major version bumps are for incompatible changes (like Python 2.x to 3.x).

What they're recommending with isolating generic code in existing libraries is so users of older versions of Go (1.17 and prior) can still use those libraries, just not any new functions/types the libraries have added that use generics, and hence require Go 1.18.