I don’t think any of that is contradicted by what this seems to be trying to do. In fact, Go doesn’t make you deal with your errors (you’re free to ignore the returns) whereas this would (via exhaustive pattern match).
> In fact, Go doesn’t make you deal with your errors
Your right, it does not. I will _ =: an error in a throw away script all the time.
I see that in a code review, in production code... Big red flag. This is a departure from an exception, that might be thrown in one place and handled far far away from the code you're looking at.
I'm not an expert in Go, and my experience is somewhat limited, however, a few years back I fixed a really subtle bug in a project that was related to the fact that errors _weren't_ being handled correctly. As a relative newbie to Go, the code in the diff[0] didn't appear to be doing anything wrong, until I added some print statements and realized that the numbers were not adding up correctly. IMO, if the returned value had been more like a Rust optional or result type, I think this issue would have either not been a bug in the first place, or it would have been easier to spot the bug.
EDIT: The fact that this was a bug at all makes me fear for the rest of the code base. If this one slipped through the cracks, how can I know that the rest of the code base is correct?
Ignoring errors is a thing you can do whether you're checking them or not. Rust does enforce error checking, every Result<T, E> is required to be checked before the value can be accessed. The only exception for this is if you don't need to access the Result's value, for which there's at least a built-in warning. And of course `unsafe`.
