Programming

They don't only say static types. They add classes, inheritance, subtyping, and virtual calls. Mind you, the difference between the last 3 is quite subtle.

So, since I've started nit-picking, Self is also OO and has prototype-based inheritance (as does javascript, but I'm not sure I'd want to defend the claim that javascript is an OO language).

IMO factory functions are totally fine -- I hesitate to even give them a special name b/c functions that can return an object are not special.

However I think good use cases for Factory classes (and long-lived stateful instances of) are scarce, often being better served using other constructs.

I have never seen them used well. I expect there IS some use case out there where it makes sense but I haven't seen it yet. So many times I've seen factories that can only return one type. So why did you use a factory? And a factory that returns more than one type is 50/50 to be scary.

Yeah, I went through the whole shape examples thing in school. The OOP I was taught in school was bullshit.

Make it simpler. Organizing things into classes is absolutely fine. Seven layers of abstraction is typically not fine.

IMO rust does use OOP styles all over the place. OOP does not mean dynamic dispatch or inheritance - that is just what older popular languages used. Note that static dispatch and monomorphization (where the compiler generates a method for each type at compile time rather than using a runtime lookup) give you a lot of the benefits of dynamic dispatch at the cost of binary size in favor of runtime checks and performance.

And other aspects of OOP, like encapsulation, data abstractions and polymorphism are easily achievable in rust and often are. Just look at any object from the std library - they are all essentially written in an OOP style. Such as Vec or File - hidden internal state with traits that you can swap them around with other parts that make sense. The only thing it really likes - like Go lang (which claims to be an OOP style language) is inheritance.

And the only reason rust is not seen as or describes itself as an OOP language is because it does not force the OOP style on you. But instead lets you program in more of a functional or procedural style if you want to. You can pick the best methodology to solve the problem you have at hand rather than trying to fir everything into a single style.

But that does not make it bad at OOP style.

To be fair, that's an issue in almost every imperative language and even some functional languages. Rust, C, and C++ are the only imperative languages I know of that make a serious effort to restrict mutability.

Rust’s borrow checker may be annoying at times, but it forces you to think about ownership and prevents you from stuffing statefulness where it shouldn’t be.

That does sound pretty cool.

ultra rare I've successfully inherited a concrete class, rarely an abstract one and 99% just impl an interface.

Damn good point! I feel the same way about CEOs as of late and how they think AI is going to solve everything, even problems they invent just to say they’re using AI.

So the easy way is to inherit and extend to a custom type while keeping the original functionality intact.

You can do this with traits and interfaces in rust/go. You can add any methods you want onto existing types. Which IMO is better. No need to subclass, in just just create a new trait, implement it on the type you want and you have new behavior attached to that type without needing to convert the existing thing you got from something into a new type.

And I think the trait system (in Rust for example) creates so much duplicate or boilerplate code.

It really does not. You can have implementation on traits that don't need to be re-implemented on every type - like the Iterator - it provides 76 methods of which you need to implement only 1 for new types. You can implement others for custom behavior which is great for specialization (aka using a more efficient implementation for types that have more info, like calling skip on an array which knows all its elements vs the default which needs to call next n times).

But it creates a vastly more flexible system. Take a very basic example - read/writing to something. How do you model that with inheritance? Basically you cannot. Not without painting yourself into a corner eventually. For instance, you can read/write to a file, to a network socket, to stdin/stdout but each of these is very different. Stdin for instance cannot be written to and Stdout cannot be read from. You might want to have a buffered reader/writer as well that wraps these types making read operation cheaper.

You cannot put these into a inheritance tree. Everything either needs to inherit from the same generic base that can both read/write and probably also close. But then for some types you need to implement these methods that don't make sense that do what? Nothing when called? or throw an exception? It is a poor way to model this behavior.

Read and Write are orthogonal ideas - they have nothing to do with each other except they might be useful on some of the same types. With interfaces/traits you are free to separate these and implement them on whichever types make sense for them.

I have not yet seen a problem that is solvable with inheritance that cannot be better solved with some other language feature in a better way. It sort of works for some things, but other solutions also work at least equally well. Which leave it in a state where what is the point of it? If it is not solving things better then other solutions we have these days?

It requires you model your problem perfectly from the start, then it can work alright. But in reality you cannot know the future and when new requirements come in that don't fit the model you created you are left in a crappy spot of needing to refactor everything or just cram it in however you can.