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.
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.
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.