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.
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.
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.
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 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.
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.
@programming.dev
This is a community dedicated to the go programming language.
Useful Links:
Rules:
- Posts must be relevant to Go
- No NSFW content
- No hate speech, bigotry, etc
- Try to keep discussions on topic
- No spam of tools/companies/advertisements
- It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
go to feed...
@programming.dev
This is a community dedicated to the go programming language.
Useful Links:
Rules:
- Posts must be relevant to Go
- No NSFW content
- No hate speech, bigotry, etc
- Try to keep discussions on topic
- No spam of tools/companies/advertisements
- It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
go to feed...
after much deliberation, we've decided to do absolutely nothing
lol, lmao even
save