3 ms·

I love Rust but honestly the Go way works fine, even if it isn’t as strictly correct as Rust. I don’t think I’ve ever seen a case where a Go function returned n

I love Rust but honestly the Go way works fine, even if it isn’t as strictly correct as Rust. I don’t think I’ve ever seen a case where a Go function returned neither a value nor an error, or both a value and an error. What I like better about Rust, and what I think most people are actually complaining about with Go, is that syntactic sugar like the ? operator and functions like unwrap(). It’s a lot more concise and your application logic doesn’t get lost in verbose error checking code.

kadoban 3y ago
> I don’t think I’ve ever seen a case where a Go function returned neither a value nor an error, or both a value and an error. That's kind of the point. The type system should be powerful enough to disallow those cases then. In practice, I've seen both, always accidentally. I've also (more commonly) seen a lot of confusion and annoyance around: Okay, so this has to return a pointer for the error case, should the caller check that? If not, how do we square that with checking for nil pointers being generally a pretty good rule? If we do check, our unit test coverage has a blemish for every call since nothing can hit that. If we skip it being a pointer, then it's a zombie object. It's just a lot of cognitive load and bikeshedding around an issue that shouldn't exist.