Hacker News Reader

Comment by simias | Hacker News Reader

My main small day-to-day usability gripes with C are lack of type inference, lack of destructors and terrible ergonomics for error handling. Go solves two out of three, but it really dropped the ball hard on error handling which is very disappointing IMO.

Things like generics and garbage collection involve some deep tradeoffs, so I get Go's take on them, even if I don't necessarily agree with it. On the other hand IMHO Go's crappy error handling boilerplate is not something I find acceptable in a modern programming language.

View on HN

I agree that the error handling is terrible, but I'm not sure how much better it could be without generics.

For me, the gold standard in error handling is Rust, where the type system simply does not allow you to ignore errors. This means that the existence of error handling is checked at compile time. Of course, this doesn't mean your error handling is _good_, but I think that's beyond any language design to enforce.

But the Rust system is entirely built around a generic Result type, where both the non-error result (an int, string, struct, etc.) _and_ the error type itself are both generic.

the type system simply does not allow you to ignore errors

Which is excellent.

the gold standard in error handling is Rust

Really? What library is in fashion this week for handling errors? I have so far used vanilla Rust, error-chain and Failure.

Seems like there is so much choice to improve the gold standard:

https://blog.yoshuawuyts.com/error-handling-survey/#librarie...

Go uses compiler magic to have effectively generic collections, why not hardcode a Result type in the same fashion? It's not very elegant, but it's pragmatic and error handling is important enough that it may well warrant it.

Yeah, that's a fair point. I imagine this could be better than what's there now.

How would you design the error handling?

Personally I'm glad Go has stayed out of exceptions (panics don't count), at scale it's so much easier to reason about flow.

Monadic error handling like in ML work-alikes, Rust etc. would be a good start. Adopt:

• https://github.com/rebeccaskinner/gofpher

• https://speakerdeck.com/rebeccaskinner/monadic-error-handlin...

I've been talking to the local Go user group. No one even knows about that concept. This continues a pattern of general ignorance/lack of looking beyond one's horizon I've noticed.

The error handling feels deeply wrong to me too. I love the explicitness and how hard it is to ignore errors - all languages should make it so easy to expect and handle potential errors - but other features (or lack thereof) of the language make it so you can’t handle any of it in concise or sane ways. Code is plastered with the same boilerplate, everywhere, always. It makes up a significant mount of all Go code.

Reply on news.ycombinator.com