[jerf]

"Most other languages seem to have converged on FastCGI or some similar model ({W,P}SGI, Rack, etc.)."

The languages you are citing are slow enough that the scripting language would like to slice away as much of the brute web serving load as possible so the slow scripting language can concentrate its power on the real task at hand.

Go is more on the compiled side. It's not C-fast quite yet (I expect it to eventually converge somewhere around 1.5x as fast, it's not quite there yet), but currently around 2-3x slower only (and net/http is seeing a lot of direct work on it, it's quite fast now). You don't get the big win that you get with letting nginx handle the brute string manipulation of HTTP and prechewing on it for the 20-100x slower scripting language.

Also, remember that you can view HTTP itself as a form of CGI request... really, FastCGI etc. doesn't do anything that an already very multi-threading-friendly language can't do with straight HTTP. Those standards are solving a lot of problems that Go just doesn't have, and straight HTTP is actually more general and flexible if you can afford it (no problems with Nginx being unable to stream FastCGI, etc).