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.
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 feel some in the go community have become convinced that the “go way” is to write the same code over and over again.