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

141–150 of 150 posts

Re: Go 1.13: xerrors

#141

Post by carc »

apta wrote: post #99
carc wrote: post #89

Earlier quoted context omitted.

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?

I think I agree with you - I'm just trying to understand the other perspective from someone that seems to think not having exceptions is an improvement. I've mostly worked using java and go and to be honest I think I prefer exceptions because you should (almost) always check error codes in go anyway, and if you forget, you just made debugging much more difficult.

Re: Go 1.13: xerrors

#142

Post by apta »

carc wrote: post #141
apta wrote: post #99

Earlier quoted context omitted.

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?

I think I agree with you - I'm just trying to understand the other perspective from someone that seems to think not having exceptions is an improvement. I've mostly worked using java and go and to be honest I think I prefer exceptions because you should (almost) always check error codes in go anyway, and if you forget, you just made debugging much more difficult.

Yes, we're on the same page. It just seems that people parrot what golang authors say without actually deeply thinking about it.

Re: Go 1.13: xerrors

#143

Post by apta »

int_19h wrote: post #107
cle wrote: post #73

Earlier quoted context omitted.

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

golang just brought these arguments back, and they're ending up reinventing most of what's been done, but in a subpar way (e.g. code gen instead of generics, verbose error handling + panics instead of exceptions, etc.).

Re: Go 1.13: xerrors

#144

Post by apta »

AsyncAwait wrote: post #134
apta wrote: post #129

Earlier quoted context omitted.

> Kotlin does that today and I like Kotlin, Kotlin's coroutines are still not like fibers (it's still affected by: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... ) Java is getting record types as well. That being said, one is free to use whatever JVM language they like and still get the huge benefits of the JVM, regardless of the language. > Not strictly true. It does have sync.Map There's also 3rd p…

> Not to mention casting to and from interface{} which is error prone and very tedious and verbose. Agreed, but Java's generics are not the best either. When I am looking for an advanced type system in this space I look at Rust, not Java.

It's not an either-or situation. Java's generics have their advantages (I'm assuming you're referring to type erasure). Just look at the number of languages implemented on top of the JVM to see what I'm talking about. Type erasure made inter-op much easier between languages implemented on the JVM. That being said, there are upcoming improvements to generics in Java and the JVM (e.g. JEP 218).

And generics constitute just one part of a type system. You have languages like Scala if you're looking for a language with a more advanced type system than Rust's, and it also runs on the JVM.

Re: Go 1.13: xerrors

#145

Post by thosakwe »

icholy wrote: post #24
fxfan wrote: post #20

Earlier quoted context omitted.

I've heard great points and experienced myself how utterly legible go is. But nobody on earth has ever praised anything about the language design itself. I wonder if go came from somewhere not google- how would it fare.

Dart also came from Google. Why isn't everyone jumping on that train?

You could argue that there's a bit of a network effect involved. i.e. it doesn't get much love on HN, Reddit, etc. (just look at the comments on any Flutter thread).

Re: Go 1.13: xerrors

#146

Post by joelfolksy »

_ph_ wrote: post #137
flavio81 wrote: post #135

Earlier quoted context omitted.

>I love the dependable simplicity of Go. If you like Go, you'll love the simplicity of Brainf-ck, a clean design which is easy to learn, simple syntax, and supported in almost all computing platforms.

Sorry, I don't see how your comment contributes to the discussion. You have heard of C? A language which most of the Unix infrastructure is built upon? It turns out, Go is a language, which keeps a lot of virtues of C, adding just enough to it to fix some of the shortcomings of C, adding more safety and convenience.

The brainfuck quip is a bit more potent when the Go advocate in question has made it clear that they think language simplicity and code simplicity are equivalent. That didn't happen here, but it's tempting to assume that's what the advocate is thinking when they praise language simplicity so much.

Re: Go 1.13: xerrors

#147

Post by int_19h »

apta wrote: post #143
int_19h wrote: post #107

Earlier quoted context omitted.

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…

golang just brought these arguments back, and they're ending up reinventing most of what's been done, but in a subpar way (e.g. code gen instead of generics, verbose error handling + panics instead of exceptions, etc.).

FWIW I don't think panics are a bad idea necessarily, they're just very different from errors. Errors are part of the API contract (whether enforced by the language or not). Panics are for when the contract is broken on either side, or expected invariants suddenly don't hold - the reason being that if your basic guarantees about process state are broken, you can't really guarantee that you'll be able to handle the error either, and trying to do so regardless might result in a security issue.

This distinction is growing popular in general, including languages that have exceptions (e.g. FailFast in C#) and error types (e.g. panic in Rust).

Re: Go 1.13: xerrors

#148

Post by flavio81 »

_ph_ wrote: post #137
flavio81 wrote: post #135

Earlier quoted context omitted.

>I love the dependable simplicity of Go. If you like Go, you'll love the simplicity of Brainf-ck, a clean design which is easy to learn, simple syntax, and supported in almost all computing platforms.

Sorry, I don't see how your comment contributes to the discussion. You have heard of C? A language which most of the Unix infrastructure is built upon? It turns out, Go is a language, which keeps a lot of virtues of C, adding just enough to it to fix some of the shortcomings of C, adding more safety and convenience.

>You have heard of C?

I'm an experienced C developer.

>which keeps a lot of virtues of C

No, C doesn't have many virtues. It's major virtue was getting close to being a macro assembler, and Go removes that completely. Go tries to be a higher-level-than-C language with good execution speed, but that goal was already achieved perfectly by Object Pascal, D, Ada, and Common Lisp.

Re: Go 1.13: xerrors

#149

Post by smilekzs »

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.

Storage is cheap but GC is not.

Source: I worked for Microsoft on C# projects where GC was constantly the bottleneck. Reducing number of exceptions (especially those used for control flow) helped.

Re: Go 1.13: xerrors

#150

Post by SureshG »

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.

Dart had an initial hiccup, but I think things started changing with flutter - https://github.com/flutter/flutter
Post reply on HN