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

91–100 of 150 posts

Re: Go 1.13: xerrors

#91

Post by nicoburns »

oppositelock wrote: post #64
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.…

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 handling backwards compatibly with their existing idioms without falling back on weird special cases of format strings, but have chosen not too.

This does not make the language simple (even though in other ways it is).

Re: Go 1.13: xerrors

#92

Post by geodel »

apta wrote: post #80
takeda wrote: post #71

Earlier quoted context omitted.

I wouldn't necessarily call Go's concurrency model superior, it seem like that initially but after all hype died out a bit it has issues. It essentially just offers one way to do concurrency. That might fit really well for some problems, not so much for others. I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os[1]. Perhaps I'll upset some, but IMO Go would be anoth…

> but IMO Go would be another obscure language that no one cared about if it didn't come from Google. The people who worked on golang also worked on another similar language called limbo before they were at google. You can guess where that one ended up.

The people who worked on Java also worked on Dart after joining Google. You can guess where it ended up.

Re: Go 1.13: xerrors

#93

Post by smilekzs »

admax88q wrote: post #66

Go error handling. Slowly re-inventing Java's exceptions one use case at a time.

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 solution to be somewhere in the middle.

Re: Go 1.13: xerrors

#94

Post by voidlogic »

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

Re: Go 1.13: xerrors

#95

Post by admax88q »

smilekzs wrote: post #93
admax88q wrote: post #66

Go error handling. Slowly re-inventing Java's exceptions one use case at a time.

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.

Re: Go 1.13: xerrors

#96

Post by admax88q »

zzzcpan wrote: post #67
admax88q wrote: post #66

Go error handling. Slowly re-inventing Java's exceptions one use case at a time.

Weirdly enough this perspective might suggest that the problem is not actually with Go, but with object oriented programming. Which wasn't considered thoroughly by original authors, because they were not OO programmers.

No other paradigm appears to be able to handle the complexity required to build the systems of today. Objects are very natural way to organize complexity. It's what let UNIX succeed where Multics failed.

Re: Go 1.13: xerrors

#97

Post by apta »

geodel wrote: post #92
apta wrote: post #80

Earlier quoted context omitted.

> but IMO Go would be another obscure language that no one cared about if it didn't come from Google. The people who worked on golang also worked on another similar language called limbo before they were at google. You can guess where that one ended up.

The people who worked on Java also worked on Dart after joining Google. You can guess where it ended up.

They're not in the same market. Dart faced competition from TypeScript (same designer as C#, and also backed by Microsoft), and the latter seems to have won so far.

Re: Go 1.13: xerrors

#98

Post by apta »

oppositelock wrote: post #64
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.…

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…

> The line of code you are looking at any point in time may instantly jump to another place,

It's the same in golang, any line can panic.

Re: Go 1.13: xerrors

#99

Post by apta »

carc wrote: post #89
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…

Aren't you supposed to check all the possible errors in golang anyway? How's that any different than java code being littered with error handling code?

Except it's possible to miss checking errors in golang (accidentally either by not assigning the return value, or by overwriting a previously assigned error). Whereas in a language with exceptions, this is not possible unless by explicitly adding code to ignore exceptions.

Do you ever see golang code that handles errors returned from fmt.Println?

Re: Go 1.13: xerrors

#100

Post by apta »

AsyncAwait wrote: post #79
takeda wrote: post #71

Earlier quoted context omitted.

I wouldn't necessarily call Go's concurrency model superior, it seem like that initially but after all hype died out a bit it has issues. It essentially just offers one way to do concurrency. That might fit really well for some problems, not so much for others. I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os[1]. Perhaps I'll upset some, but IMO Go would be anoth…

> I wouldn't necessarily call Go's concurrency model superior Sure, opinions differ, the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases. > I don't know what to say about native binaries, when a Go's "hello world" app is as big as an entire os Is that OS written in Java or C#, because that's what the discussion was about. Also, CSP is not the only way of doing…

> the point is that it's far from clear that Java etc. are superior in every way, certainly for some use cases.

Once Java gets fibers, its concurrency offerings will be a strict superset of golang's. golang doesn't even offer event based async concurrency.

> Also, CSP is not the only way of doing concurrency in Go. The standard shared variable model with mutexes is supported as well, just not preffered.

golang doesn't even have concurrent data structures. So it's either CSP or mutexes, both not ideal for high performance code.

Post reply on HN