If a framework is going to solve approximately the same set of problems for me as Sinatra, I'm not sure that's a big enough win over what Golang already ships with.
So out of curiosity, when you do web development, do you use an ORM-less framework, or do you simply not use the ORM that's included/recommended?
Flask of Python does not ship with one.
Want more?
There's certainly not an Active Record -esque ORM for Go, but that doesn't prevent you from writing a very simple model layer. Write a few structs to represent your models, and use database/sql (or another DB interface) to unmarshal your response into the struct as needed.
i.e.
type User struct {
Id int
Email string
OAuthId string
Created time.Time
Active bool
}
user := &User{}
err := r.Table("heroes").Get(user_id).Run(session).One(&user)
fmt.Printf("%s", user.Email)
I'm finding that the code to do this is no more verbose (if at all) than writing out my models.py in Django.
I cant even express much little I like that api.
Lets just start with: no comprehensive test suite to make sure drivers work, drivers that don't work (or work 'if you use the api in a particular way only; which defeats the purpose of having an api), no cross database support.
There are some good database apis, but using database/sql wouldn't be my advice (hint: use a c binding to a cpp orm).
I haven't heard of lots of people using database/sql; most shy around from it for mongo or similar as far as I'm aware.
https://github.com/robfig/revel/tree/master/samples/booking/...
I want to replicate SQLAlchemy's relationship and ORM features in Haskell; I haven't sat down to work on it yet, that's my next free-time project.
Can I email you on your email address I found via your HN profile so we can share ideas?
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.
https://github.com/chuckpreslar/librarian
No where near perfect and needs a lot of work. By no means am I a SQL expert so I'd love some help.