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

Go 1.13: xerrors

crawshaw.io

Post reply on HN
Print view View original

101–110 of 150 posts

Re: Go 1.13: xerrors

#101

Post by apta »

hu3 wrote: post #90
apta wrote: post #47

Earlier quoted context omitted.

> I wonder if go came from somewhere not google- how would it fare. There was a precursor to golang that the some of the same authors worked on before they were at Google. It didn't go anywhere, precisely because it didn't have Google's name behind it.

Ever considered that in 1995 some aspects of Limbo weren't as appealing as they are today and that this played a great deal in its adoption? For example its CSP concurrency model, similar to Go, was hardly pertinent when common processors were 150 MHz Pentiums with 1 core. Completely different scenarios. Not to mention Bell Labs had enormous influence on Computer Science at the time so it's not like Limbo had no stro…

> For example its CSP concurrency model, similar to Go, was hardly pertinent when common processors were 150 MHz Pentiums with 1 core. Completely different scenarios.

There was always demand for having servers that processed high numbers of requests (e.g. C10K). Just because single core processing was common does not mean that there wasn't need for high concurrency.

> Not to mention Bell Labs had enormous influence on Computer Science at the time so it's not like Limbo had no strong backing either.

In those days there was less fad driven development compared to what we see today. So the effect wasn't as pronounced.

Re: Go 1.13: xerrors

#102

Post by apta »

admax88q wrote: post #95
smilekzs wrote: post #93

Earlier quoted context omitted.

