Hacker News Reader

Comment by rbtprograms | Hacker News Reader

Good on the Go Team listening to the community, I definitely saw more people against this feature than for it.

I hope they take another stab at improving error handling. I like Go a lot and do think error handling is one place it could use improvements.

View on HN

I didn't have particularly strong feelings towards this proposal (maybe just slightly against it) but it's probably important to note that people who are against it are generally much more vocal and make their voices are heard whereas those who like it just give it a thumbs up/tacit approval and keep it moving. Wish I knew how to accurately gauge the opinion of proposals from user communities.

I don't understand why anyone would be (strongly) against this proposal. If I understand it correctly, it's just a shortcut. That is, the old (existing) way would still work. If anyone didn't like "try", well, don't write your code that way.

It would also appear to be amenable to an automated tool that would convert to or from try-style.

Given that, why would people have strong feelings against? Because they think go needs something better, and if this passes, they'll never get it?

Go is all about having one way to do something. Small number of highly orthogonal features.

Sounds like python.

Python 2.1 or 2.2, sure

Damn right, these days it's about as true as G not doing evil.

The argument seemed to be that it would split the codebase out there by style and that would be bad.

This is the prime example of what makes Go different than most other languages. They don't put things in attached with the argument "if you don't like it, you don't have to use it." Go is a language designed to be written and read by teams. You don't like try. Bob does. Bob writes code that uses it. You still have to read it.

I kind feel that declining try/catch is aligned with the baleful eye cast on Bob. The language designers think Bob is going to use try/catch to foist error handling on someone else or for later which never comes. And so error handling will then end up slightly broken to totally broken. So they'd rather when Bob's writes code with error paths that he to deal with that then and there. Not 'elsewhere' 'later' or make it 'someone else's problem'

> They don't put things in attached with the argument "if you don't like it, you don't have to use it."

I agree with this. I think many Go users like Go because of its simplicity that prevents unnecessary bikeshedding so prevalent in other languages.

> If anyone didn't like "try", well, don't write your code that way.

I don't have a strong opinion on try, but this is not a good philosophy. Whatever you include in a language will get used and will get abused if it can be abused.

This is mostly why there is a part of Golang users who do not want generics. Look at codebases in C++ and you can see the clarity cost of adding generics in a codebase.

> Because they think go needs something better, and if this passes, they'll never get it?

More that they will never get rid of it, even after something better comes along. Same reason Go has been careful about adding generics. There have been many generics proposals over the years. Any one of them – or even all of them – could have been implemented, but all of them had faults that the Go maintainers did not way to forever saddle the language with even when a better way to do generics comes along.

Unfortunately, they saddled the language with the lack of generics, which has a nonzero cost, too.

Worse yet, Go community may develop, or already has, a taste to the lack of genetics. When a really really good proposal comes along, and is implemented, it may produce a Python 2/3 rift with the existing code bases, or not be accepted at all because of this.

I would argue that the definition of a “really really good proposal”, is one that fits in to the language so naturally that such a rift/disagreement would not exist. If you can’t imagine such a proposal, it’s precisely because it is be very hard (maybe impossible) to do this to Go, as it’s written today.

IMO, this is because with generics (and we even get shades of this in error handling), we are running into limits with the type system itself. Coming up with a proposal that’s universally acceptable for generics would probably require a bottom-up (and potentially compatibility-breaking) refactor of the type system. Would that be this worth the effort? Eventually, probably, yes, because you might unlock other benefits for free (compilation time, GC efficiency, etc.).

Today, however, there are many lower hanging & valuable fruit to pluck. In the meantime, new languages with better type systems are invited to capture market share. :)

It's just a shortcut... in a language that has very few shortcuts, very few abstractions whatsoever, and certainly none that look or behave like try would.

It complicates the language for little gain. It's good that they punted on this for now.

Reply on news.ycombinator.com