alt Hacker NewsEven if people in your example couldn't agree on a particular alternative, the outcome still is a less attractive area, maybe some will move out and fewer people move in. So, any solution would be better than the status quo - and they all would probably agree on that.
The lack of a good error handling story to a lot of people puts go in a mental trash bin of sorts. Similar (but different) reasons eg Java goes to a mental trash bin. I think leaving this issue unhandled will only make go look worse and worse in comparisons as the programming language landscape evolves. It might take 10 or 20 years but it'll always be unique in having "trash bin worthy" error handling. (this can perhaps be argued - maybe exceptions are worse, but at least they're standard).
Replies
In the analogy we might suppose everyone agrees that there is a problem and any solution is better than the status quo, but that's extremely unlikely in the case of Go. In my experience discussing this issue with Go users and critics, a lot of Go users find the status quo to be minimally chafing.
> The lack of a good error handling story to a lot of people puts go in a mental trash bin of sorts. ... It might take 10 or 20 years but it'll always be unique in having "trash bin worthy" error handling. (this can perhaps be argued - maybe exceptions are worse, but at least they're standard).
Remember that the context is syntactic error handling proposals, not proposals for error handling generally--the maintainers are saying they're only going to close syntax-only error handling proposals. While I have no doubt that there are lots of people who write of Go for its error handling syntax alone, I don't see any reason why a language community should prioritize the opinions of this group.
Additionally, while I have plenty of criticism for Go's error handling, I can't take "Go's error handling is 'trash bin worthy'" seriously. There are no languages that do error handling well (by which I mean, no implicit control flow and one obvious way to create errors with appropriate error context, no redundant context, clear error messages, etc). Go and Rust probably both give you the tools necessary to do error handling well, but there's no standard solution so you will have issues integrating different libraries (for example, different libraries will take different approaches to attaching error context, some might include stack traces and others won't, etc). It's a mess across the board, and verbosity is the least of my problems.
> So, any solution would be better than the status quo - and they all would probably agree on that.
The point is that people do not agree that any solution is better than the status quo. In my analogy, if redeveloping that plot of land is quite expensive in tax dollars, people will prefer it be left alone completely so that money can be spent elsewhere than have it squandered on a "solution" that does nothing for them.
Likewise in Go, adding language features has a quite large cost in terms of cognitive load, decision load, implementation cost, etc. After many many surveys and discussions, it's clear that there is no consensus among the Go ecosystem that any error handling strategy is worth that cost.