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

Gopher Wrangling: Effective error handling in Go

stephenn.com

Post reply on HN
Print view View original

111–120 of 310 posts

Re: Gopher Wrangling: Effective error handling in Go

#111

Post by philosopher1234 »

andrewjf wrote: post #107
philosopher1234 wrote: post #103

Earlier quoted context omitted.

I don’t buy it. I can’t think of a single other Google backed programming language with anywhere near to the following of Go. I think Googles stamp gives it some legitimacy, but I think the much likelier explanation is that the values in Go and its design speak to frustrations a lot of people actually have. This thread is full of people arguing in favor of gos error handling. You can dismiss them all as cranks or she…

I mean, maybe - but there's a lot of examples of things being as popular as they are because google did them - gRPC, Protobuf, Kubernetes, Chromium. None of these things were technically bankrupt (including Go), but their adoption curve would not have been what they have been without Googles name on it. There's likely other OSS that's technically better, but did not have the network effects google-backed software had…

Go almost certainly would not have been as successful Without googles brand. But also, without its funding. Google has poured tens of millions of dollars in to go. all of the good qualities of go are due to its incredible funding, whether that’s tooling or the fact that three or four extremely experienced engineers were given years of time to design and implement it.

Re: Gopher Wrangling: Effective error handling in Go

#112

Post by mirekrusin »

SmooL wrote: post #98
kaba0 wrote: post #91

Could someone explain why is Go so hyped? In my personal opinion it is just not a good language, and I think many judge it based on some false basis that it is somehow “close to the hardware” because it produces a binary. Like, the amount of time it is put next to Rust when the two have almost nothing in common.. It is very verbose, yet Java is the one that is called that, often by Gophers, which is much more concise…

1. It's opinionated, so there's often only one way of doings things. Largely, the "one way" is a good way, so people appreciate the forced consistency 2. It's simple. It is very easy to read and write. It is hard to shoot yourself in the foot. 3. It's powerful. They have a few core abstractions that compose well (generic io, http stuff). 4. It's fast. It runs fast because it's compiled, and it compiles fast because i…

You can shoot yourself in the foot with null pointers.

Re: Gopher Wrangling: Effective error handling in Go

#113

Post by konart »

mirekrusin wrote: post #112
SmooL wrote: post #98

Earlier quoted context omitted.

1. It's opinionated, so there's often only one way of doings things. Largely, the "one way" is a good way, so people appreciate the forced consistency 2. It's simple. It is very easy to read and write. It is hard to shoot yourself in the foot. 3. It's powerful. They have a few core abstractions that compose well (generic io, http stuff). 4. It's fast. It runs fast because it's compiled, and it compiles fast because i…

You can shoot yourself in the foot with null pointers.

You can find a gun to shoot yourself in the foot in any language.

Re: Gopher Wrangling: Effective error handling in Go

#114

Post by mirekrusin »

philosopher1234 wrote: post #103
andrewjf wrote: post #101

Earlier quoted context omitted.

I feel like a lot, if not all, has to do with the Google backing. Back when Go was announced, the company had _a lot_ of goodwill, and were envied by anyone doing software engineering. So, pretty much anything they did had an immediate following and base of engineers willing to blindly adopt whatever they did.

I don’t buy it. I can’t think of a single other Google backed programming language with anywhere near to the following of Go. I think Googles stamp gives it some legitimacy, but I think the much likelier explanation is that the values in Go and its design speak to frustrations a lot of people actually have. This thread is full of people arguing in favor of gos error handling. You can dismiss them all as cranks or she…

It does feel like mostly google backing (other aspects are important as well). Imagine if google would be behind ie. Crystal - you'd see it everywhere.

Re: Gopher Wrangling: Effective error handling in Go

#115

Post by preseinger »

awused wrote: post #94
randomdata wrote: post #90

Earlier quoted context omitted.

> This is trying to twist a weakness of Go's type system as a virtue. No. There is no discussion about type systems taking place here at all. The discussion is about patterns where the producer or the consumer is in control. Specifically, Result puts the producer in control. Idiomatic Go (T, error) sees the consumer in control. There is likely no language in existence that prevents you from choosing. You can write co…

This entire discussion is about the type system and how it interacts with the language. Go does not have sum types, so the producer cannot signal to the consumer what it can produce and what the consumer has to handle. The consumer in Go must pessimistically assume the all combinations of return values are possible, where in a language with a decent type system the possible cases can be enumerated and handled appropr…

> In Go, you are always forced by the language to return a value of type "A or B, including both or neither." The consumer isn't any more in control, it just has to guess whether "both or neither" are possible return types.

it does not have to guess

convention dictates either one or the other

is convention enough? is it roughly the same as compiler-enforced rules? you're free to say "no" but it is not like a guarantee

Re: Gopher Wrangling: Effective error handling in Go

#116

Post by janosd »

Go's error handling is a horrible mess:

1. It's easy to ignore returned errors without any compiler warnings. You have to rely on third party tools such as golangci-lint to report missing error handling.

2. Errors don't carry stack traces with them, you have to rely on third party libraries or custom errors to get that functionality and you will only get it for your own code, not in other libraries you are using.

3. It's unclear who should add context to error messages is it the caller or callee? Usually it gets skipped, leading to useless error messages.

