3 ms·

Most discussions of language features immediately fall into the politician's syllogism: https://en.wikipedia.org/wiki/Politician%27s_syllogism https://en.wikip

by evmar 1y ago

Most discussions of language features immediately fall into the politician's syllogism: https://en.wikipedia.org/wiki/Politician%27s_syllogism https://en.wikipedia.org/wiki/Politician%27s_syllogism I appreciate the Go language's general sense of conservatism towards change. Even if you're not a fan of it, I think it's admirable that there is a project staking out a unique spot in the churn-vs-stability design space. There are plenty of other projects that churn as fast as they can, which also has its pros and cons, and it's great to be able to see the relative outcomes. PS: it's kind of hilarious how the blog post is like "there are hundreds of proposals and miles of detailed analysis of these", vs the commenters here who are like "I thought about this for five minutes and I now have an idea that solve everything, let me tell you about it".

mseepgood 1y ago
Sometimes doing nothing is the right thing to do. (Quote from Until Dawn) Go chose not to change the error handling - Nature remained in balance.
ummonk 1y ago
I'd happily come up with criticisms of any specific proposal and bikeshed it, but any one of these proposals would be preferable to the status quo. I'd understand if they decided they needed more time to continue iterating on and analyzing proposals to find the right solution, but simply declaring that they'll just suspend the whole effort because they can't come to a consensus is rather infuriating.
- sa46 1y ago
  “Simply declaring” is inaccurate description of the Go team’s decision. The team built several proposals, reviewed dozens more, and refined the process by gathering user feedback in multiple channels. The Go team thoroughly explored the design space for seven years and did not find community consensus.
  - ummonk 1y ago
    There are two possibilities. 1) There isn't consensus that improved syntax for error handling is needed in the first place. If that is the case, they should just say so, instead of obfuscating by focusing on the number of proposals and the length of the process. 2) There is consensus about a need for improved error handling syntax, but after seven years of proposals they haven't been able to find community consensus about the best way to add said syntax. That would mean that improved syntax for error handling is necessary, but the Go team is understandably hesitant to push forward and lock in a potentially inferior solution. If that is the case, then would be reason to continue working on improved syntax for error handling, so as to find the best solution even if it takes a while.
deleted 1y ago
[deleted]

by evmar 1y ago

mseepgood 1y ago

Sometimes doing nothing is the right thing to do. (Quote from Until Dawn) Go chose not to change the error handling - Nature remained in balance.

ummonk 1y ago

I'd happily come up with criticisms of any specific proposal and bikeshed it, but any one of these proposals would be preferable to the status quo. I'd understand if they decided they needed more time to continue iterating on and analyzing proposals to find the right solution, but simply declaring that they'll just suspend the whole effort because they can't come to a consensus is rather infuriating.

sa46 1y ago
“Simply declaring” is inaccurate description of the Go team’s decision. The team built several proposals, reviewed dozens more, and refined the process by gathering user feedback in multiple channels. The Go team thoroughly explored the design space for seven years and did not find community consensus.
- ummonk 1y ago
  There are two possibilities. 1) There isn't consensus that improved syntax for error handling is needed in the first place. If that is the case, they should just say so, instead of obfuscating by focusing on the number of proposals and the length of the process. 2) There is consensus about a need for improved error handling syntax, but after seven years of proposals they haven't been able to find community consensus about the best way to add said syntax. That would mean that improved syntax for error handling is necessary, but the Go team is understandably hesitant to push forward and lock in a potentially inferior solution. If that is the case, then would be reason to continue working on improved syntax for error handling, so as to find the best solution even if it takes a while.

deleted 1y ago

[deleted]