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

171–180 of 310 posts

Re: Gopher Wrangling: Effective error handling in Go

#171

Post by stephen123 »

kinghajj wrote: post #129
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…

https://en.wikipedia.org/wiki/Worse_is_better Go is a language made by Googlers, so its design helps with Google problems. And many of Google's problems are ones of scale. * Go is straightforward to read. Any reasonably-competent college graduate should have little trouble understanding it and be able to become productive quickly. * Go compiles into completely static binaries. You don't have issues like "oops, the bu…

"completely static" has a gotcha though. I was getting segfaults yesterday because libc was removed from my docker image.

I had to add `CGO_ENABLED=0`

Re: Gopher Wrangling: Effective error handling in Go

#172

Post by philozzzozzz »

za3faran wrote: post #44

The provided examples highlight exactly why error handling in golang is verbose, error prone, and lacks context. Do people really not care about stack traces?

A descriptive error message beats any stack trace. A stack trace does not actually tell you anything that's particularly interesting, there is a ton of irrelevant information and it's generally missing the values bound to the arguments and variables.

Re: Gopher Wrangling: Effective error handling in Go

#173

Post by stephen123 »

za3faran wrote: post #145
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…

I'm strongly convinced that the google brand name gave it a big push. Its predecessor (Limbo if I recall correctly) went nowhere. It did bring uncolored async to the mainstream, but as in typical golang fashion, it was very verbose and error prone. Java learned the right lessons and I'm quite excited to see their structured concurrency approach. No need to pass channels and contexts everywhere to manually manage hier…

Yea, I find go's concurrency very error prone compared to something with futures.

I've even got a library for using futures in Go. https://stephenn.com/2022/05/simplifying-go-concurrency-with...

Re: Gopher Wrangling: Effective error handling in Go

#174

Post by aniforprez »

notTooFarGone wrote: post #121
janosd wrote: post #116

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

Calling a linter thirdparty in Go is really disingenuous. Like you install go in your favourite IDE and it's batteries included. It's part of the standard set.

golangci-lint does not come batteries included. It is a third party library. Saying it's "part of the standard set" is really disingenuous

Re: Gopher Wrangling: Effective error handling in Go

#175

Post by adezxc »

za3faran wrote: post #142
konart wrote: post #136

Earlier quoted context omitted.

In my personal opinion it's a great language to solve problems _I_ have to deal with in course of my work. Can I solve them with Java? Sure. Difference is go does not have the complexity you can find in Java and quite opinionated. So you don't have to spend as much time working with the language inself and can focus on getting the job done. Go is not as expressive and some other languages and does not have the same a…

Could you elaborate on exactly what complexity in Java you're referring to? By having an overly simplistic language, you end up pushing more complexity onto the programmer and into the code base. There is no free lunch. I find it much more sane to solve and express code in Java. You get terser, more to the point code that reflects the underlying logic more clearly, compared to having to read many lines or pages to un…

It is frustrating to read Java code. I don't want to understand your abstractions or class definitions like final, static and whatever.

I don't want to learn about Gradle or Maven to understand how a package is working, I'd rather do it in code.

Consider even the current "Hello, world" example in Java (Yes, I know about the proposal about simplifying it), it is tedious, why would I need to understand public/private and classes before launching a simple program?

I fully agree it is a terrific piece of software, especially for industry-grade applications, yet it just isn't attractive.

Main thing IMO, is that you can start out writing pretty good Go code after 24 hours and just improve on your skills as a general programmer. With Java, after a few months you would still need to know about some methods or OOP tips/tricks, design patterns etc. to become proficient.

Re: Gopher Wrangling: Effective error handling in Go

#176

Post by nbraxf100 »

janosd wrote: post #116

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

The error handling is second nature to anyone who has done C or Unix programming. It just feels dirty not to check for an an error.

This is one part I like about Go.

Re: Gopher Wrangling: Effective error handling in Go

#177

Post by bombolo »

kinghajj wrote: post #129
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…

https://en.wikipedia.org/wiki/Worse_is_better Go is a language made by Googlers, so its design helps with Google problems. And many of Google's problems are ones of scale. * Go is straightforward to read. Any reasonably-competent college graduate should have little trouble understanding it and be able to become productive quickly. * Go compiles into completely static binaries. You don't have issues like "oops, the bu…

> Go compiles into completely static binaries

* sometimes.

It can also dynamically link stuff on occasions, depending what options you use.

Re: Gopher Wrangling: Effective error handling in Go

#178

Post by aniforprez »

preseinger wrote: post #156
za3faran wrote: post #137

Earlier quoted context omitted.

Nothing is preventing the code from returning both at the same time. I've seen code (including in the standard library) that returns both an error and a return value. In a language with disjoint unions, such cases would be encoded properly.

convention prevents it and in the case where returning both is OK, then documentation makes that clear this is not difficult

Convention in no way prevents anything. Convention is simply that. People are free to not follow convention when nothing is enforcing it. You frequently see juniors, who may be brand new to the language, making mistakes with conventions. If I'm supposed to depend on the vagaries of some accepted standard that is only documented in text then it is less than useless in the real world

Re: Gopher Wrangling: Effective error handling in Go

#179

Post by nbraxf100 »

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…

I'm not a fan of the syntax either. My impression is that "close to the hardware" is not the selling point, but "close to Unix" is.

If you view the language as a safer super shell script, it becomes more obvious.

Go was hyped in the beginning, but I get the impression that now it isn't. The most persistently hyped language here is Python. Fortunately, we see more Elixir, Ruby and Go posts lately.

Re: Gopher Wrangling: Effective error handling in Go

#180

Post by dthul »

kitd wrote: post #161
lolinder wrote: post #12

Earlier quoted context omitted.

The killer feature of Rust's Result isn't actually the monad itself, it's the ? operator. Being able to concisely say "if there's an error, bail out by returning it" gets you pretty close to exception-level convenience with just a bit more explicit syntax showing where an error might come from.

I've not used Rust. Do you get to add context at the point of bailing?

That depends on the type you use to represent errors. A more "fancy" error type will allow you to add context / backtraces / whatever you want, while a simpler error type, for example just an error code, does not. (The error type is the E in Result).
Post reply on HN