Cool catalogue, but it had nothing to do with inheritance. It’s more “nine ways to do polymorphism-adjacent things using ad-hoc polymorphism (“traits”) instead of subtype polymorphism (‘inheritance’)”
Just like you can do OO in any language - for example, you can do OO like C (or at least that's what GTK folks believe), Rust already has most runtime mechanisms to pretty much implement inheritance in a library or a coding pattern (as opposed to a language feature)
For a long time the most important thing missing was a better story around upcasting, but Rust 1.86 implemented the usual child-to-parent upcasting [0] expected in OO (with the Any trait doing the parent-to-child downcasting [1] in a way that's less error prone than most OO languages actually)
Also note that Firefox and Servo were a early proponents of getting more OO into Rust (I guess that's because they need to deal with the DOM? Not sure). Which doesn't mean literally having classes and inheritance, but rather, language features that can emulate those when needed.
Today I think the missing piece is fields in traits: a way for a vtable to store field offsets rather than just pointers to method; current practice is to add getters and setters to traits when needed (but that's "ugly"). Unfortunately discussion around this stalled [2]
Yes. The polymorphism isn't bad. It's the inheritance of data that's the problem.
Rust traits can't have associated data. That's the big difference from objects.
It's also hard to have a parent-child relationship where the child can find the parent. That takes much fooling around with wordy combos of Rc, Weak, upgrade, etc.
This makes it hard to convert C++ programs, and C++ programmers, to Rust.
It's quite possible to write 100% safe code under Rust's constraints, but it takes a major rethink from C++.
Much of this post seems to focus on interface inheritance via traits, which is a well-known feature of Rust. It's weird though that it completely misses the generic typestate pattern, which is pretty unique to Rust as far as it goes and can be quite fairly described as OOP implementation inheritance in a type-theoretic trench coat.
Cool catalogue, but it had nothing to do with inheritance. It’s more “nine ways to do polymorphism-adjacent things using ad-hoc polymorphism (“traits”) instead of subtype polymorphism (‘inheritance’)”
Just like you can do OO in any language - for example, you can do OO like C (or at least that's what GTK folks believe), Rust already has most runtime mechanisms to pretty much implement inheritance in a library or a coding pattern (as opposed to a language feature)
For a long time the most important thing missing was a better story around upcasting, but Rust 1.86 implemented the usual child-to-parent upcasting [0] expected in OO (with the Any trait doing the parent-to-child downcasting [1] in a way that's less error prone than most OO languages actually)
Also note that Firefox and Servo were a early proponents of getting more OO into Rust (I guess that's because they need to deal with the DOM? Not sure). Which doesn't mean literally having classes and inheritance, but rather, language features that can emulate those when needed.
Today I think the missing piece is fields in traits: a way for a vtable to store field offsets rather than just pointers to method; current practice is to add getters and setters to traits when needed (but that's "ugly"). Unfortunately discussion around this stalled [2]
[0]: https://blog.rust-lang.org/2025/04/03/Rust-1.86.0/#trait-upc...
[1]: https://doc.rust-lang.org/std/any/index.html
[2]: maybe the latest one is https://internals.rust-lang.org/t/fields-in-traits/6933/ but idk
Yes. The polymorphism isn't bad. It's the inheritance of data that's the problem.
Rust traits can't have associated data. That's the big difference from objects.
It's also hard to have a parent-child relationship where the child can find the parent. That takes much fooling around with wordy combos of Rc, Weak, upgrade, etc.
This makes it hard to convert C++ programs, and C++ programmers, to Rust. It's quite possible to write 100% safe code under Rust's constraints, but it takes a major rethink from C++.
Much of this post seems to focus on interface inheritance via traits, which is a well-known feature of Rust. It's weird though that it completely misses the generic typestate pattern, which is pretty unique to Rust as far as it goes and can be quite fairly described as OOP implementation inheritance in a type-theoretic trench coat.