Don't use any framework.

You can use a dispatcher library like httprouter to get slightly more convenient URL routing and parameter capture. There are a whole bunch of "middleware" libraries that intercept requests and provide sessions, CSRF protection, &c --- and no one "framework" provides all of them.

But keep net/http visible in your code. It'll maximize compatibility with other libraries, keep you from having to write bizarre shims, and ensure your code is idiomatic.

When someone writes a library that coherently unifies persistence and request handling and view rendering, it'll be time to consider frameworks. But current Golang frameworks aren't ambitious enough to be worth the headache of, in effect, coding to an idiosyncratic alternate universe of request handling.

If you want to render HTML, there's a lot of security features that you won't get with micro-frameworks. And even Beego and Revel have a lot to do to catch up with Rails and Django. So for this type of apps, I would stay with Rails or Django for now (depending on your preferences).

If you make REST APIs, then you can use a micro-framework because there will be less boilerplate to get to what you want. Goji and Gin offer great performances compared to Gorilla, Martini and the others.

I see a lot of companies using Rails or Django for their main app and Go for their background processes. I think this approach is a good first step to get better performances and knowledge of Go, keeping the productivity of these frameworks to render HTML apps.

Yes, I also think, if you're the kind of developer who wants a framework: Rails is probably an objectively better choice. My default "stack" is Rails front-end and Golang for JSON RPC stuff on the backend. Golang is nowhere close to Rails in terms of flexibly converting an SQL database to HTML.

My experience of building complex web stuff in Golang is very similar to my experience of doing the same with Sinatra: you inevitably realize about 1/3rd of the way in that you're really just building an underspecified, undertested version of Rails itself.

I have been long time Django/Flask users, and undoubtedly a good web frameworks give you some structures, security and impose good practices to new programmers, that's what I'm trying to find out. I'm not very aware of how advanced Go Framework are, but if there is something that could replace nicely my current Python web stack, I would be happy to give it a go.

You may not see this now, but does building a(n) SPA change your thinking on this at all?

(Assuming you build those, and I'm not suggesting that it would--more looking for additional viewpoints.)

I use martini, I know it's notoriously the most hated framework for go, but I find myself very productive. With martini and gorm/mgo I can get apps up and running VERY quickly. Its never been a bottleneck for performance for me. I know down the line I'll try something more efficient, but the fact I'm able to develop CRUD apps at a rapid rate helps my job and helps me find more work.

I'm enjoying beego. It provides most of what I need. I don't use the ORM because I like the flexibility of lib/pq + sqlx.

I could do without it, but I like what it offers. The bee tool is nice. It lets you quickly bootstrap an app and using bee run provides hot recompile when your code is changed.

Beego docs are pretty good and the developer is very responsive to github issues.

I've tried them all. I went from the extreme of Revel (very rails-like) to straight net/http. I ended up using Goji for my most recent API and really like the feel. It's very close to net/http with just enough candy to make it easier on me without losing straight net/http compatibility.

Happy Revel user here. If you have any questions I'd be happy to share my experiences.

I've been reading this before trying beego and it kind of push me to try Beego first http://madewithdrew.com/blog/choosing-a-go-web-framework/

What did you build with Revel? How would you compare to your previous web framework?

A simple data gathering and report building app. The previous web framework was Perl/Mojolicious, but that is not a good comparison.

I looked at net/http and needed something a little more, but not too much more. I like that it only has 1 templating choice and no notion of a database / ORM. It feels like net/http on steroids.

goji, mainly because it supports einhorn