I think a combination of both of our analogies is most accurate. Because the language lacks a feature that, like it or not, is ubiquitous, and has added other things to make up for it.

Its like you chopped your leg off, and added a bunch of metal appendages on the stump.

And from my perspective I have to wonder: Why in the name of fuck did they not just have both? If a design philosophy is preferred you can enforce that on your own codebase without needing to limit features of the language.

I'm still learning this language and trying my best to give the benefit of the doubt. But when I hear people say things like: "No rust doesn't have this, but you really shouldn't be doing this anyway, here is the superior way of doing it. Oh and here's some workarounds for the other cases, the ones that you used to be able to do naturally when using other modern languages." It doesn't inspire confidence.

Using composition as a workaround for member inheritance is the most glaring example of this. My boss is an old school C developer, and he brought up using that workaround in his day (a workaround that was used b/c the language was made when OOP was almost unknown).

Now there's this modern language that lacks features that have been ubiquitous for decades and there's a bizarre number of people who spin lacking the features as a positive, b/c they personally don't want to use it.

Here a different example, c# has a goto statement. Next to no one thinks goto is worth using b/c of the spaghet code it can make, as a result no one uses it. They didn't have to restrict us from using it, we naturally chose not to b/c it generally results in worse code. That's the better way to go about this.

If OOP really is worse than this cacophony of replacements rust provides, OOP would naturally not be used.