[royjacobs]

Isn't the argument that there is nothing inherently wrong with OOP but like all things, it shouldn't be used exclusively?

For instance, working with language like Kotlin or C# it's fairly straightforward to get the best of both worlds: Use inheritance where appropriate, favor composition in all other cases.

IMO being dogmatic about not wanting inheritance altogether will result in friction as well: The fact that Rust eschews inheritance altogether will increase boilerplate whenever you want to do something that is 'inheritance-like'. Sure, people will argue that in 90% of the cases this is bad design, but for the cases where it IS the best approach it's a shame it's not part of your toolbox.

[ashleyn]

Inheritance is so natural to a GUI data structure. UI in Rust is incredibly painful. Probably a reason behind the CPU-wasteful "immediate mode" fad.

[0815test]

Implementation inheritance may have its uses, but it's not for the faint of heart. Its defining feature is _open recursion_; that is, defining an object's external interface (its bundle of public and protected methods) in terms of itself (in that any method may be defined as calling any other method of the same external interface) and then leaving the whole thing open for arbitrary overriding in "derived" classes, via a "tying the knot" trick. Most treatments of OOP brush over this feature, but it creates a huge amount of complexity. It is even proper to say that something like this should be avoided at all costs, IMHO.

[vannevar]

I would quibble with the implication that composition isn't OOP---mixins have been part of many OOP languages for a long time. Whether you create a new object via inheritance or via composition, it's still an object, typically with methods and state.