Expectations for generics in Go 1.18 • Hacker News Board

Re: Expectations for generics in Go 1.18

#131

Post by jcelerier » Thu, Oct 28, 2021, 9:54 AM UTC

kodah wrote: post #74

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?

> oh my god Definitely the correct response. Also, > c++ allows 0-width spaces in variable names. Where's your god now? Nowhere. We have strayed maximal distance from god's light and are currently in orbit around Satan.

> > c++ allows 0-width spaces in variable names.

Is that true though ?

> A valid identifier must begin with a non-digit character (Latin letter, underscore, or Unicode character of class XID_Start) and may contain non-digit characters, digits, and Unicode characters of class XID_Continue in non-initial positions. Identifiers are case-sensitive (lowercase and uppercase letters are distinct), and every character is significant. Every identifier must conform Normalization Form C.

Re: Expectations for generics in Go 1.18

#132

Post by masklinn » Thu, Oct 28, 2021, 9:57 AM UTC

1_player wrote: post #91

baby wrote: post #61

Earlier quoted context omitted.

If you don’t have a result type then you don’t have better error handling!

Zig disagrees. Monads are cool and all, but we can do better than Result for error handling.

Result is monadic but not necessarily a monad.

From what I know of zig’s error handling, I really don’t think it’s better than result types.

It is less work, especially when using error unions (though I think that makes it easier to miss changes to error sets as they’re implicit), but since errors are literally just u16 they’re also deeply lacking in richness and composability.

It’s definitely an improvement over C’s error style, and thus perfectly understandable given zig’s goal, but I very much disagree that it’s “better than Result”.

It’s also extremely magical in that it needs special language-level support throughout in ways Result is not, but obviously that’s more of a matter of taste.

Re: Expectations for generics in Go 1.18

#133

Post by sudhirj » Thu, Oct 28, 2021, 10:01 AM UTC

kubb wrote: post #117

I'm glad that all the blog posts written by the apologetes and zealots, claiming that Go doesn't need generics and how they will actually be a detriment to the language, are archived somewhere in the wayback machines, so that they can't gaslight us into believing that they weren't just being silly for all this time.

Sigh. Go without generics was useful. We built useful things with it.

Go with generics will continue to be useful, and it'll make it easier to build some things that were irritating to build earlier.

The design of generics went though so many rounds of iteration and discussions to make sure it wasn't a detriment to the language - indeed you can build everything that Go has already been used to build without ever knowing about or using generics.

Generics coming into a 1.x release also means that any code written under 1.x is expected to continue working perfectly, generics or not.

The process has made sure no damage will be done, and we now have a new toolkit to make solving some problems easier. I don't think anyone is trying to gaslight anyone by using generics.

Re: Expectations for generics in Go 1.18

#134

Post by mseepgood » Thu, Oct 28, 2021, 10:06 AM UTC

Zababa wrote: post #127

mseepgood wrote: post #12

Earlier quoted context omitted.

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

How does that compare to other approaches for generics? I know that you can do monomorphisation, which usually increases the executable size and compilation time, and usually gives faster code, but I don't know about other approcahes.

The two approaches are stenciling (what you call monomorphisation) and dictionaries. Stenciling/monomorphization increases binary size, compilation time and TLB/cache pressure. The dictionaries-only approach has more runtime cost. This hybrid is a middle ground of both.

Re: Expectations for generics in Go 1.18

#135

Post by 1_player » Thu, Oct 28, 2021, 10:11 AM UTC

masklinn wrote: post #132

1_player wrote: post #91

Earlier quoted context omitted.

Zig disagrees. Monads are cool and all, but we can do better than Result for error handling.

Result is monadic but not necessarily a monad. From what I know of zig’s error handling, I really don’t think it’s better than result types. It is less work , especially when using error unions (though I think that makes it easier to miss changes to error sets as they’re implicit), but since errors are literally just u16 they’re also deeply lacking in richness and composability. It’s definitely an improvement over C’…

> It’s also extremely magical in that it needs special language-level support throughout in ways Result is not, but obviously that’s more of a matter of taste.

That's a peculiar observation, it's like saying Rust's borrow checker is magical because it needs language-level support. I mean, that's the point.

In any case re: zig error or rust's Result, I don't think either of us are discussing features and pros/cons, but just describing what we like the best. Not very objective an argument.

