[cmhamill]

Not entirely on-topic, but the mention of the various language "stacks" at the beginning of the article reminded me of something I've been wondering.

Why does the de facto standard for web apps in Go-land seem to be using the built-in HTTP server provided by net/http, or otherwise having the program server as its own HTTP server?

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

It irks me a bit because I don't understand why you'd want to do it this way; it seems preferable to have a dedicated HTTP server in pretty much every way I can think of.

Does anyone have any insight there?

[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).

[mwsherman]

Well, I think one answer if that you can quickly have a running web app without another piece of software. This is an attractive quality of Node, too. In fact, if a language doesn’t have a “5 lines to a web app” demo, I consider it insufficient.

I’d posit that 90+% of apps don’t need another http server. Big apps have good reasons for a dedicated http server – unifying SSL termination, load balancing – but they are a minority.

There is nothing to to prevent you from putting nginx in front of the Go app if that’s better.

[kaoD]

I guess it's because the HTTP module works out of the box and you can still have the dedicated HTTP server using a reverse proxy like Nginx.

[kyrra]

For Go, you probably don't want to use their net/http server if you will also have it doing SSL/TLS. Go's TLS implementation doesn't support a lot of older cipher suites which could be a problem for some clients. As well, it is not as hardened as OpenSSL and others (such as possibly being vulnerable to timing attacks[0]).

[0] https://code.google.com/p/go/issues/detail?id=2445

[zsombor]

OTH there was no Heartbleed bug in the SSL implementation of Go's net/http. So much for hardened implementation. Secondly you can use go behind a http proxy, or even in an FCGI etc environment with minimal change to the code.

[icebraining]

It's to be expected that different implementations will have different bugs; that doesn't mean the Go's is better.

That said, it's an advantage of heterogeneity; you get some security by being a small target in a sea of OpenSSL servers.

[jksmith]

Custom windows servers that do failover and interceptor pattern at the same time. Try that with IIS without pulling your hair out.