[vlovich123]

“Inheritance” of interfaces good *. Inheritance of stateful objects bad - composition is much better. The OOP model that Rust supports only supports the good kind of OOP and doesn’t support the bad kind.

* technically rust doesn’t have interface inheritance but you can treat it that way and it’ll mostly look like that in an abstract sense.

[jandrewrogers]

I agree that composition is much better than inheritance for most typical code cases. However, there are cases where inheritance is absolutely the correct model and not having inheritance makes for worse code. I may not use inheritance very often (it rarely makes sense in a systems context) but it is nice to have it when it is unambiguously the right tool for the job.

Most code paradigms exist because there is some code context where they are nearly ideal. Someone invented them to handle that case efficiently and elegantly. If you write diverse software long enough you will come across all of those contexts in real code.

I’m the opposite of a model purist. I have a strong preference for a languages that let you efficiently switch models on a very granular basis as may be useful in the moment.

[zozbot234]

> The OOP model that Rust supports only supports the good kind of OOP and doesn’t support the bad kind.

Well, almost. You can actually express "the bad kind of OOP" (i.e. implementation inheritance) in Rust quite elegantly via the generic typestate pattern! But that's still good, because it reveals the inherent complexity of your 'inheritance hierarchy' very clearly by modeling every part of it as a separate, possibly generic type. Hence why it's very rarely used in Rust, with interface inheritance being preferred instead. It mostly gets used in cases where the improved static checking made possible by the "typestate" pattern can be helpful, which has little to do with "OOP" design as generally understood.