4. Errors are untyped. If you want to decide based on error types, you have to use errors.Is or errors.As, which, surprise, is roughly as expensive computationally as panic-recover. (Source: I did a performance tests on this with Go 1.18) Go might as well add a simpler way to create exceptions. (I wrote a prototype library to that effect a while ago: https://github.com/APItalist/lang )

5. Error messages are too terse and hard to read when using the recommended semantic of "message (cause(cause(cause)))". I'd rather see stack traces, that's much more useful.

6. Most loggers are globally scoped and cannot be injected into code, leading to an all-or-nothing approach. It is not uncommon that you have 3-4 logging libraries as dependencies, which you need to configure separately (if you even can). Also, good luck securing this mess.

Re: Gopher Wrangling: Effective error handling in Go

#117

Post by awused »

randomdata wrote: post #109
awused wrote: post #94

Earlier quoted context omitted.

This entire discussion is about the type system and how it interacts with the language. Go does not have sum types, so the producer cannot signal to the consumer what it can produce and what the consumer has to handle. The consumer in Go must pessimistically assume the all combinations of return values are possible, where in a language with a decent type system the possible cases can be enumerated and handled appropr…

> This entire discussion is about the type system and how it interacts with the language. No. The discussion opened to say that Result is better than the pattern used in Go. In other words, dependent state is better than independent state. I said that dependent state puts the producer in control, while independent state puts the consumer in control and that there are pluses and minuses to each approach, with neither…

>The discussion opened to say that Result is better than the pattern used in Go

You are trying to paint a false dichotomy between Rust's Result and Go's (T, error). In reality the dichotomy is between sum types (which Result is a very simple case of) and languages without sum types, of which Go is one of a very small set. The key difference is that Result is available as an option in Rust/Haskell/Ocaml/etc, and I'm free to not use Result if it's not the right fit, where in Go the only option is to use a product type.

Result and the ? operator are shortcuts for concisely handling the very common case of handling "A or B, but never both or neither." If your producer doesn't fit that, you're free to define your own sum type. In Go, you are simply unable to represent these and must cover all four cases (or eight, or sixteen, or thirty-two, etc, as the function grows in complexity).

Nothing I'm saying is specific to Rust either, despite your appealing to conspiracies, and Rust's ideas are not new, not by decades. Haskell, Ocaml, Java, C++, typescript, etc, (even C with a bit of squinting) all have basic sum types and can encode "A or B, but never both or neither" and "A or B or both, but never neither" in their type systems and control flow in a way that Go cannot. Rust didn't pioneer the idea of a basic sum types, Go is just uniquely (among popular statically types languages from the last 50 years) incapable of representing them.

>So, in other words: Dependent state puts the producer in control, while independent state puts the consumer in control and that there are pluses and minuses to each approach, with neither being better, just different tradeoffs...?

No, this is complete nonsense. In Go, if I never write "return nonNilFile, nonNilError", the consumer cannot magic that into existence. Your entire position about languages being consumer controlled vs producer controlled is entirely nonsense. Consumers cannot rewrite the code of the functions they call.

Re: Gopher Wrangling: Effective error handling in Go

#118

Post by awused »

preseinger wrote: post #115
awused wrote: post #94

Earlier quoted context omitted.

This entire discussion is about the type system and how it interacts with the language. Go does not have sum types, so the producer cannot signal to the consumer what it can produce and what the consumer has to handle. The consumer in Go must pessimistically assume the all combinations of return values are possible, where in a language with a decent type system the possible cases can be enumerated and handled appropr…

> In Go, you are always forced by the language to return a value of type "A or B, including both or neither." The consumer isn't any more in control, it just has to guess whether "both or neither" are possible return types. it does not have to guess convention dictates either one or the other is convention enough? is it roughly the same as compiler-enforced rules? you're free to say "no" but it is not like a guarante…

>convention dictates either one or the other

Convention is just an educated guess.

>is it [convention] roughly the same as compiler-enforced rules?

No. The answer is no. I'm not only free to say "no," but if I'm honest and truthful I am compelled to say "no."

Re: Gopher Wrangling: Effective error handling in Go

#119

Post by saghm »

konart wrote: post #113
mirekrusin wrote: post #112

Earlier quoted context omitted.

You can shoot yourself in the foot with null pointers.

You can find a gun to shoot yourself in the foot in any language.

> It is hard to shoot yourself in the foot.

>> You can find a gun to shoot yourself in the foot in any language.

Sure, but finding that one isn't particularly hard, which is what GP was responding to

Re: Gopher Wrangling: Effective error handling in Go

#120

Post by skarlso »

This feels like it has been written by someone who recently started using the language, considering that the code in many places simply doesn't compile and has syntax errors or logical errors in it.

Many people coming into Go as a new language immediately start bickering about how they want their previous language features in Go rather than accept what Go has to offer and at least try to understand it. This is the equivalent of moving to another country and then refusing to integrate but being very vocal about how said country sucks.

I genuinely appreciate Go's error handling because it's clean and on the nose. It's not hidden behind weird syntax/values that you have to unpack. It's right in your face all the time. When you read the code, it reads cleanly and understandably, even for a beginner. They don't have to adapt to some weird combination of failures / unpacking/choosing something different when there is an error; you immediately see that there could be an error.

And regarding stack traces, wrapping errors will provide you with failure locations to the line code. You can have all sorts of nice output for errors you can later parse and identify.

I get that some people go into Go because of a shift in the company and have no choice; I feel you. For me, it was a life changer. I learned to love coding again after 15 years of writing Java Beans, Spring annotations, CreateMyFriggingObjectFactorySingletonBuilderFactoryBuilders.

Post reply on HN