Go (T, error) versus Rust Result for error handling

WHAT THIS TESTS It probes whether you understand that both languages make errors ordinary values, but differ in whether handling is enforced by convention or by the type system.

A GOOD ANSWER COVERS Go returns errors as a second value, typically (T, error), where error is an interface. By convention you write if err != nil, but the compiler does not require you to inspect the error; you can assign it to the blank identifier or ignore it. This keeps the model uniform and simple. Rust represents fallible operations with Result<T, E>, a single enum with Ok and Err variants. To obtain the inner T you must pattern match, use combinators, or propagate with ?, so the error path is explicit. The compiler emits a warning (and via must_use, effectively flags) unused Results, and there is no way to read the success value without confronting the possibility of error.

IMPLICATIONS Go trades a small risk of silently dropped errors for less ceremony and a flat control flow. Rust trades extra syntax for a strong static guarantee that an error is at least acknowledged, plus rich typed errors and exhaustive matching. Neither uses stack unwinding for normal errors, so both avoid exception overhead and hidden control flow.

COMMON WRONG ANSWERS Saying Go forces you to handle errors. Saying Rust's Result is an exception or has unwinding cost. Conflating panic/recover or panic! with the normal error path.

LIKELY FOLLOW-UPS How does the ? operator work and what does it require of the function's return type? What is errors.Is and wrapping with %w in Go? When is panic appropriate?

ONE CONCRETE EXAMPLE In Go, val, err := os.Open(path) lets you write _ = err and proceed with a possibly-invalid val, a class of bug linters try to catch. In Rust, let f = File::open(path)?; cannot compile unless the enclosing function returns a compatible Result (or you otherwise handle the Err), so the error case is structurally impossible to ignore while still using the value.