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

31–40 of 209 posts

Re: Expectations for generics in Go 1.18

#31

Post by jchw »

dagmx wrote: post #28
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

They're semantically different characters and Go supports multilingual identifiers, so I would not expect normalization to impact this. At most I would expect normalization to simply deal with ordering combining marks and standardizing on composed or decomposed forms of characters (where applicable.)

Re: Expectations for generics in Go 1.18

#32

Post by jandrese »

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?

That's the kind of thing you see in a comment and then back slowly out of the room, never breaking eye contact with the code until you are far enough away to turn tail and run.

At the very least they could have used the cute Japanese 「quotation marks」 to avoid confusion.

Re: Expectations for generics in Go 1.18

#33

Post by adgjlsfhk1 »

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…

Why not {} That should be pretty easily parsable, and seems less ambiguous than [] (also Julia at least is prior art)

Re: Expectations for generics in Go 1.18

#34

Post by mseepgood »

camkego wrote: post #27
benhoyt wrote: post #4

Earlier quoted context omitted.

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

> Was the try() proposal for Go error handling?

Yes, it was the second proposal by the Go team for shorter error handling: https://github.com/golang/proposal/blob/master/design/32437-...

> I'm really curious what happened to the proposals for shorter Go error handling

The community didn't like it and it was declined: https://github.com/golang/go/issues/32437#issuecomment-51203...

Re: Expectations for generics in Go 1.18

#35

Post by edflsafoiewq »

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.

Re: Expectations for generics in Go 1.18

#36

Post by tptacek »

topspin wrote: post #25
benhoyt wrote: post #4

Earlier quoted context omitted.

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

I wrote a comment here pushing back somewhat on the idea that Rust has much better error handling ergonomics (not correctness, where it clearly wins, but ergonomics) but thought better of it; debating Go vs. Rust is about the least productive thing we can do on HN.

Re: Expectations for generics in Go 1.18

#38

Post by mseepgood »

adgjlsfhk1 wrote: post #33
arp242 wrote: post #13

Earlier quoted context omitted.

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…

Why not {} That should be pretty easily parsable, and seems less ambiguous than [] (also Julia at least is prior art)

You can't get more ambiguous to parse than {} in the context of Go.

> also Julia at least is prior art

Julia doesn't use curly braces for blocks and structs.

Re: Expectations for generics in Go 1.18

#39

Post by throwaway894345 »

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 love the reply: “c++ allows zero width spaces in variable names. where’s your god now?”

Re: Expectations for generics in Go 1.18

#40

Post by blondin »

mseepgood wrote: post #8
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

> 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?
Post reply on HN