Comment by vlovich123 9 days ago
I think you missed my complaint was that unlike more modern languages like Rust, Go has way too much boilerplate for error handling and not only does it not have error chaining via a `?` operator, it doesn’t even force you to check the error meaning I’m sure there’s plenty of missed error checks in production code leaving all sorts of vulnerabilities lying around. The package you linked in no way addresses what I wrote.
You’d really like the C community. They like to say things like “although I do find the setfaults annoying, it really makes me think carefully about memory ownership and layout”. The problem is that if you don’t have a consistent way to accomplish a task correctly, something like errors that could happen a nearly every function call, then you’re very likely to make a mistake. Coupled with that, most people ignore testing for error conditions or simulating errors, so the error handling has a very high likelihood of having bugs.
> Coupled with that, most people ignore testing for error conditions or simulating errors, so the error handling has a very high likelihood of having bugs.
Er, is Rust any different in that regard? As I said, I tend to think the `?` operator would make that worse, as the error path is so much less visible. In Golang if you don't test your error path, at least it will be listed as having no coverage -- is the same thing true in Rust?
The `?` operator is even worse than that as it leaks implementation details by default (the default you are undeniably going to lean on if testing/simulating error cases is more than you can handle), which is going to make someone's life a miserable hell when requirements change in the future.
But it seems most programmers here are only around for the MVP and are content to let the future of maintaining their garbage be someone else's problem. Which, I expect, is also the fundamental aversion they have to Go, which is trying to create a world where you still want to work on the same codebase in 30 years.
Not that Go is perfect. It most certainly isn't. But you are going to spend more time obsessing over things that aren't even all that important in practice when your "launch and dash" lifestyle is being threatened.
Rust: this `Result` may be an `Err` variant, which should be handled.
I am not at all a fan of Rust but dissing the `?` operator and the compilers error/warning messages regarding error handling and somehow thinking Go is superior here when its objectively not is "inconsistent with reality"
> The problem is that if you don’t have a consistent way to accomplish a task correctly
I know of no programming language that provides a consistent way to deal with values correctly, if the venerable if statement (or whatever is equivalent) is not it.
What is this magical fairy language that you speak of or envision?
I've been interested in learning more about Rust, but so far haven't had a project that seemed like it'd be worth learning a whole new language structure.
So, I was responding to my _understanding_ of what you had written, which apparently didn't adequately explain what you sought to those who haven't seen the thing you were trying to reference.
I do occasionally use a helper function in golang like 'nilOrPanic()' which if it's given an Error type that isn't nil causes a panic(); which isn't so useful outside of development or toy exercises.
A language like Rust makes the Error and Option types first-class. It’ll be a compiler warning (or error? Don’t remember right now) if you ignore the return from a function that returns one of these. Go requires a separate linter and relies on uncaught variables. Minor distinction but important one because defaults matter.
If you want to panic on error/option (i.e. you don’t think it’s going to happen), you add an exclamation mark after the error. If you want to unwrap but propagate the error effortlessly, add a question mark. This syntactic sugar is a pretty common ideas at this point not unique to Rust. What is a bit more unique is that Error and Option are sum types. This means that you can’t just access the value without unwrapping them somehow and unwrapping requires you to either handle the error by a match or conditional statement, propagate (?), or panic (calling .unwrap() function). But you have to make that decision and can’t ignore it so while you have to think about what you want the error handling to look like, you can’t ever accidentally forget (& since mostly you forward, ? Makes things easy even if you need to bridge different error types).
> have error chaining via a `?` operator
Although I do frequently find typing in the boiler plate of _every_ _single_ _error_ a bit of a faff, it does prompt me each time to really think "what if an error really happened here". I'm inclined to think that something like the ? operator makes it much easier to just toss in the ? and not consider the implications of an error.
> even force you to check the error[,] meaning I’m sure there’s plenty of missed error checks in production code
Something the equivalent of "#[must_use]" would certainly be an additional aid, (as would const pointers).
EDIT but one of the tools mentioned in the blog post, golangci-lint, will warn you of unchecked errors.