I agree with the feeling, but I also see this being a debate between an opt-in approach (choose to use an error value with gradually more information enclosed) vs opt-out (throw an Exception, a la C#/Java, that by default stores everything you may or may not need, then maybe figure out a way to stop storing what you don't need). The use cases are not going to magically go away though, which explains why we need the s…

> then maybe figure out a way to stop storing what you don't need I'm not sure I understand why this is something you need to do. "Figure out a way to stop storing what you don't need." Who cares if you don't need it, or at least don't need it now, storage is cheap.

Exactly. Plus, code that uses exceptions but does not encounter any throws should be faster than code that uses error checks. In the latter, there's always a cost even if there aren't any errors returned. However, the former can optimize for the (hopefully more common path) of no exceptions being thrown and avoid checks altogether.

Re: Go 1.13: xerrors

#103

Post by dnautics »

jrockway wrote: post #56
trpc wrote: post #12

It seems like golang designers are totally isolated from what's been happening in the last 30 years in languages design. They still insist on their weird way of error handling just like they were stubborn for years and years on the lack of package management and eventually a very weird and rudimentary way of it. It's sad because I use this language extensively but its weirdly mediocre design is totally unfathomable.…

My takeaway from the last 30 years in computer science is that errors are not exceptional. They occur often and should be accounted for near the code that generates the errors. Exceptions and return values are both sub-optimal. Exceptions encourage drastic actions for non-drastic events (exit the program if an HTTP server is transitently slow). Return values encourage ignoring the error value, and then wondering why…

> My takeaway from the last 30 years in computer science is that errors are not exceptional. They occur often and should be accounted for near the code that generates the errors... We should make it possible for functions to declare everything that goes wrong so that recovery can be more easily tested.

https://www.theatlantic.com/ideas/archive/2019/04/why-accide...

> Accidents happen. What he meant is that they must happen. Worse, according to Perrow, a humbling cautionary tale lurks in complicated systems: Our very attempts to stave off disaster by introducing safety systems ultimately increase the overall complexity of the systems, ensuring that some unpredictable outcome will rear its ugly head no matter what.

Re: Go 1.13: xerrors

#104

Post by retzkek »

tylerhou wrote: post #74
cle wrote: post #42

Earlier quoted context omitted.

Go's error handling is essentially the same as Error/Either/StatusOr (returning errors as values). Re: exceptions, there are a lot of people, myself included, who do not view exceptions as "advancements", but as setbacks. Magically and suddenly subverting the normal control flow and unwinding the stack in highly concurrent programs (as is expected in Go) is an awful way to do error handling, and you end up having to…

> Go's error handling is essentially the same as Error/Either/StatusOr (returning errors as values). Not really, it's very annoying to chain calls which can error. Also, as another commenter mentioned, functions which can potentially fail should return sum types and not product types. Compare: do first and first, err := computeFirst() if err != nil { return nil, err } second, err := computeSecond() if err != nil { re…

> Even without do-notation the Haskell is considerably shorter

This is a great example, not to your point, but to the methodology of Go. You give a verbose Go example, that I expect the vast majority of readers here could understand, even if they've never written a single line of Go, followed by a terse but syntax-heavy Haskell example that I expect relatively few could.

Re: Go 1.13: xerrors

#105

Post by int_19h »

secure wrote: post #84
scrollaway wrote: post #57

Earlier quoted context omitted.

What's the point of making it a format string if you are hardcoding where the % identifier goes anyway?!

The %w (or %v) identifier must be at the end for the magic to work, but you can still meaningfully format things in front of the wrapped error, e.g. fmt.Errorf("Write(%s): %w", filename, err)

Why does it need to be at the end?

Re: Go 1.13: xerrors

#106

Post by int_19h »

retzkek wrote: post #104
tylerhou wrote: post #74

Earlier quoted context omitted.

> Go's error handling is essentially the same as Error/Either/StatusOr (returning errors as values). Not really, it's very annoying to chain calls which can error. Also, as another commenter mentioned, functions which can potentially fail should return sum types and not product types. Compare: do first and first, err := computeFirst() if err != nil { return nil, err } second, err := computeSecond() if err != nil { re…

> Even without do-notation the Haskell is considerably shorter This is a great example, not to your point, but to the methodology of Go. You give a verbose Go example, that I expect the vast majority of readers here could understand, even if they've never written a single line of Go, followed by a terse but syntax-heavy Haskell example that I expect relatively few could.

The last example is Haskell without the syntactic sugar. The first example is in Haskell how it's normally written, and it's far clearer than Go.

Re: Go 1.13: xerrors

#107

Post by int_19h »

cle wrote: post #73
apta wrote: post #51

Earlier quoted context omitted.

> Go's error handling is essentially the same as Error/Either/StatusOr (returning errors as values). Except that you cannot easily chain calls that return errors, or it isn't really that hard to accidentally ignore errors because of shadowing or overwriting the variable you're storing your errors in. Or the fact that using a union type to represent errors is a strictly superior way, both in terms of usability, as wel…

> Except that you cannot easily chain calls that return errors, or it isn't really that hard to accidentally ignore errors because of shadowing or overwriting the variable you're storing your errors in. Or the fact that using a union type to represent errors is a strictly superior way, both in terms of usability, as well as correctness. People should just face the fact that returning errors as a product type is a mis…

They're essentially the same, in a sense that if/goto is essentially the same as a loop. In practice, there's a big pragmatic difference.

And I have to say, the debate around Go error handling does remind me a fair bit of some of the arguments I've read while researching that ancient debate about structured programming - needless abstraction that we're not even sure is right, it's clearer when it's explicit, language is simpler etc.

Re: Go 1.13: xerrors

#108

Post by lugg »

insertnickname wrote: post #8
nickcw wrote: post #4

This (it looks like to me) is an attempt to pull in the best bits of Dave Cheney's errors package (which I love) into the standard library: https://github.com/pkg/errors Standardising error unwrapping is a great idea IMHO and I think that this has a lot of merit. I don't like the `fmt.Errorf("more description: %w", err)` though for several reasons. Firstly it is a lot more opaque than Dave Cheney's original mechanism…

> Secondly why is this really important functionality in `fmt` and not in `error`? `fmt` already depends on `errors`, and Go does not allow cyclical dependencies, so `errors` would have to reimplement string formatting.

That's not an argument for putting it in fmt.

That's an argument for putting it in the language layer or putting it in its own place.

Re: Go 1.13: xerrors

#109

Post by lugg »

voidlogic wrote: post #94
nickcw wrote: post #4

This (it looks like to me) is an attempt to pull in the best bits of Dave Cheney's errors package (which I love) into the standard library: https://github.com/pkg/errors Standardising error unwrapping is a great idea IMHO and I think that this has a lot of merit. I don't like the `fmt.Errorf("more description: %w", err)` though for several reasons. Firstly it is a lot more opaque than Dave Cheney's original mechanism…

IMHO they should either just adopt Dave Cheney's errors package ( https://github.com/pkg/errors ) into the standard library or leave it as it is becoming the de-facto standard. The parallel reddit thread seems to agree too: https://www.reddit.com/r/golang/comments/biexq0/go_113_xerro...

Because this isn't nodejs.

Re: Go 1.13: xerrors

#110

Post by lugg »

nicoburns wrote: post #91
oppositelock wrote: post #64

Earlier quoted context omitted.

I've been using Go heavily over the last five years, starting with 1.2. Whatever warts the language has in its design, the error handling being one, it's still an excellent language for getting work done quickly, and correctly. I'm far more productive in it than Java, C++, or Python, and I'm old enough to have done lots of Pascal, Lisp, and more scripting dialects than I can count. Having been writing software over t…

> Java, C++ and Python have exceptions to keep you from littering your code with error handling, and code with exceptions is hard to read. The line of code you are looking at any point in time may instantly jump to another place, effectively, Rust and Swift both manage to make error handling easy while keeping this nice "errors are just values" property. Go could easily have added Rust-like or Swift-like error handli…

How is rust error handling better than gos?
Post reply on HN