Expectations for generics in Go 1.18 • Hacker News Board

Re: Expectations for generics in Go 1.18

#21

Post by mseepgood » Thu, Oct 28, 2021, 2:03 AM UTC

ebruchez wrote: post #11

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

I don't know the answer to that but Scala is also a precedent for using square brackets for generics (AKA type parameters). However in Scala arrays don't use square brackets so that confusion is avoided.

And Python and CLU, Barbara Liskov's OG generics language.

Re: Expectations for generics in Go 1.18

#22

Post by steveklabnik » Thu, Oct 28, 2021, 2:13 AM UTC

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

Rust used [] for generics a very, very long time ago. A lot of people wish we still did. I personally am glad we do not, but that's only in the context of Rust. I think the choice the Go folks made is very reasonable.

Re: Expectations for generics in Go 1.18

#23

Post by [deleted] » Thu, Oct 28, 2021, 2:23 AM UTC

topspin wrote: post #20

Benjammer wrote: post #17

Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

On the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?

[deleted]

Re: Expectations for generics in Go 1.18

#24

Post by Splizard » Thu, Oct 28, 2021, 2:24 AM UTC

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

It makes sense, you are indexing the function with concrete types to select your implementation. This is consistent with slices and maps.

Re: Expectations for generics in Go 1.18

#25

Post by topspin » Thu, Oct 28, 2021, 2:25 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…

"Isn't the "noise problem" with Go error handling the control flow rather than the lack of generics?"

It's both. Adding only concise flow control, such as with the ? operator, works poorly if all you can return is multiple non-generic values; various common permutations get awkward in that case. And as you point out Result doesn't achieve much without the concise operators. Rust has very successfully shown the benefit of the combination.

Re: Expectations for generics in Go 1.18

#26

Post by benreesman » Thu, Oct 28, 2021, 2:30 AM UTC

Is the garbage collector still an undergraduate project, or did Pike hire Cliff Click while I wasn’t looking?

Re: Expectations for generics in Go 1.18

#27

Post by camkego » Thu, Oct 28, 2021, 2:49 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…

Was the try() proposal for Go error handling? I'm really curious what happened to the proposals for shorter Go error handling, rather than if err!=nil {...}

Re: Expectations for generics in Go 1.18

#28

Post by dagmx » Thu, Oct 28, 2021, 2:50 AM UTC

Benjammer wrote: post #17

Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

I'm actually curious if Go would normalize the characters AND if it had used angle bracketd, and make those equivalent to angle brackets? Would he then not have to even change his code?

I guess that's a lot of ifs/ands but it's interesting that one could have future proofed their code if their bet on syntax paid off

Re: Expectations for generics in Go 1.18

#29

Post by glouwbug » Thu, Oct 28, 2021, 2:55 AM UTC

topspin wrote: post #20

Benjammer wrote: post #17

Thank god, this guy[0] can finally cut over to native generics in his code. [0]: https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

On the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?

Canadians now roll with the term Indigenous instead of Aboriginal

Re: Expectations for generics in Go 1.18

#30

Post by spenczar5 » Thu, Oct 28, 2021, 3:06 AM UTC

glouwbug wrote: post #29

topspin wrote: post #20

Earlier quoted context omitted.

On the question of "what's this?": type ImmutableTreeListᐸElementTᐳ struct "If you look closely, those aren't angle brackets, they're characters from the Canadian Aboriginal Syllabics block, which are allowed in Go identifiers. From Go's perspective, that's just one long identifier." Simultaneously amusing and disturbing. Is there an award for which one might nominate this person?

Canadians now roll with the term Indigenous instead of Aboriginal

That may be, but in this case it is a precise technical term, referring to a particular block of Unicode: https://en.m.wikipedia.org/wiki/Unified_Canadian_Aboriginal_...

Maybe the Unicode Consortium should change it, but for now, Canadian Aboriginal is the correct term.