Having experimented with golang a bit I don't see any significant advantages over other languages in interfacing with sql dbs - the db drivers return rows which

Having experimented with golang a bit I don't see any significant advantages over other languages in interfacing with sql dbs - the db drivers return rows which you convert back to your objects, and it's up to you to wire up the objects and relations from that, and there are even a few issues like calls to insert not returning the rowid inserted so you have to call LastInsertId for Mysql/sqlite (last time I used it). You still have to decide how rows returned are converted back to your golang objects, deal with nils, relations etc, all that logic has to go somewhere, and it's not in the db drivers. The problem with ORMs is not with just storing data, that's pretty simple and you don't even really need an ORM for that. The most difficult problem comes when you introduce complex relations, and need a way to retrieve those datasets from the database. AFAIK golang does not help you in any way with that, so you'll have to invent your own ORM and conventions for representing things like belongs_to, has_many and join relationships. If you have join tables you'll be doing the relations yourself which is not always simple or performant - this is what ORMs are useful for. Clearly ORMs break down in apps of a certain size and have their own issues (largely due to non-optimal SQL and/or a reluctance to break out of the ORM when necessary), but every app contains the sort of logic which is in an ORM, because it must map storage to in-memory and view representations. If you have logic to convert *sql.Rows to your objects, including relations, you have written a simple ORM.