Came here to say the same thing. Go won't enter "crud webapp" market until they have a better story on relational db interactions. I'm afraid this is way beyond the current possibilities of the language as it offer barely any meta-programming technics, on purpose.
Did you had a look at sqlx? [1] Granted, it won't generate the queries for you - but parsing into structs works 95% of time without additional mapping for me. Coming from other languages I also found the amount of necessary typing a bit disturbing first. But then you can actually read code instead of orm framework documentation, issue trackers and workarounds.
sqlx didn't work in my case last time i tried (don't remember why exactly), but it's still far from any standard like sqlalchemy (python), hibernate (java) , active records (ruby),entity framework (.net), doctrine (php) or bookshelf (js).
Writing every select for every entity, with all the variations depending on whether you want to inner join with 1-n relationships (and which ones) is really tedious when you've got 30 entities in your model.
We use SQLalchemy at work and I would rather write queries by hand. A lot of that is because the documentation is a huge pain, but also because the object composition isn't intuitive. I've built a profile query builder in Go and it was pretty straight forward; I'm confident I could build an ORM in a couple of weeks.
sqlalchemy ( which i used and liked a lot) has multiple layers. query builder is the bottom one, but the most "challenging" one for go is probably the orm with things lazy loading and its parametrization ( such as eager loading of relationships).
keeping it all type safe ( not having the user cast interface{} to struct everywhere) and performant would be a challenge.
I'm not sure exactly what you mean about parameterization, but I suspect in general my notion of what an ORM is differs from yours (in particular, I don't assume lazy loading). Maybe what I'm thinking isn't appropriately called "ORM" (maybe "type relational mapping" is more appropriate?). At any rate, I don't think type safety should be a challenge (somehow a mapping must be generated for each type, just like SQLAlchemy--in Go this can be either explicit or inferred once via reflection or code generation) and I don't think performance would be more a challenge in Go than any other language (the trick to ORM performance is in building efficient SQL queries, not in reflection or type asserts).
compile-time code generation can only get you so far, unless you're ready to generate every single kind of query beforehand ( which grows exponentially with the number of -to-many relationship). You'll have to rely on introspection but i suspect things won't go smoothly.
anyway, it should make for a good exercise i'm sure.
as for the definition of Object-Relationnal-Mapper the idea is to completely abstract the fact that you're storing your object graph ( or struct graph in the case of go) in a relationnal database. To do so, the developper provides meta data , like an xml file or annotation, to describe the mapping. This is a pretty hard problem.
It's not too difficult. Where I work, we're building a BI tool that maps domain concepts ("objects") to fields in relational databases (we're using Python and building out SQLAlchemy queries, but we're not doing anything that wouldn't easily translate into Go). The domain concepts are analogous to structs in Go or simple classes in Python. You only need to get the mapping data once (in our case, the user configures these mappings in the UI and then we load them at runtime, but these could come from anywhere) and from then on there is no magic.
If you know ahead of time what your types are, then you can do everything in code gen easily.
Thanks for the link, i didn't know about it. From what i see from the documentation (which looks pretty sparse) it doesn't implement lazy loading or any kind of mapping between SQL relation (1-n , n-n) to and from the go structs, so i guess it's pretty far from any of today's standard.
i've seen companies forbid the use of ORMs by fear that developpers will abuse lazy loading and collapse the db instead of using inner joins ( which any decent orm is able to do btw).
It could make sense in some context, and i'm pretty sure that any sufficiently advanced service has so many custom and optimized queries that an ORM doesn't make a difference.
however IMHO, ORMs do play a very important role in the beginning of the project when prototyping screens and apis, and when rapid iteration is important. It isn't a coincidence that RoR advertized active record as much, that symfony use doctrine in all tutorials, and that java , .net and node.js frameworks all include an ORM component.
