3 ms·

Part of the issue is that when people evaluate a language, they do it in a safe setting: a toy problem, a coding challenge, whatever. In those cases, handling e

Part of the issue is that when people evaluate a language, they do it in a safe setting: a toy problem, a coding challenge, whatever. In those cases, handling error scenarios is annoying and just slows you down. But when the rubber meets the road and you are trying to write code that consistently works, Go’s verbose but simple error system is really an asset. I used to write a lot more Go and have been writing Python, and I miss Go’s style terribly. Errors as values, the build/package tools, gofmt, and the consistent quality of the standard library are what I miss most.

rob74 3y ago
Well, you can simply write "result, _ = function()" to ignore the error for the time being, but that underscore will sit there nagging you to handle the error properly...
- pdimitar 3y ago
  There's also tooling you can run that scans for such code and points it out to you. I've seen people integrate such tools in their CI/CD as well.
- Thaxll 3y ago
  You can ignore errors in most languages, rust included.
ajross 3y ago
That's true, but it's also true than when people evaluate a problem, they tend to want to imagine the maximally scaled, most robust, "final" version thereof. And so they tend strongly to solve the wrong problem in practice, often in inappropriate languages. Now, for the record, I happen to love Go and agree with the author about its error handling paradigms. That said, I like the python script at the top of the article a lot more still, because the problem being presented is a routine kind of thing that needs to be solved on a routine, ad-hoc basis a zillion times every day. And we don't want people writing the 80 line Go code to do that, we want them doing it in python. Basically exception-style "I don't know what went wrong, just that it failed, let the user sort it out[1]" code is the correct solution to probably 90% of workaday problems we face. You fall through to precise error handling (and/or frameworks like in Rust that force the handling syntactically) only when you need to write code that survives in the absence of a traditional "operator". But most code doesn't run that way! [1] In this case, the problems are likely bad filenames, bad URL, server down, etc... If your developers are running this script themselves, they'll figure that out on their own.
- spenczar5 3y ago
  To me, the advantage isn’t so much that you have to handle every error. It’s that you can see, with certainty, which functions and methods are error-free. I even find myself encouraged to write functions that cannot return errors. You don’t get anything similar in exception-based systems. Of course, algebraic error types share this advantage. They are good too.

rob74 3y ago

Well, you can simply write "result, _ = function()" to ignore the error for the time being, but that underscore will sit there nagging you to handle the error properly...

pdimitar 3y ago
There's also tooling you can run that scans for such code and points it out to you. I've seen people integrate such tools in their CI/CD as well.
Thaxll 3y ago
You can ignore errors in most languages, rust included.

ajross 3y ago

That's true, but it's also true than when people evaluate a problem, they tend to want to imagine the maximally scaled, most robust, "final" version thereof. And so they tend strongly to solve the wrong problem in practice, often in inappropriate languages. Now, for the record, I happen to love Go and agree with the author about its error handling paradigms. That said, I like the python script at the top of the article a lot more still, because the problem being presented is a routine kind of thing that needs to be solved on a routine, ad-hoc basis a zillion times every day. And we don't want people writing the 80 line Go code to do that, we want them doing it in python. Basically exception-style "I don't know what went wrong, just that it failed, let the user sort it out[1]" code is the correct solution to probably 90% of workaday problems we face. You fall through to precise error handling (and/or frameworks like in Rust that force the handling syntactically) only when you need to write code that survives in the absence of a traditional "operator". But most code doesn't run that way! [1] In this case, the problems are likely bad filenames, bad URL, server down, etc... If your developers are running this script themselves, they'll figure that out on their own.

spenczar5 3y ago
To me, the advantage isn’t so much that you have to handle every error. It’s that you can see, with certainty, which functions and methods are error-free. I even find myself encouraged to write functions that cannot return errors. You don’t get anything similar in exception-based systems. Of course, algebraic error types share this advantage. They are good too.