[cies]

No you dont. Sorry for the blunt answer.

ORMs are a bad idea, even when using OO langs: they make the simple queries slightly simpler (`Users.getById(id: Long)`), they do not help you for hard queries (ORM-using codebases of size usually have hard-SQL-queries "in strings").

Most users of FP langs know this and hence will not even try to implement ORMs.

Look into jOOQ, LINQ-method-syntax (or whatever it is called, without the funny SQLish syntactic sugar), SQLDelight or sqlx for non-ORM options that improve embedding SQL in general purpose langs.

[rafaelmn]

I like the idea of F# type providers but last time I tried (two years ago) they were pretty shit compared to any mainstream ORM/alternative - has that improved ?

Also ORM for simple row selects is a straw-man - their use case is deserializing, updating relationship graphs where they hide away a bunch of code. Should that code be hidden is a different question - but pretending it's there to save you from typing SELECT * FROM foo is kind of disingenuous. Editing graph data structures in most FP languages is just not compatible with OOP approach hence no ORM.

[jcmontx]

Most of the time we do simple CRUD operations, I want this plumbing to be as straight forward as possible. Don't be patronising...

[Dansvidania]

I am always confused by this wish. If the operations are simple, why the need for ORM?

[cies]

And the notion of lazy associations, life cycles, clean/dirty, attached/detached, ... etc, etc.

The book of Hibernate is thicker than the book for SQL.

The only thing that works better in ORMs is "save". Just call save on an ORM managed object and it is saved, quite a bit harder in SQL.