By definition, you only need to do the minimum to move data from one process to another to get things read or written.
That doesn't mean you need an entire system to represent every table as an object-like thing (which is what I assume when people say ORM). It's actually possible to just emit queries to read and write the exact data that's required in the shape that makes sense for the caller.
Mine doesn't, so I don't need an ORM. Plus, I think that when people say ORM, they mean more than just a map from the relational model to the object model and back. They refer to things like hibernate and SQLAlchemy and all the extra stuff that comes with that, like the active record antipattern, and a query builder which successfully encapsulates all trivial queries (which don't need encapsulation) but then as soon as you need to do anything even remotely complicated, the abstraction leaks. I'll be honest, not a fan of ORMs.
You can map objects to db updates, and map query results to objects. Neither of those objects needs to have a mapping to actual relations, like how ORMs insist on.
No, ORMs abstract away the relational database and present it as if it were some kind of object database. Needing to map query results to structs is just incidental, and is completely missing the point of an ORM.
If copying query results to a list of structs is enough to qualify as an ORM, then the term is so generic as to be entirely useless.
This is clearly not what anyone means when they say they don't want an ORM.
An ORM library maps an entire relational database to a graph of objects, with the intention of abstracting away the relational database. Copying query results to structs doesn't actually do any of that.
Majority of ORMs really are nothing more than this.
But then it's nice to have something that generates optimised, database-specific SQL, can handle date/number conversion, supports many-many relationships, converting BLOB to binary streams etc.
ORM by modern standard is not that, it's basically let me interact with the DB without knowing SQL.
Every language need to deserialize results into some object so by definition every language that deal with a DB do some form of ORM. So ORM is meaningless in that context.
I kind of agree with this. Data in a database is often relational (hey it might not be, but it's still nice to represent it in a struct sometimes, rather than 10–20 different variables which can change anytime your database changes).
I've been using Go recently, and while I'm not convinced on an active-record style ORM in Go (I don't think the language is dynamic enough, and I'm not the biggest fan of codegen), I've been loading the row data from Postgres into a Result struct (pretty much a 1:1 mapping of the Postgres result set into the struct), and then using another function to load the Result struct into struct with their relationships attached (using tags on the structs to define the relationships between them). This has worked great using reflections & generics.
You can write your own or you can use someone else's. Those are the two choices.