Go and Rust shipped without implementation inheritance at all. What replaces it, what does a team actually pay in code that would have used a three-level class hierarchy, and what does the omission buy?

## The bet Two widely used systems languages designed in the last two decades looked at implementation inheritance and declined it. Go has structs, interfaces and embedding; Rust has structs, enums and traits. Neither has a base class. That is a strong claim about the reuse-only inheritance critique: the argument was not "use it carefully", it was "the mechanism is not worth its coupling". ## What actually replaces each thing a hierarchy did A three-level hierarchy typically does four jobs at once, and each has a separate replacement. **Polymorphism.** Rust: a trait plus `dyn Trait` behind a pointer for runtime dispatch, or a generic parameter that monomorphises to a direct call at compile time. Go: an interface, satisfied implicitly -- the type never declares that it implements anything, so the interface can be defined by the *consumer*, at the point of use, rather than by the provider. That inverts a real dependency: in a class hierarchy the abstraction lives with the supplier and every consumer is coupled to it. **Shared behaviour.** Rust: default method bodies on a trait. These are more capable than they first look, because a default body may call the trait's required methods through `self`, and those calls resolve to the implementing type -- so Template Method-style hooks work fine. Go: embedding a struct promotes its methods, which covers straightforward code reuse but has no re-dispatch back into the outer type, so hook-shaped designs must be inverted into an injected interface. **Shared state.** This is where the omission bites. Rust traits cannot declare fields at all. If three implementers need the same three fields, you either declare required accessor methods in the trait and have each implementer write them, or you factor the fields into a struct and give each type a member plus forwarding methods. Go embedding does share state -- an embedded struct's fields are promoted -- so Go handles this case more gracefully than Rust. **Type identity / exhaustiveness.** A sealed class hierarchy answers "what are all the cases". Rust replaces it with `enum` plus exhaustive `match`, which is a better fit for closed sets and is checked by the compiler. Go has no equivalent and leans on interfaces plus, occasionally, type switches with a default branch. ## What a team pays - **Forwarding boilerplate.** The single most common complaint. When you cannot inherit state and behaviour together, you write delegating methods. Rust's ecosystem responded with macro crates (`delegate`, `ambassador`) whose whole purpose is generating forwarders, which is evidence that the cost is real and recurring rather than theoretical. - **Framework styles do not port.** Anything built on "extend our base class and override these three protected methods" has no direct translation. Both languages push registration and injection instead: pass a function or an interface value. Teams migrating a subclass-hook design must redesign, not translate. - **The Deref temptation.** Rust newcomers discover that implementing `Deref` makes a wrapper's inner methods appear on the wrapper, which mimics inheritance. It is explicitly discouraged: `Deref` is for smart pointers, and abusing it produces surprising method resolution and poor error messages. That a widely warned-against anti-pattern exists is a fair measure of the pressure the omission creates. - **The orphan rule.** Rust's coherence rule -- you may implement a trait for a type only if you own the trait or the type -- is the price of guaranteeing a single implementation exists globally. It blocks the natural move of "implement someone else's trait for someone else's type" and forces newtype wrappers, which is more forwarding. ## What it buys - **No coupling to a base's internal call pattern.** In Go, an embedded type cannot re-enter the outer type, so changing which internal calls it makes cannot alter an embedder's behaviour. That deletes a whole failure category rather than mitigating it. - **No diamond, no linearization, no accidental capture.** There is no ancestor chain whose order is part of the API, and a method added to an embedded or implemented type cannot silently capture a call that was going somewhere else -- in Go an ambiguous promotion is a compile error at the use site. - **The expression problem from the other side.** In a class hierarchy, adding a new *type* is easy (write a subclass) and adding a new *operation* is hard (edit every class, or introduce a visitor). With Rust traits, adding a new operation over existing types is easy -- define a trait and write impls -- and adding a new type is also easy. The orphan rule is precisely the constraint that keeps this from being free. - **Predictable cost.** Rust's generics monomorphise to static calls; you opt into dynamic dispatch by writing `dyn`. Go's interface calls are indirect but there is no hierarchy depth to traverse. ## The judgement The honest summary is that these languages did not remove reuse; they removed the *bundling*. Inheritance offered subtyping, code reuse, state reuse and open recursion in one keyword, and both languages unbundled it and shipped the pieces separately -- keeping the ones that compose (interfaces, embedding, trait defaults) and dropping the one that couples hardest (inherited state plus overridable internals). For a team, the practical test is how much of your design is shared *state* versus shared *behaviour*. Shared behaviour ports cleanly. Shared state is where you will write forwarders and where you should expect the port to be a redesign.