Implicit Go interfaces versus explicit Rust trait impls

WHAT THIS TESTS It evaluates whether you understand the maintainability consequences of implicit structural conformance versus explicit nominal conformance.

A GOOD ANSWER COVERS In Go, a type satisfies an interface merely by having the right methods; there is no statement of intent. This yields strong decoupling: a consumer can declare a small interface and any existing type, even from another package, conforms automatically, and you can introduce interfaces retroactively. The costs are weaker discoverability (you cannot easily ask the compiler who implements an interface), the possibility of accidental conformance (a type matches an interface it was never meant to), and refactoring fragility (renaming or changing a method signature silently removes conformance, with errors appearing only at distant call sites). Rust requires an explicit impl Trait for Type block. Intent is documented at the implementation, tooling can enumerate implementers, and changing a trait method produces compile errors precisely where impls no longer satisfy it. The orphan rule, allowed only because impls are explicit, guarantees coherence by forbidding two crates from both implementing a foreign trait for a foreign type.

TRADE-OFFS Go favors flexibility and decoupling, accepting reduced safety and discoverability. Rust favors explicitness, discoverability, and compiler-guided refactoring, accepting that extending foreign types needs the newtype pattern.

COMMON WRONG ANSWERS Saying implicit conformance has no downsides. Claiming Rust's explicit impls prevent decoupling entirely. Forgetting the orphan rule and coherence.

LIKELY FOLLOW-UPS What is accidental conformance and how might it cause bugs? How does the orphan rule relate to explicit impls? How do IDEs find interface implementers in Go versus trait impls in Rust?

ONE CONCRETE EXAMPLE Suppose you rename a method on an interface's expected shape in Go: types that used to conform silently stop conforming, and the build fails only where they are passed as that interface, sometimes in another package, making the root cause non-obvious. In Rust, changing a trait method signature immediately flags every impl Trait for Type block that no longer matches, pointing you straight at each implementer to update.