Hacker News Reader

To take this analysis another level deeper: what has happened here is a classic example of bikeshedding — and, worse, fostering bikeshedding.

Everyone feels equipped to have an opinion about "what should be the syntax for an obvious bit of semantics." There's no expertise required to form such an opinion. And so there are as many opinions on offer as there are Go developers to give them.

Limit input on the subject to just e.g. the people capable of implementing the feature into the Go compiler, though, and a consensus would be reached quickly. Unlike drive-by opinion-havers, the language maintainers — people who have to actually continue to work with one-another (i.e. negotiate in an indefinite iterated prisoner's dilemma about how other language minutiae will work), are much more willing to give ground "this time" to just move on and get it working.

(Tangent: this "giving ground to get ground later" is commonly called "horse trading", but IMHO that paints it in a too-negative light. Horse trading is often the only reason anything gets done at all!)

> I love inaction as a default decision

The thing is, inaction is not simply "not taking an action"; Inaction is taking active action of accepting the current solution.

> I doubt that the best proposals are so horrible for some people that they’d hold a grudge and leave Go.

But people may leave go if they constantly avoid fixing any of problems with the language. The more time passes, the more unhappy people become with the language. It will be a death by a thousand cuts.

I love go. But their constant denial do fix obvious problems is tiring.

> But people may leave go if they constantly avoid fixing any of problems with the language.

For many people the current Go error handling just isn't a problem. Some even prefer it over the overengineered solutions in other languages. This brutalist simplicity is a core design feature I personally enjoy the most with Go, and forcing me to use some syntax sugar or new keywords would make it less enjoyable to use. I also don't think that generics were a net benefit, but at least I'm not forced to use them.

Go is a cemented language at this point, warts and all. People who don't like it likely won't come around if the issues they're so vocal about were fixed. It's not like there's a shortage of languages to choose from.

The article seems to admit that a `try` keyword restricted to statements / assignments only would combine the best parts and alleviate the major concerns of both the `try` and `?` proposals. It reads as though the concept has not been seriously discussed due simply to exhaustion.

Pro and con. It hinders progress, but it can also arrest the "enshittification" of a language that takes place when it slowly adds complexity and features and support for whole paradigms.

Python does offer a lot more utility for the expert these days, but it also went from the maxim of "There is one obvious way to do it" to having 5-6 ways to format strings, adding more things to be familiar with, causing refactoring churn as people chase the latest way to do it, etc.

I'm a C++ developer. I wouldn't want to go back to older versions of the language, but it's also very hard to recruit any newer programmers into using it willingly, and the sheer amount of stuff in it that exists concurrently is a big reason why.

I agree with you in principle, but this isn't like T-strings or C++ concepts. We're talking about a feature that has become infamous for it's lack of syntax in Go. A feature that every other major language has some syntax for.

It's true that Google is "design by committee" and consensus driven, but the Go team has been particularly obtuse about things, seemingly not understanding which opinions are valid and which are confused.

Yeah this bugs me about the decision process too, but Go places more importance on backwards compatibility and stability than most other languages so it does align with their values. I'm not the biggest fan of Go but its nice having a language around that favors simplicity and stability.

> I love inaction as a default decision, but sometimes a decision is better than nothing. It reminds me of a groups when you can’t decide what to have for dinner – the best course of action isn’t to not eat at all, it’s to accept that everyone won’t be happy all the time, and take ownership of that unhappiness, if necessary, during the brief period of time when some people are upset.

Invalid comparison - eating one foodstuff or another affects a few people for a few hours. Significantly changing a popular language affects every single user of it forever.

But not changing has the same effect, also "forever" (and it also affects many non-users who could become users), so this is not a good argument for doing nothing

> sometimes a decision is better than nothing

Not in this case. The most popular Go proposal/issue of all times was 'leave "if err != nil" alone': https://github.com/golang/go/issues?q=is%3Aissue%20%20sort%3...

If go had started out having different syntax for error handling, would these same people request that it change to what go currently does? Or is this just resistance to change, and wanting to keep what they are used to?

I suspect it is the latter.

The second most popular issue was adding generics. So it's probably not a resistance to change.