What in Go is a return type of (Anything, error) with typically exactly one of the two being nil is in Rust the Result type, `enum Result { Ok(T), Err(E) }`, something which is explicitly exclusively-either an OK T or an error E.

The equivalent of `x, err = expr; if err != nil { return err }` is very common in Rust; it would be written `x = match expr { Ok(x) => x, Err(e) => return Err(e) }`. It’s such a common pattern that a macro named try! was placed in the standard library for this incantation. Therefore you can write `x = try!(expr);` (or if you’re going to ignore the Ok variant, just `try!(expr)`).

Rust also warns you if you do nothing with a Result object; you can ignore the warning or suppress it, but it all makes it very much harder to ignore such error conditions. Go is one step up from C, where integral error-indicating return codes are the norm and are typically ignored, but I feel it’s still a fair way off the confidence that Rust gives me that I haven’t accidentally forgotten to deal with an error case. If you want people to get the message “Whatever you do, always check your errors!”, it helps if you design the language to make it hard for the user to forget.

(You people that know Rust, I’m ignoring the `FromError` part for simplicity. That’s only in libstd’s try!, anyway; libcore’s try! doesn’t have it.)

It is very easy to produce linters for Go to find things like unchecked errors, for example https://github.com/kisielk/errcheck