> but since errors are literally just u16 they’re also deeply lacking in richness and composability

Zig errors are composable: https://ziglang.org/documentation/master/#Merging-Error-Sets and later sections.

Re: Expectations for generics in Go 1.18

#136

Post by [deleted] » Thu, Oct 28, 2021, 10:17 AM UTC

kubb wrote: post #117

I'm glad that all the blog posts written by the apologetes and zealots, claiming that Go doesn't need generics and how they will actually be a detriment to the language, are archived somewhere in the wayback machines, so that they can't gaslight us into believing that they weren't just being silly for all this time.

[deleted]

Re: Expectations for generics in Go 1.18

#137

Post by kubb » Thu, Oct 28, 2021, 10:17 AM UTC

sudhirj wrote: post #133

kubb wrote: post #117

I'm glad that all the blog posts written by the apologetes and zealots, claiming that Go doesn't need generics and how they will actually be a detriment to the language, are archived somewhere in the wayback machines, so that they can't gaslight us into believing that they weren't just being silly for all this time.

Sigh. Go without generics was useful. We built useful things with it. Go with generics will continue to be useful, and it'll make it easier to build some things that were irritating to build earlier. The design of generics went though so many rounds of iteration and discussions to make sure it wasn't a detriment to the language - indeed you can build everything that Go has already been used to build without ever know…

That's an expected pivot. From "nobody needs generics" to "we absolutely needed 10 years to figure out the best way to do parametric polymorphism, which was already known for 35 years when the language was created".

And of course in addition to that, there will probably be claims that "no one claimed that generics aren't needed". I'm glad that we have the archives to show that this isn't true, and it's a good thing to keep in mind when opinions are being pushed on HN.

Re: Expectations for generics in Go 1.18

#138

Post by kubb » Thu, Oct 28, 2021, 10:21 AM UTC

chairmanwow1 wrote: post #119

kubb wrote: post #113

Earlier quoted context omitted.

They already have it with panic and recover. They just don't recommend using it for error handling.

Even if this behavior is similar to how Java exceptions work, I love the way go packages are written. Explicit error handling can be tedious, but I’m never confused about what some code will do. Compared to Java where an exception may bubble up 10 layers to a catchall try catch statement, I actually know where the error is coming from. Would be nice to have this abstracted away with tooling though. I would imagine go…

I'm just stating a fact, it's slightly unnecessary to reply with your declaration of love for Go.

I prefer returning errors as a part of the function result myself, as you would in any decent language encouraging functional programming principles.

If anything, it shows that including a feature in a language (exceptions) will not lead to people misusing it if that misuse is not encouraged.

Re: Expectations for generics in Go 1.18

#139

Post by afiodorov » Thu, Oct 28, 2021, 10:29 AM UTC

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? ᐸ & ᐳ

made my day

Re: Expectations for generics in Go 1.18

#140

Post by masklinn » Thu, Oct 28, 2021, 10:31 AM UTC

1_player wrote: post #135

masklinn wrote: post #132

Earlier quoted context omitted.

Result is monadic but not necessarily a monad. From what I know of zig’s error handling, I really don’t think it’s better than result types. It is less work , especially when using error unions (though I think that makes it easier to miss changes to error sets as they’re implicit), but since errors are literally just u16 they’re also deeply lacking in richness and composability. It’s definitely an improvement over C’…

> It’s also extremely magical in that it needs special language-level support throughout in ways Result is not, but obviously that’s more of a matter of taste. That's a peculiar observation, it's like saying Rust's borrow checker is magical because it needs language-level support. I mean, that's the point. In any case re: zig error or rust's Result, I don't think either of us are discussing features and pros/cons, bu…

> That's a peculiar observation, it's like saying Rust's borrow checker is magical because it needs language-level support. I mean, that's the point.

You can’t do borrow checking without language support (I think, at least not without a significantly more expressive type system) whereas Result is pretty much just a type, the features it uses are mostly non-exclusive, and those which are, are very much intended not to remain so (e.g. the `Try` trait for the `?` operator).

> Zig errors are composable: https://ziglang.org/documentation/master/#Merging-Error-Sets and later sections.

Not really? That’s just merging error sets, but you can’t say that you’ve got an error which originally comes from an other error, except by creating its dual and documenting it as such. Essentially your choices are full transparency or full type erasure.