This doesn't look like it expands much on what the Go web server does and it also looks like it's been abandoned. Last commit was ~5 months ago from today, with most of the rest being 7-8 months ago and 40-something issues piled up. For some better web experiences in Go I'd check out revel[1] or gorilla[2]
From very quickly playing with it for a toy app, Revel is impressively easy to get started with. I do agree with elithrar that some things don't seem quite "Go-y" (variable names passed to Render turn into template data names...how?), and it sort of makes you say "huh" that today's 4 years of Go post mentions Gorilla and not Revel. Even in my short time playing wiht it part of me kind of wanted to go back to net/http to not use magic I didn't understand. Maybe that part would prefer Gorilla. But, anyway, if Gorilla is a better alternative to Revel, Go does not lack for decent Web toolkits. :)
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.
• 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.
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.
> 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).
> Being able to deploy a single binary and front-end it with nginx also reduces a ton of complexity.
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.
> What's the added complexity there, in terms of deployment?
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.
Thanks. I still don't see how that's fundamentally different from JVM or .NET languages though. Sure, your jars or asseblies might be more than one file, but they're all in the same directory. Deploy means upload the contents of that directory.
With some clever compilation stuff, you can also pack most static assets directly in your application (see https://github.com/jteeuwen/go-bindata ). This gets even more magic...
In Scala there's also an option to pack you application in a large package and distribute. It's quite a popular approach. We can use tools for this like https://github.com/xerial/sbt-pack
> I wouldn't recommend Revel to many (it's Play heritage isn't well suited to Go, IMO)
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!
I have mixed feelings about this. On the one hand its true that there are a lot of abandoned libraries out there, but on the other Go isn't like node.js. They don't reinvent the wheel with every release, and changes have been very conservative (and they have tools to automatically upgrade your code for you).
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.
1. http://robfig.github.io/revel/
2. http://www.gorillatoolkit.org/