I agree 100% that the current ORM situation is early. The existing ones [1] are already very useful for simple mapping from result set to structs, and they are still under development.

Out of curiosity, what ORM do you particularly like?

My ORM experience is mostly Hibernate and some Django, and I think that they are both too advanced -- I ended up with a deeper understanding of Hibernate than I would care to admit, but it is really a minefield for developers.

It seems to me that the sweet spot is between Gorp and Hibernate -- the ORM should be able to load collection-valued properties on my struct, but it doesn't need to have programmatic query builders, a session cache, etc. I would prefer to write plain SQL, and treat the ORM as a way to map the result set into Go (with sugar for common cases like FindById and FindAll).

[1] Gorp, Jet, QBS

===

On the topic of tight integration with ORM -- I was hoping to understand what kind of integration you had in mind?

For example, I used my own ORM on top of Play 1.x, and it didn't feel any different than using Django ORM, after adding a Play Plugin that started / committed / rolled back transactions for me.

Is that the extent of integration that you meant?

===

I'll reply to the "Why not vanilla Go" question in a separate comment, since it is raised a number of times.