Compare Go interfaces with Rust traits

WHAT THIS TESTS: Whether you understand the difference between structural implicit polymorphism and nominal explicit polymorphism in systems languages. The interviewer wants to see that you recognize how Go's automatic interface satisfaction reduces boilerplate but shifts design responsibility, while Rust's explicit trait implementation and trait objects create stronger contracts through dyn Trait.

A GOOD ANSWER COVERS: First, the typing discipline: Go uses structural typing where a type satisfies an interface automatically by implementing the required methods, with no explicit declaration needed. Rust uses nominal typing where a developer must write an explicit impl block to bind a trait to a type, making the relationship explicit in the source code. Second, runtime representation: Rust trait objects use a reference like dyn Trait that carries a vtable for dynamic dispatch, allowing polymorphic behavior without knowing the concrete type. Go interfaces also enable polymorphism but rely on a runtime mechanism where satisfaction is checked implicitly. Third, API design influence: Go interfaces are often defined by the consumer of a type, letting packages abstract over dependencies they do not own without importing extra definitions. Rust traits are typically defined by the producer of a behavior, and the explicit impl block means the library author controls how a type participates in an abstraction. Fourth, flexibility versus safety: Go's model makes it easy to adapt existing types to new interfaces but can lead to accidental satisfaction if method signatures collide. Rust's model prevents accidental implementation and enables zero-cost abstractions because the compiler knows exactly which types implement which traits at compile time.

COMMON WRONG ANSWERS: Claiming that Rust traits are implemented automatically like Go interfaces. Asserting that Go interfaces require an explicit implements keyword or declaration. Confusing Rust trait objects with Java interfaces or C++ pure virtual classes without noting the dyn keyword and vtable indirection. Stating that Go interfaces are checked at compile time only and have no runtime representation; in fact, Go interface values carry runtime type information. Suggesting that one approach is strictly superior without acknowledging that Go favors loose coupling while Rust favors explicit contracts.

LIKELY FOLLOW-UPS: How would you add a new method to an existing interface or trait without breaking existing code? When should you use generics instead of trait objects in Rust? How do you test code that depends on an interface in Go versus a trait in Rust? What happens in Go if two interfaces define the same method signature? How does Rust's borrow checker interact with trait objects compared to Go's garbage collected interface values?

ONE CONCRETE EXAMPLE: Consider a Bark behavior. In Rust, you define a Bark trait and implement it explicitly for Dog and Cat using impl Bark for Dog. A function accepting dyn Bark can treat both uniformly through a trait object that carries a vtable. In Go, you define a Barker interface with a Bark method, and if Dog and Cat already have Bark methods with matching signatures, they automatically satisfy Barker without any import or declaration. A function accepting a Barker parameter works immediately. This means a Go package can define Barker locally and pass a third-party Dog into it, while in Rust the third-party crate or a wrapper must explicitly implement the trait.