Hacker News Reader

Comment by drivebyops | Hacker News Reader

Great that they listened to the community

Its a pity that they listened to the members of the community that was opposed to try. I was a massive fan of try or anything else that would prevent me writing the same boilerplate code.

I feel some in the go community have become convinced that the “go way” is to write the same code over and over again.

I think try is jumping the gun.

Implementing try now is splitting the community and introducing what will likely be new technical debt. It doesn't fundamentally change things, it only makes the language more complicated in a way that's both weird* and likely to become obsolete once generics are a thing.

They should focus on xerrors for now and wait until generics are implemented and try again.

* weird as in there are no macros and there's no other language construct that behaves like this so it's a totally unique and new thing for Go

I expect that once we get generics we are going to get a host of differently implemented variations of the error monad none of which is used by the standard library.

Which I think is worse then try.

In a broader sense I am deeply irritated by the part of the go community's culture that seemingly sees any effort to make go more "don't repeat yourself" to be making it more complex. With no acknowledgment that avoiding complexity in the language isn't a free lunch, it comes at the cost of complexity in the code written, the ecosystem and libraries.

I share your irritation and I'm a bit worried about the language future because of this conservatism.

They listened to the part of the community that agrees with you.

I'm "community" and I would prefer to have `try()` than not to have. They didn't listen to me.

"Listened to" is colloquial for "engaged with". They engaged with people who represented the `try()` option and declined to implement it.

It is impossible to implement every proposal their ears listened to so obviously that's not what listened means.

And they also "fast tracked" the decline "ahead of schedule".

They didn't listen to the community. It was not a democratically driven decision. They gathered feedback from the community, weighed it in, discussed it and took a decision considering all aspects. It's not like they listened to whatever had the most votes on Github. At least I'd like to believe they didn't.

I right there with you. I would have loved try() even as a stop-gap to something better.

The community is self-selected for the ability to tolerate Go-style error handling and the Go philosophy generally. It's not a philosophy for me.

Reply on news.ycombinator.com