[simondotau]

An ORM only saves you boilerplate if you’re mapping relationships to objects. And if you’re doing that, you haven’t learned good data modelling and normalisation.

ORMs are for storing objects.

SQL is for correctly modelled data.

[gmac]

There's a middle ground between ORMs and raw SQL, especially if you're using a strongly typed language. My library Zapatos[1] is one example among several.

[1] https://jawj.github.io/zapatos/

[simondotau]

That does look like a compelling tool specifically because it isn't really an ORM. It seems more like an ergonomics layer for SQL within that particular language. It looks decent because the database schema remains the source of truth, and the code adapts to it — not the other way around.

I think ORMs mostly exist because most programming languages tend to lack an elegant way to write SQL and interact with results. Somewhat ironically, the much-maligned CFML (aka ColdFusion) got this right decades ago. It made SQL string building trivial, and it provided a native data type for tabular query results.

No other language I'm aware of has this, and it's the missing piece in many modern ecosystems. They do not need an ORM. They need better ergonomics for interacting with databases: a clean way to compose queries, execute them, and work with the result as structured relational data rather than shoehorning it into application objects.

[9rx]

> They do not need an ORM.

What you do need is some kind of boundary mapping layer so that your application isn't tightly coupled to the database. That might be a an RRM instead, but if you are going to all the trouble of adding an RRM, why not an ORM? What's the difference, really?