Earlier quoted context omitted.
I disagree completely. It's not just a technicality, traits are not the same as multiple inheritance. They allow you to solve the same kinds of problems but traits don't introduce the mountain-loads of confusion, complexity and headache that multiple inheritance does. Moreover, nothing forces you to use traits. You're just strictly better off using them in many cases. But you can always defer to writing overtly repet…
Yet, I have zero issues mapping COM approach to OOP into Rust, because it turns out as per CS type systems theory, there are many ways to achieve the same goal. Practical example, Raytracing in one weekend port from C++ to Rust, keeping the overall architecture. Second example, Microsoft bindings to WinRT for Rust.
Anyone who has at least read and understood both of these languages can see that this is not true, even if you replace inheritance with traits in rust. Not only that, traits do not support the same range of things that inheritance does. They have overlap, but it's not a small difference. When you actually get down to real rust codebases, they end up pretty different even if they're heavy on traits. But again, there's nothing requiring you to use traits. You see them often in libraries because they are very useful for generic programming. But that doesn't mean you are forced to use them in your application code.