[twotwotwo]

Without making grand pronouncements about The Right Way, I at least get why the Go community shies away from all-inclusive frameworks after years of using Django. An all-inclusive framework is super helpful for getting started quickly, but the way its components can be deeply tied with each other can make life tricky when you want to do some things that weren't quite what the framework authors envisioned. If you glued the components together yourself, you at least know they're separable and where they fit together.

There are popular packages for the sorts of things that a lower-level Python framework might:

- http://www.gorillatoolkit.org/ has a more flexible router, sessions, and some other basics on the Web side

- Built-in html/template is a pretty good place to start. (The context-aware escaping is something I wish I had.)

- Popular database tools include jmoiron/sqlx and jinzhu/gorm on GitHub.

- gokit.io is mostly about internal services rather than frontends, but may have parts of general interest. It includes example services.

- godoc.org links to a bunch of popular packages and has search and such. Incidentally, its own source is available: https://github.com/golang/gddo

I'd say Go is not going to get you to a releasable DB-backed Web app anywhere near as fast as Django or any of the other well-known dyn-language frameworks. I think the language has the bones where you could get that sort of app to faster time-to-first-usefulness, without entirely giving up the easy-to-follow-what's-happening and pick-your-parts aspects, but probably not there now.

[ddw]

While I agree with you and I tend to stay as lean as possible, it always perplexes me why people want a Django/RoR/Phoenix in Go.

These other frameworks are mature and battle tested enough in agreeable enough programming languages, why attempt to reinvent them in Go?

Go's strength and afaik original purpose for Google was for creating smaller services, not a web app monolith.

[twotwotwo]

The wanting part I get: a lot of people do database-backed Web apps, some of them (us!) see some useful attributes in Go and would like to have access to them in our world too.

Personally I get that appeal more strongly now that in Django-land we're well over 100K LOC and dealing with a lot more traffic and so on than when we started. Helping folks scale gracefully from "tiny app you can get going very soon" to "larger app that's still cool to maintain" might be where there's the most unfilled need.

The truly hard part is figuring out what improvements you can achieve without host/graft disease, where either the language itself or softer factors keep the mashup from working satisfactorily.

That is, one way to fail at improving DB-backed webapps in Go is the obvious one: you don't actually make them easy to build. Another is if you do make it easy to get started, but in the process lose the things that made it appealing to use Go. Those might be "hard" technical attributes like static checks and decent perf, or "soft" human- and standards-oriented things about Go: flexibility in choosing libs you want, or norms favoring explicit code where it's possible to work out what's really running from what's on the page.

Feeling out those tradeoffs is probably a long, communal process with a lot of trial-and-error. Certainly it's slower and harder than just trying to translate the dyn-language tools already out there. But I think it is possible and could be really useful.

[erikb]

Great answer! Starting to learn the components with Ruby on Rails or Django and then moving to Go, gluing parts together seems to be a good way to get from zero to great apps.