It depends. At the very most dynamic end, you'd encounter some troubles writing a code generator that could accommodate arbitrary joins of arbitrary combinations of tables chosen at runtime that happen to be for some reason arbitrarily joinable. This is an odd case, though; I'm sure somebody reading this has seen it and I sure it's out there, but it's probably not a case an ORM should be optimizing for. In most of the conventional uses, code generation could fit the bill, but you'd start getting into some weird declarations or something since you're not going to pre-generate every possible combination.

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.