2021-05-14
2108
#rust
Andre Bogus
48759
May 14, 2021 ⋅ 7 min read

Understanding inheritance and other limitations in Rust

Andre Bogus Andre "llogiq" Bogus is a Rust contributor and Clippy maintainer. A musician-turned-programmer, he has worked in many fields, from voice acting and teaching, to programming and managing software projects. He enjoys learning new things and telling others about them.

Recent posts:

the replay oct 15 graphic

The Replay (10/15/25): AI’s accessibility problem, React 19.2, and more

Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the October 15th issue.

Matt MacCormack
Oct 15, 2025 ⋅ 34 sec read
AI has an accessibility problem: What devs can do about it

AI has an accessibility problem: What devs can do about it

Jemima Abu examines where AI falls short on accessibility and how we can best harness AI while still building products that everyone can use.

Jemima Abu
Oct 15, 2025 ⋅ 10 min read

Want to run your AI model locally? Here’s what you should know

Cloud AI made scaling easy, but local AI brings control, cost stability, and data privacy. Explore the hardware realities, tradeoffs, and strategies shaping this shift.

Clara Ekekenta
Oct 15, 2025 ⋅ 6 min read

Stop writing REST APIs from scratch in 2025

Writing REST APIs by hand is a thing of the past. Frameworks like tRPC, Fastify, and Hono eliminate boilerplate with schema-driven design, improving speed and safety.

Ikeh Akinyemi
Oct 14, 2025 ⋅ 3 min read
View all posts

2 Replies to "Understanding inheritance and other limitations in Rust"

  1. “You could surely argue that even in the OO world, inheritance has a bad reputation and practitioners usually favor composition if they can.”

    I’ve been programming with OO for more than 25 years and I’ve never heard it had bad reputation, or that one should favor composition (which doesn’t offer the benefits of inheritance).

    When programming UI there is simply no alternative, and the lack of inheritance in Rust excludes it from any form of efficient UI framework. The default implementation on undefined types that you mention is not inheritance:
    – it cannot act on the object since it’s generic
    – a custom implementation can replace the default one, but not call it
    – there is only one level (replacing the default implementation)

    In general like any other feature, inheritance shouldn’t be abused, maybe that’s what you’re referring to, though without an example it is hard to tell for sure.

  2. You wrote, about code duplication due to the lack of inheritance: “The simplest way is, obviously, to duplicate the methods. Yes, duplication is bad. So is complexity. Create a free method and call that from the Cat and Lion impl if you need to deduplicate the code.”

    But how do you manage to access the struct’s (or worse, enum’s) fields from a free function, for several different types? Polymorphism doesn’t stretch that far, so it doesn’t look like this is possible and that’s the whole point about reusing methods with inheritance.

    That’s why I generally avoid using fake code with animals to talk about OOP, they don’t reflect the actual complexity and the interdependencies of the actual code.

    Currently one option is to use macros, like delegate for instance, but macros are not standard, harder to read and even harder to use with refactoring. That could be an acceptable temporary work-around if the macro was part of the core library, but it isn’t, which makes it a hack at best.

Leave a Reply