I'm happy that Go performed so well, but the example is a bit strange for a few reasons.
First, the version of Go they're using (r59) is very old. The current stable release is r60, and most Go users have recently switched to tracking the weekly snapshots in preparation for Go 1 (mere weeks away).
Second, and most importantly, they demonstrate the web.go and mustache.go libraries. These third-party libraries were written shortly after Go was released (in 2009 or perhaps early 2010). Since then, Go's standard http and template packages have seen a lot of development and should now perform much better than web.go and mustache.go.
Third, there's a new "database/sql" package in the recent weeklies that provides a single interface to SQL databases. There are several drivers available, including sqlite, so it's relatively easy to implement the database part of the benchmarks in Go, too.
Given the task of benchmarking frameworks, I suppose the author thought it necessary to reach for a framework. That explains why he looked outside the standard library for these tools. Fortunately for Go programmers, the Go project regards http, templates, and databases as core functionality in its standard library.
I don't think this is a resounding victory for Go. It's a compiled language and yet it can only manage just over 3000 requests a second. With such a small difference in speed, I'd be better off with Python.
If you want to see some impressive figures from a compiled language, look at Haskell's snap.
web.go is very allocation heavy and unoptimized so I am unsurprised at the less-than astounding performance shown here. Also as I said r59 is very old and go has come a long way since.
Go isn't just about speed. it is also a much cleaner and simpler language than Python. Go is designed to scale programs from tens to tens of millions of lines of code.
Under the hood web.go is using the http package, so it should benefit from all the improvements, you are talking about.
What I wonder more about is if the benchmark is setting the GOMAXPROCS env variable according to the number of CPUs on his system, otherwise he has 4 cores and 3 are idling around...
That web.go handlers return a string severely handicaps its performance. It forces you to allocate for each http request, probably several times. For large responses this is crazy. The go http package lets you write directly to the tcp socket, and as such is capable of being way more efficient.
First, the version of Go they're using (r59) is very old. The current stable release is r60, and most Go users have recently switched to tracking the weekly snapshots in preparation for Go 1 (mere weeks away).
Second, and most importantly, they demonstrate the web.go and mustache.go libraries. These third-party libraries were written shortly after Go was released (in 2009 or perhaps early 2010). Since then, Go's standard http and template packages have seen a lot of development and should now perform much better than web.go and mustache.go.
Third, there's a new "database/sql" package in the recent weeklies that provides a single interface to SQL databases. There are several drivers available, including sqlite, so it's relatively easy to implement the database part of the benchmarks in Go, too.
Given the task of benchmarking frameworks, I suppose the author thought it necessary to reach for a framework. That explains why he looked outside the standard library for these tools. Fortunately for Go programmers, the Go project regards http, templates, and databases as core functionality in its standard library.
http://weekly.golang.org/pkg/