3 ms·
Linus’s proposal for Result<T, E> seems a lot like the Golang approach to things where you almost always return a value and an error. I’m not a rust developer
by gigatexal 6y ago
Linus’s proposal for Result<T, E> seems a lot like the Golang approach to things where you almost always return a value and an error.
I’m not a rust developer and a very weak go dev so take the above as you will.
- coldtea 6y agoThe Result<T, E> is actually Rust's aproach, which is a formal (better) version of Golang's approach. Better as in the result is standardized, and not ad-hoc like in Golang, and must be handled to use the value.
- pornel 6y agoIn Rust it's guaranteed that you never get both Ok and Err values at the same time (Result is a tagged union, not a tuple). In golang both are independent, and it's unclear whether you can or should use the ok value when err != nil. There are some interfaces that actually return both at the same time.
- coldtea 6y ago>In Rust it's guaranteed that you never get both Ok and Err values at the same time (Result is a tagged union, not a tuple). Yeah, that's the standardized part -- it's a tagged union. In Goland the second value might not even be an error, it's just a convention using the variadic return capabilities...
- joseluisq 6y agoYeah, I see `Result<T, E>` more solid in Rust than on-purpose Go error approach as you already mentioned and even more concise than `Exceptions` in other languages. BTW there are already interesting discussions around the topic if someone wants to have a look. https://news.ycombinator.com/item?id=25254737 https://news.ycombinator.com/item?id=25254737