Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Expectations for generics in Go 1.18

groups.google.com

Post reply on HN
Print view View original

11–20 of 209 posts

Re: Expectations for generics in Go 1.18

#11

Post by ebruchez »

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.

Re: Expectations for generics in Go 1.18

#13

Post by arp242 »

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

The original implementation used ( .. ), which I found an unreadable mess of parentheses soup, but luckily that was changed. The problem with is that it's ambiguous with the greater-than and lesser-than operators. From [1] (among many other discussions on this):

For ambiguities with angle brackets consider the assignment

a, b = w (z)

Without type information, it is impossible to decide whether the right-hand side of the assignment is a pair of expressions:

(w (z))

or whether it is a generic function invocation that returns two result values:

(w)(z)

In Go, type information is not available at compile time. For instance, in this case, any of the identifiers may be declared in another file that has not even been parsed yet.

[1]: https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8

Re: Expectations for generics in Go 1.18

#14

Post by Kranar »

VHRanger wrote: post #9

How are they implemented? Compile time? With template expansion like D and C++?

Yes, which I find unfortunate but I can respect that approach as it's likely the simplest way of implementing it and Go does want to avoid heavy abstraction in its type system.

The downside is you can't do something like have a function pointer to the generic itself or specify generic members of a dyn trait/interface or otherwise treat the generic as a first class value (although you can treat specific instantiations of it as first class). The generic is basically syntactic sugar for a macro like substitution system. C++ and other languages that take the monomorphization route all have this restriction, whereas languages with more "first-class" support for generics like C# don't and hence do allow the moral equivalent of a virtual template.

Re: Expectations for generics in Go 1.18

#15

Post by saurik »

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

Maybe it would feel better if you thought of List as the set of all types that are List, and List[Thing] as extracting a single item from that set?

Re: Expectations for generics in Go 1.18

#18

Post by [deleted] »

arp242 wrote: post #13
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

The original implementation used ( .. ), which I found an unreadable mess of parentheses soup, but luckily that was changed. The problem with is that it's ambiguous with the greater-than and lesser-than operators. From [1] (among many other discussions on this): For ambiguities with angle brackets consider the assignment a, b = w (z) Without type information, it is impossible to decide whether the right-hand side of…

[deleted]

Re: Expectations for generics in Go 1.18

#19

Post by dgunay »

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…

Right, I suppose I forgot that a big reason `Result` works well in Rust is the `?` operator.

At the very least, I'll appreciate having some more sugar over loops that are essentially just map/filter.

Re: Expectations for generics in Go 1.18

#20

Post by topspin »

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?

Post reply on HN