I'm not gonna argue against OOP in general here, but in the context of ORMs, some of the most important characteristics of OOP (encapsulation and inheritance, e

I'm not gonna argue against OOP in general here, but in the context of ORMs, some of the most important characteristics of OOP (encapsulation and inheritance, especially) are the source of many anti-patterns. Keeping methods that operate on data together with the data is the biggest problem with the Active Record pattern, and it's good that some new ORMs (like Ecto) are inspiring others to try other alternatives. Those alternatives invariably eschew the exaggerated use of method/data coupling and code-sharing via inheritance/mixins, among other things. They are either functional or procedural. Not to mention that a lot of OOP-heavy codebases are already replacing a lot of OOP-heavy ORM code with procedural (Services) or functional-inspired ("Railway Oriented Programming", Trailblazer operations). Sure, there are still classes being used. But I don't think it's fair to call "just using classes" as really as OOP, when they're used as structs, and especially in languages that make class usage mandatory.