from time to time topics like 'Why is Rust so bad at OOP?', 'Why doesn't Rust support feature X from OOP-language Y?' and so on turn up on in this forum. I think most of you know what I'm talking about. In those discussions it is then pointed out that with enough tricks, hacks and crates you can have more OO-ish Rust. However, I think this is the wrong way to go. The way Rust's type(/trait) system is designed it is just different from the hierarchical approaches that are favored in C++, Java, C# and so on (by design, I know that it is not recommended).
Therefore, I propose to call Rust's way of doing OOP Behavior-Oriented Design. In many OOP classes the first thing you learn is abstractions like a car is a vehicle and vehicles have this properties and methods. In difference, the Rust way (from my point of view) is to say a car is movable and movable types have this behavior. And it's the same for abstraction. Instead of stating that a function takes any kind of a vehicle (
fn func(v: &dyn Vehicle)), a Rust function rather states that it requires something that can move (
fn func(m: impl Movable)). This can also be seen at traits like
Clone that rather describe behavior than a class of objects.
I know this view is not very different from Java's interfaces but I think it can help beginners to faster understand the mind set behind Rust's way of abstracting things.
What do you think about this?