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

191–200 of 209 posts

Re: Expectations for generics in Go 1.18

#191

Post by steveklabnik »

topspin wrote: post #189
dnautics wrote: post #178

Earlier quoted context omitted.

To clarify I thin parent means syntax error I'm the sense of "I'm parsing a (code) file at runtime and there's a syntax error", not a language syntax error. I mean there's nothing stopping you in zig from creating a rich "error" struct and returning a union of the struct with whatever you would have done otherwise. You only lose the error return trace.

"I mean there's nothing stopping you in zig from creating a rich "error" struct" Thus Rust's std::result::Result where the E in Err(E) is anything that implements the std::result::Error trait. Rust got this right. It satisfies most use cases with the least possible noise and accommodates the weird ones easily, and does it in a std:: codified manner where no one has to wonder whether or not there is anything stopping…

(E is not required to implement that trait, it just often does)

Re: Expectations for generics in Go 1.18

#192

Post by typical182 »

tored wrote: post #179
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…

> In Go, type information is not available at compile time. Not a compiler expert, but I got confused when reading this, when is it available?

I think they meant “type information is not available at parse time” (rather than “compile time”).

There is a longer and more precise description of the problem as part of this FAQ of the generics proposal:

https://go.googlesource.com/proposal/+/refs/heads/master/des...

…which includes an example and the statement “It is a key design decision of Go that parsing be possible without type information”.

Re: Expectations for generics in Go 1.18

#193

Post by skybrian »

adwn wrote: post #161
skybrian wrote: post #71

Earlier quoted context omitted.

Given that every language is different, this is basically reasoning by analogy. Sometimes analogies are useful for explaining things, but they're not a reliable way of determining what will definitely work. Reasoning by analogy in a sneering way doesn't make it work better.

Programming languages differ, yes, but not so much that they face completely different design decisions. Also, it's not "reasoning by analogy", it's learning from others . In fact, why stop at generics? Why not go back and question structured programming? Or strong typing? Because structured programming and strong typing has proven to be extremely useful. Same as generics in statically typed languages.

Maybe reasoning by analogy and learning from others are about the same thing?

How much you should rely on others' experience, and when you should consider it a positive example versus something to learn from by avoiding, is going to be a judgement call.

Re: Expectations for generics in Go 1.18

#194

Post by dnautics »

topspin wrote: post #189
dnautics wrote: post #178

Earlier quoted context omitted.

To clarify I thin parent means syntax error I'm the sense of "I'm parsing a (code) file at runtime and there's a syntax error", not a language syntax error. I mean there's nothing stopping you in zig from creating a rich "error" struct and returning a union of the struct with whatever you would have done otherwise. You only lose the error return trace.

"I mean there's nothing stopping you in zig from creating a rich "error" struct" Thus Rust's std::result::Result where the E in Err(E) is anything that implements the std::result::Error trait. Rust got this right. It satisfies most use cases with the least possible noise and accommodates the weird ones easily, and does it in a std:: codified manner where no one has to wonder whether or not there is anything stopping…

Have you seen what a "rich error struct union" looks like in zig? It's very easy and very legible code. I'd further bet that there are no cases when you're doing this that you want an error return trace. And the downstream handling code is very easy.

If there is a problem with how it's done in zig, it's a community one: maybe the pattern needs a megaphone beside it, like examples in the main docs or tuts in the various zig tut sites that have cropped up

Re: Expectations for generics in Go 1.18

#195

Post by _hzrk »

eweise wrote: post #168
_hzrk wrote: post #130

Earlier quoted context omitted.

Yep, Kafka is probably the most popular one. I've heard that the team is looking forward to replace the remaining Scala code in the project with Java once pattern matching and co. land. Spark is another beast that was written in Scala. Many are reporting a high cost for compatibility. Nowadays, Scala community is all about Typelevel and ZIO, if you are not a category theory minded person, then you will have a hard ti…

Zio's library is not based on category theory. In fact, its trying to be the opposite.

