Compare Go's switch with Rust's match on exhaustiveness, fallthrough, and expressions.

WHAT THIS TESTS: This question probes whether you understand the fundamental architectural difference between statement-oriented and expression-oriented languages. In Go, control flow constructs are generally statements that perform side effects, while Rust treats control flow as expressions that produce values. The interviewer wants to see if you can articulate how exhaustiveness checking eliminates a class of runtime bugs, how fallthrough semantics affect readability and safety, and why expression-oriented syntax enables more concise, functional-style code. It also checks whether you know the practical consequences for API design, such as using match to initialize variables in a single expression.

A GOOD ANSWER COVERS: First, classify Go switch as a statement and Rust match as an expression. Second, explain that Go cases implicitly break and require an explicit fallthrough keyword to continue, whereas Rust match arms never fall through. Third, note that Rust match requires exhaustive pattern coverage, often enforced by the compiler with a catch-all pattern or the compiler rejecting non-exhaustive matches, while Go switch has no such requirement. Fourth, highlight that Rust match evaluates to a value of a uniform type across all arms, enabling direct assignment or return, while Go switch cannot be used to return a value directly. Fifth, mention that Rust match supports rich pattern matching including destructuring and guards, while Go switch is limited to equality comparisons or type assertions.

COMMON WRONG ANSWERS: A red flag is claiming that Go switch can return a value like a ternary operator or that Rust match allows implicit fallthrough. Another mistake is saying Go has exhaustiveness checking; it does not, even for typed constants. Some candidates confuse Rust match with C switch and assume break is needed. Also, asserting that Go switch only works on integers is wrong, since Go permits switching on strings, interfaces, and types.

LIKELY FOLLOW-UPS: The interviewer may ask how Rust handles non-exhaustive matches if you add a new variant to an enum later, which is a key maintenance benefit. They might ask how to simulate an expression-like switch in Go, which typically requires an immediately invoked function literal or a helper function. They could also ask about performance, such as whether Rust match is compiled to jump tables or decision trees, or how Go switch on strings is implemented. Another angle is error handling, comparing Go's idiomatic if err != nil with Rust's match on Result types.

ONE CONCRETE EXAMPLE: In Rust, you can write let msg = match status { 200 => "ok", 404 => "not found", _ => "other" }; because match is an expression and the compiler verifies every u16 value is covered. In Go, you must write a switch statement with separate case branches, each assigning to a msg variable declared beforehand, or use a helper function, because switch does not yield a value and the compiler will not warn if you omit a case.