It's meant to be a nicer interface on top of the net/http server. In reality it's very difficult an ambitious web framework (like Rails) in Go.
I wouldn't recommend Revel to many (it's Play heritage isn't well suited to Go, IMO) but the Gorilla toolkit—a collection of useful packages that extend net/http, rather than a full-blown framework—is exceptional. mux/pat, schema and sessions are all such useful tools and I've been working with them for a couple of months [in my spare time] as I build a web app w/ Go as a non-programmer.
Some other solid Go web packages/tools:
• beego (https://github.com/astaxie/beego) - a well-maintained, active project if you want to head down the framework route. Closer to Sinatra/Flask than Django/Rails.
• "Bones" (https://github.com/peterskeide/bones) - a useful template for an application/some good design patterns
• nosurf (https://github.com/justinas/nosurf) - CSRF middleware that plugs into net/http (and therefore works with gorilla/mux or pat)
• gorilla/context (http://github.com/gorilla/context) - request context. Great for passing per-request variables (i.e. CSRF tokens, saved forms, etc) between your middleware and your wrapped handlers. Set up some Get and Set wrappers around your specific keys so you can avoid writing out type assertions every time you want to retrieve the stored object.
• go.stripe (https://github.com/drone/go.stripe) - a fairly complete Stripe library.
• blackfriday (https://github.com/russross/blackfriday) - Markdown processor.
Obviously, frameworks (and ecosystems...) like Flask, Sinatra, Django and Rails have an advantage in that you can get stuff done today: they do a lot for you. And, for many use-cases, performance will never be a problem.
Saying that, writing HTTP logic in Go has been surprisingly easy, and the small amount of extra boilerplate you have to write (if you're sans-framework like me) is nice when you realise how darned fast your application is. Being able to deploy a single binary and front-end it with nginx also reduces a ton of complexity.
PS: Once I finish this thing off over the Christmas break, I'm hoping to write up a few articles on the bits-and-pieces that took a bit of time to "get right". Also have a minimalist (i.e. wraps HandleFunc, not Handler) CSRF package in the works.
Just wondering, how is that different for other compiled languages, like Java/Scala (Play) or C#? You copy all jars over, optionally put an nginx in front, and off you go. And is it really that different for Ruby or Python with virtualenv? What's the added complexity there, in terms of deployment?
Note, I don't really mean to be critical or something, rather I wonder whether there's some advantage of Go that I've not understood.
You need to install the interpreter/runtime (and sync versions/use rbenv/etc) + you need to install your libraries + ensure that they are kept up to date (i.e. virtualenv or bundle install).
A lot of this is shortcut these days thanks to rbenv, virtualenv, etc, but it's still not automatic.
I can import a ton of libraries into my Go project on OS X, cross-compile a binary (`$ GOOS=linux go build`) and upload it. If I update the packages on my dev machine, it doesn't matter. Recompile, upload, restart. This goes for many languages that compile native binaries, but Go does make it really easy.
But yes, it does sound a bit easier.
https://github.com/coreos/etcd/blob/0.2/mod/dashboard/resour... https://github.com/coreos/etcd/blob/0.2/mod/dashboard/build https://github.com/coreos/etcd/blob/0.2/mod/dashboard/dashbo...
>Also have a minimalist (i.e. wraps HandleFunc, not Handler) CSRF package in the works.
Does not compute. I'm fairly sure you're a programmer mate.
I should clarify: it's not my day job. Most of my "programming" experience has been hacking small Python things together. I do understand web security though, and a CSRF package certainly isn't a massive undertaking (it does require rigor, though).
Can you elaborate on the issues you've had? I've used Revel on one project and it was totally adequate. The automatic reloading works well, and I built a reasonably complex data warehousing app in a few days with it. Other than some awkwardness in deployment and lack of built-in CSRF filter it seems great!
In general Go libraries are at their best when they follow the unix philosophy: Write programs that do one thing and do it well. Those programs, even after being abandoned for years, still work fine. (for example: https://github.com/dchest/siphash)
They're at their most brittle when they are highly platform dependent (like bindings to some C libraries) or massive never-finished frameworks.