https://github.com/zio/zio-prelude

Re: Expectations for generics in Go 1.18

#196

Post by arp242 »

tored wrote: post #179
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…

> In Go, type information is not available at compile time. Not a compiler expert, but I got confused when reading this, when is it available?

Most (if not all) languages are compiled or interpreted in two stages: first the code is parsed (a.k.a. lexed, tokenized) to an internal representation (usually called "Abstract Syntax Tree", or AST), which just means translating something like ">" to "GREATER_THAN_SYMBOL", "5" to NUMBER, etc. and storing this in some data structure. This is also where you usually detect syntax errors like forgetting to use " to close a string and such.

In Go, you can do this fairly easily with the go/ast package.

Then you take the AST and do something with it. That something can be compiling the code, but also writing some sort of tooling like a linter, or identifier rename tool, or generate documentation from it, or whatnot. When compiling the code you need the type information, for a lot of other purposes you don't really care.

It's pretty valuable to keep the parsing as simple as possible; it makes it easier to detect errors, improves the quality of the error messages, and makes it easier to write tooling. It also keeps the code a lot simpler, easier to understand and modify, etc.

Re: Expectations for generics in Go 1.18

#197

Post by dragonwriter »

arp242 wrote: post #196
tored wrote: post #179

Earlier quoted context omitted.

> In Go, type information is not available at compile time. Not a compiler expert, but I got confused when reading this, when is it available?

Most (if not all) languages are compiled or interpreted in two stages: first the code is parsed (a.k.a. lexed, tokenized) to an internal representation (usually called "Abstract Syntax Tree", or AST), which just means translating something like ">" to "GREATER_THAN_SYMBOL", "5" to NUMBER, etc. and storing this in some data structure. This is also where you usually detect syntax errors like forgetting to use " to clos…

> Most (if not all) languages are compiled or interpreted in two stages: first the code is parsed (a.k.a. lexed, tokenized) to an internal representation (usually called "Abstract Syntax Tree", or AST)

Lexing/tokenization doesn't produce an AST; it produces a token stream. Parsing (which may or may not be preceded by lexing) produces an AST.

Re: Expectations for generics in Go 1.18

#198

Post by konart »

kubb wrote: post #113
konart wrote: post #77

Earlier quoted context omitted.

Hopefully not and never.

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

...because panic and recovery is a whole different plane of existence. Recovery feature is a needed evil here, needless for a simple error handling.

Re: Expectations for generics in Go 1.18

#199

Post by pjmlp »

EdwardDiego wrote: post #78
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_...

It's funny how codegen has become widespread in Golang to work around its deficiency.

C++ and Java also used codegen before they got templates and generics respectively, but since Go's matra is to relearn history, they had to have a go at it.

Re: Expectations for generics in Go 1.18

#200

Post by topspin »

dnautics wrote: post #194
topspin wrote: post #189

Earlier quoted context omitted.

"I mean there's nothing stopping you in zig from creating a rich "error" struct" Thus Rust's std::result::Result where the E in Err(E) is anything that implements the std::result::Error trait. Rust got this right. It satisfies most use cases with the least possible noise and accommodates the weird ones easily, and does it in a std:: codified manner where no one has to wonder whether or not there is anything stopping…

Have you seen what a "rich error struct union" looks like in zig? It's very easy and very legible code. I'd further bet that there are no cases when you're doing this that you want an error return trace. And the downstream handling code is very easy. If there is a problem with how it's done in zig, it's a community one: maybe the pattern needs a megaphone beside it, like examples in the main docs or tuts in the vario…

"Have you seen what a "rich error struct union" looks like in zig?"

No, and I'm not arguing that zig hasn't done well. I do argue that Go has not; you're only non-weird choice is to fetter code with miles of "if err ==/!=" gymnastics.

Traces are frequently very useful; precise traces have saved me a lot of pain in life. Lack of traces precludes nothing for me, but I have enjoyed the benefit of them enough times to acknowledge their great value.

Post reply on HN