I think a lot of people conflate OOP and inheritance to mean the same thing. And inheritance is what should get the bad rap. It does not solve any problem I have seen any better than other language features (in particular interfaces/traits can solve a lot of the same problems) but inheritance causes far more problems overall.

But building the code out of logical units with fenced responisbilities is in my opinion a good way to structure code.

This is encapsulation, which is one of the better ideas from OOP languages. Though also not unique to them.

And I have a hard time to wrap my mind around some design choices in the language that would have been very easily solved with a more OOP like structure.

What design choices would those be? And how would they better fit into an OOP like structure? Note that rust is not anti OOP - it uses OOP techniques a lot throughout the code base. It just lack inheritance and replaces that with other IMO better features.

Curious to hear what in Rust could be more easily solved with OOP! I think one reason for rust not using OOP is because they want to minimize dynamic dispatch and keep it explicit where it happens, because it's a language that gives you very fine grained control of resource usage, kinda similar to how you have to be explicit about copying for most types. Most trait calls are static dispatch unless you have a Box::<dyn SomeTrait>

It's enterprise design that sucks, often it's written in Java - Hello World

I've realized that Factories are actually kind of fine, in particular when contexualized as being the equivalent of partials from the world of functionals.

Why is the word factory a code smell?

OOP definitely doesn't get to claim static types for only itself either. Fuck that.

Yeah let’s not forget the Common Lisp Object System (CLOS) which was more full-featured of an object-oriented language than most “current” languages.

The dynamism allowed both Smalltalk and CLOS to avoid a dark corner that will confound your typical OOP’er today - the circle/ellipse modeling problem; they allow an object to “become” a different type on its own accord. Take that, Java!

But how does the alternative solutions compare with regards to maintainability?

Which alternative solutions are you thinking of, and have you tried them?

Rust has been mentioned several times in the thread already, but Go also prohibits "standard" OOP in the sense that structs don't have inheritance. So have you used either Rust or Go on a large project?

This is something that’s difficult to demonstrate with small toy examples, which gives OOP languages an unfair disadvantage.

This is well said. It's such a frustrating meme when I see people talk about how many lines a "hello world" application needs as if that's the benchmark of what makes a language good.

This is something often repeated by OOP people but that doesn't actually hold up in practice. Maintainability comes from true separation of concerns, which OOP is really bad at because it encourages implicit, invisible, stateful manipulation across disparate parts of a codebase.

I work on a Haskell codebase in production of half a million lines of Haskell supported by 11 developers including myself, and the codebase is rapidly expanding with new features. This would be incredibly difficult in an OOP language. It's very challenging to read unfamiliar code in an OOP language and quickly understand what it's doing; there's so much implicit behavior that you have to track down before any of it makes sense. It is far, far easier to reason about a program when the bulk of it is comprised of pure functions taking in some input and producing some output. There's a reason that pure functions are the textbook example of testable code, and that reason is because they are much easier to understand. Code that's easier to understand is code that's easier to maintain.

I've always had an easier time jumping into an oop code base, then eg a lisp one.

I hear people when they say they don't want their data mixed in with their logic but The pressure to structure code Is very nice.

If we’re looking at it from a Rust angle anyway, I think there’s a second reason that OOP often becomes messy, but less so in Rust: Unlimited interior 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's a take I can agree with. My experience is that composition solves much of what inheritance is intended to solve and ends up being a more maintainable solution a majority of the time.

Inheritance is isn’t always a terrible choice. But it is a terrible choice often enough that we need to warn the next generation.

But also, when it is not a terrible choice for a problem it is often not the best choice or at the very least equally good as other options that work in vastly more cases.

Composition is far better and immensely more flexible than inheritance. Extracting duplicate code into helper classes or static functions is a good option.

Conformance to interfaces or protocols with default implementations is a great alternative as well.

I like OOP more than other styles, it’s just often badly done. Complex inheritance, huge classes that do too much, overuse of factories and similar patterns, can ruin it.

I do not agree. Very often, when using libraries for example, you need some extra custom handling on types and data. So the easy way is to inherit and extend to a custom type while keeping the original functionality intact. The alternative is to place the new functionality in some unrelated place or create non-obvious related methods somewhere else. Which makes everything unnecessary complex.

And I think the trait system (in Rust for example) creates so much duplicate or boilerplate code. And in Rust this is then solved by an even more complex macro system. But my Rust knowledge might just nog be mature enough, feel free to correct me if I'm wrong..

I’ve seen some surprisingly fragile OOP solutions that require tons of internal knowledge about how the classes work. It seems to be a popular approach to writing code that just isn’t very flexible.

My issue isn't any particular language but the advocates of various languages treating their language as the best hammer for every nail.