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

41–50 of 209 posts

Re: Expectations for generics in Go 1.18

#41

Post by mohanmcgeek »

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…

> 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

Re: Expectations for generics in Go 1.18

#42

Post by nemothekid »

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?

The doc says it's actually impossible, and I'm inclined to believe so. Rust has a similar problem in their case they adopted the "turbo fish" operator, where the generic function call would take the following form:

    let (a,b) = w::(z);

Re: Expectations for generics in Go 1.18

#43

Post by ethbr0 »

mseepgood wrote: post #38
adgjlsfhk1 wrote: post #33

Earlier quoted context omitted.

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.

Why not use characters from the Canadian Aboriginal Syllabics block?

ᐸ & ᐳ

Re: Expectations for generics in Go 1.18

#44

Post by mseepgood »

mohanmcgeek wrote: post #41
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…

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

Re: Expectations for generics in Go 1.18

#45

Post by uuddlrlr »

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

Colloquially in the north "native" is ubiquitous.

Re: Expectations for generics in Go 1.18

#46

Post by mseepgood »

ethbr0 wrote: post #43
mseepgood wrote: post #38

Earlier quoted context omitted.

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.

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.

Re: Expectations for generics in Go 1.18

#47

Post by mseepgood »

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?

Can you as a human? If you can't do it a parser can't do it either.

Re: Expectations for generics in Go 1.18

#48

Post by rustnote »

tptacek wrote: post #36
topspin wrote: post #25

Earlier quoted context omitted.

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

I like what Chris Lattner said about language design in Lex Fridman podcast, that you know when you're doing something right because it "feels" right. Rust has a bunch of syntactic sugar which gets critised in many languages, but to me things like error returns with ? "feels" right. Love Go as well, and the error handling makes a lot of sense in concept but it just doesn't "feel" nice to look at or use.

I like there's a language that has such a strong vision, but dealing in absolutes has drawbacks, a little sytactic sugar would make error handling a lot nicer.

Re: Expectations for generics in Go 1.18

#49

Post by rustnote »

mseepgood wrote: post #12
VHRanger wrote: post #9

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

GC Shape Stenciling, a hybrid of stenciling and dictionaries: https://go.googlesource.com/proposal/+/refs/heads/master/des...

So there's a runtime cost for using generics?

Re: Expectations for generics in Go 1.18

#50

Post by thewakalix »

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.

It’s a reference to a cursed Reddit post, at the top of this page.
Post reply on HN