Hacker News Reader

Comment by rsc | Hacker News Reader

FWIW, I wrote a short response here: https://twitter.com/_rsc/status/1146128393542492160

I want to flag especially that there is not, nor has there ever been, a plan to "push this through".

People consistently say error handling is problematic for them in Go. Overall I think people spend more time writing error checks than they should, and at the same time there are still too many mis-handled errors. We would like to see if we can find a way to make it both less work and more correct. Maybe we can, maybe we can't. The process is slow and needs to backtrack out of formerly-promising dead ends, and that's OK.

There's a very large amount of conversation right now around try, and that's good. Like I said in the tweets, community-wide discussions like this one are open source at its best.

View on HN

I think "try" is a terrible name, because it overloads try/catch which is very common usage these days but it's nothing like that. It's basically a error checking macro, so give it a new name.

Rust had the try! macro before which is similar, the name is fine I think.

> Overall I think people spend more time writing error checks than they should, and at the same time there are still too many mis-handled errors.

Care to elaborate on both points, or direct me somewhere I can learn more about these opinions? Thanks!

Why not allow call-by-name parameters to functions? That would enable library authors to build whatever error handling conveniences they wanted. This feature dates all the way back to ALGOL-60.

I think you're answering your own question there:

> That would enable library authors to build whatever error handling conveniences they wanted

What I want from a language - especially if it's, like Go, aimed at really big project - is for it to be opinionated and narrowed in options. That's Bill Kennedy's point as well, they're adding a language level feature so now there's one more way to do a very common thing. And when there's multiple ways to do something, they will all get used.

"But what about conventions and code reviews?", you might ask; that's cognitive overload that, if there was only one way, would never be a thing. I mean another feature of Go is that it enforces a certain standard (with tooling and formatters), so that as a development team you should never have to waste time and energy on discussing or arguing about formatting.

I'm not against changing how errors are handled now, as long as they're standardized and the One Way to do things.

I respect this position, but we must also recognise that it makes Go less of a general purpose language (as is often claimed) and more a domain-specific language (with the domain being systems/network programming).

Just curious, why a twitter thread response and not a blog post?

Reply on news.ycombinator.com