I see it as a pretty clear sign of dysfunction in the project unfortunately. Being unable to reach an actionable decision to improve on the most disliked part of the language (I’m personally ambivalent, I find that the repetitive error handling quickly fades into the background, but I also really love the ? operator in rust) is a bad sign.
firelizzard@programming.dev
on 08 Jun 02:43
collapse
So you think they should have picked a solution that pissed off a large portion of the user base, just so they could say they “solved” it? The entire problem is that they tried, repeatedly, and none of their proposals had wide support.
They did pick a solution that pisses off a large portion of their user base, that’s exactly what choosing to do nothing means when attempting to fix the most complained about issue with your language. Doing nothing is a choice too after all.
firelizzard@programming.dev
on 08 Jun 03:56
collapse
If every possible action is going to piss off a large portion of the user base, doing nothing is the sanest option IMO.
How does that logically follow? It seems obvious to me that if every choice is going to piss people off then you simply disregard that as a factor and then make the best choice possible. If that had been their decision process and status quo was the best choice on the merits then that would be perfectly reasonable. That was not, however, the process they described in their blog, instead they remained entirely focused on the one issue that they should have ignored.
Especially when compared to generics. They spent so much time on that, and for what? They say themselves that most users are unlikely to use or encounter it. Personally, I’ve found Go generics to be useless in most of the cases they’d be handy, because of the limitation about methods being required to match struct specifiers. Everywhere else I’ve used them, I could have easily worked around them and probably come out with more clear code.
Error syntax jockied with generics for first place user concern for years, and they chose to roll out the change that would have a lesser impact on user convenience and code readability.
Bitter Ruaidhrigh is bitter.
firelizzard@programming.dev
on 08 Jun 02:45
collapse
They weren’t looking for universal approval. They were looking for widespread/majority approval.
I personally welcome this decision. I am fairly happy with the current syntax and I enjoy the explicit “does what it says” nature of Go code. None of the proposed alternatives would have made error handling more robust, they were pure syntactic sugar with no nutritional value.
Saying no to multiple proposals when you feel that the status quo is better can be difficult to do and I am happy that the Go team is able to make these kinds of decisions.
FizzyOrange@programming.dev
on 08 Jun 12:41
collapse
I agree. The syntax for useless error handling is indeed more verbose than Rust (a whole if block Vs a single ?) but the difference when you actually do proper error handling and add a useful context message is much smaller.
You could argue that’s a good thing because it encourages writing proper error handling code.
I’ve seen plenty of Rust code with only? which leads to really bad error messages. I’ve seen Rust errors in complex programs that are literally just Could not open file or directory - no context, no filename. Go definitely has better error messages on average.
That said I still prefer Rust’s error handling, and writing Rust in general.
namingthingsiseasy@programming.dev
on 08 Jun 01:46
nextcollapse
The lesson learned (in my opinion) is that if you’re going to design a language where errors need to be handled explicitly, you need to design the language from the ground up to support monadic error handling syntax. At this point, it seems too late to add it to Golang. What a shame - it could have been so much better of a language without this flaw.
It’d be nicer to see tagged unions first, with the machinery for those, and then take steps to provide a semantic fix for error handling.
SilverShark@programming.dev
on 12 Jun 13:37
collapse
Might be that I’m so used to the status quo, but I like the current way Go handles errors very much.
I do understand that there is a lot of code repetition, and many lines of code in a function will go for error handling instead. But I also feel that when we don’t focus too much on happy path and do handle errors, we end up with a lot more work on it then on the happy path anyway, so the number of lines that go for error handling do correlate with the amount of effort we take there anyway.
I think in errors, a thing that might be improved is what to return on the “normal/happy path” side when there is an error. Suppose a string that returns a string and an error. If there is no error, I get some string and nil on the error. But if there is an error, I still need to return a string (an empty one, but still). If it’s a struct being returned without being a pointer, then it still needs to be returns. Many feel this is a weird aspect about the language.
threaded - newest
after much deliberation, we’ve decided to do absolutely nothing
lol, lmao even
Which is completely reasonable. Insanity is trying the same thing over and over and expecting different outcomes.
It’s not like they tried nothing and are all out of ideas; they tried a lot and nothing stuck so far.
I see it as a pretty clear sign of dysfunction in the project unfortunately. Being unable to reach an actionable decision to improve on the most disliked part of the language (I’m personally ambivalent, I find that the repetitive error handling quickly fades into the background, but I also really love the ? operator in rust) is a bad sign.
So you think they should have picked a solution that pissed off a large portion of the user base, just so they could say they “solved” it? The entire problem is that they tried, repeatedly, and none of their proposals had wide support.
They did pick a solution that pisses off a large portion of their user base, that’s exactly what choosing to do nothing means when attempting to fix the most complained about issue with your language. Doing nothing is a choice too after all.
If every possible action is going to piss off a large portion of the user base, doing nothing is the sanest option IMO.
How does that logically follow? It seems obvious to me that if every choice is going to piss people off then you simply disregard that as a factor and then make the best choice possible. If that had been their decision process and status quo was the best choice on the merits then that would be perfectly reasonable. That was not, however, the process they described in their blog, instead they remained entirely focused on the one issue that they should have ignored.
I liked the thorough explanation of the decision process, but I think universal approval is a paralysing requirement. This risks stagnation.
Especially when compared to generics. They spent so much time on that, and for what? They say themselves that most users are unlikely to use or encounter it. Personally, I’ve found Go generics to be useless in most of the cases they’d be handy, because of the limitation about methods being required to match struct specifiers. Everywhere else I’ve used them, I could have easily worked around them and probably come out with more clear code.
Error syntax jockied with generics for first place user concern for years, and they chose to roll out the change that would have a lesser impact on user convenience and code readability.
Bitter Ruaidhrigh is bitter.
They weren’t looking for universal approval. They were looking for widespread/majority approval.
I personally welcome this decision. I am fairly happy with the current syntax and I enjoy the explicit “does what it says” nature of Go code. None of the proposed alternatives would have made error handling more robust, they were pure syntactic sugar with no nutritional value.
Saying no to multiple proposals when you feel that the status quo is better can be difficult to do and I am happy that the Go team is able to make these kinds of decisions.
I agree. The syntax for useless error handling is indeed more verbose than Rust (a whole if block Vs a single
?) but the difference when you actually do proper error handling and add a useful context message is much smaller.You could argue that’s a good thing because it encourages writing proper error handling code.
I’ve seen plenty of Rust code with only
?which leads to really bad error messages. I’ve seen Rust errors in complex programs that are literally justCould not open file or directory- no context, no filename. Go definitely has better error messages on average.That said I still prefer Rust’s error handling, and writing Rust in general.
The lesson learned (in my opinion) is that if you’re going to design a language where errors need to be handled explicitly, you need to design the language from the ground up to support monadic error handling syntax. At this point, it seems too late to add it to Golang. What a shame - it could have been so much better of a language without this flaw.
It’d be nicer to see tagged unions first, with the machinery for those, and then take steps to provide a semantic fix for error handling.
Might be that I’m so used to the status quo, but I like the current way Go handles errors very much.
I do understand that there is a lot of code repetition, and many lines of code in a function will go for error handling instead. But I also feel that when we don’t focus too much on happy path and do handle errors, we end up with a lot more work on it then on the happy path anyway, so the number of lines that go for error handling do correlate with the amount of effort we take there anyway.
I think in errors, a thing that might be improved is what to return on the “normal/happy path” side when there is an error. Suppose a string that returns a string and an error. If there is no error, I get some string and nil on the error. But if there is an error, I still need to return a string (an empty one, but still). If it’s a struct being returned without being a pointer, then it still needs to be returns. Many feel this is a weird aspect about the language.