OTOH, I'm not particular fond of ORM as a universally right solution for dealing with DBs (its a solution which makes sense for some DB-related issues in some OO languages, but isn't something that should be reflexive "deal with DB, need ORM"), and its probably not a solution I would reach for for any problem in Go even whether or not you could reasonable do it in Go.
Extensive use of reflection (in Go, this takes the form of type assertions) proceed to make it fundamentally possible again, but they have lost a lot of conciseness, certainty of safety and correctness in the process.
Personally, though, I've been migrating to "SQL calls" and "some support code to manage the rows coming back" even when not using Go. ORMs are this enormous pile of complexity, and it's amazing how easy it is to recover the vast bulk of their utility just by writing a bit of SQL. Use a decent SQL generator (as opposed to bashing strings together) and you're even closer. By no means is it a "full replacement", but I'm increasingly of the opinion that the costs of ORMs tend towards the staggering and the benefits minimal, for any nontrivial project. Possible exception for the really good ones that have been developed for a long time, but most of the ones used in the open source world are pretty dubious, IMHO.