In the article > The only opposition I have to the Result type in Go is that we wouldn’t be able to make use of it in the standard library without either break

In the article > The only opposition I have to the Result type in Go is that we wouldn’t be able to make use of it in the standard library without either breaking backwards compatibility, writing Result variants of existing API calls (so NewRequest, NewRequestWithContext, and NewRequestWithContextAndResult), or issuing new /v2 variants of existing packages (like the recently-released math/rand/v2 package), which then means we’ll have some libraries and programs that use the old style with one return value, some with the new style, and many instances of confused programmers using the wrong one. It would be as close to a Go equivalent of the Python 2/3 transition debacle as I think we could manage. I see Go's approach and Rust's approach as being mostly isomorphic as Go's `tuple(result, err)` maps pretty reasonably onto Rusts's `either(Err(err), Ok(result))`. If Go implemented a language convention that made these 100% equivalent, there would be no real problem except the battle between the old school and new school code authors as to which one is the right one to use in their code. Caveat - I am not a Go programmer, so I have no idea how feasible this is as an addition to the language proper. If you wanted to write Rust like you do go, it would be as simple as the following (cursed): impl From<Result<T, E>> for (Option<T>, Option<E>) { fn from(result: Result<T, E>) -> (Option<T>, Option<E>) { match result { Ok(value) => (Some(value), None), Err(error) => (None, Some(error)), } } } then let (val, err) = someFallibleCall().into(); if val.isSome() // something good with val.unwrap() } else // something bad with err.unwrap() } (noting of course this would be intentionally unidiomatic rust - real code would probably use match (val, err)) for this.