And for those of you who are not cofortable running with net/http (it is a rather simple server), there is always uWSGI support for Go, which I found to be a rather brilliant idea
It's not portable (support for cgo on Windows is extremely sketchy).
It also goes against common sense. Any code you can write in C, you can write in Go, except it'll be easier (Go is garbage collected, has built-in arrays, strings, hash tables etc.) and there's drastically smaller chance Go will have a security issues due to memory over-write.
It duplicates lots of net/http functionality.
net/http is well documented, well tested, reviewed by extremely knowledgeable people.
Most importantly, it is being used in production by me and many other people.
Finally, net/http gave me everything I needed to write my web applications. Before I would even considering using uWSGI (or anything else) someone would have to explain what exactly does it provide that is so indispensable for writing web apps.
If net/http (or whatever http wrapper in whatever language) gives you enough batteries for a web application i am really happy for you.
Sadly me (and a lot of other people) need a lot more.
That is why the uWSGI project exists. Things like logging, clustering, statistics, multi protocol support, alarms, time events, request routing and blah blah are added to your app for free (and the funny thing is that you can tune lot of internals without rebuilding your app).
Obviously if not having windows support is a too much high price for you the discussion ends here :)
I did try D when it was in its early days (i.e. D 1) but at the time I was put off by lack of documentation, the standard library split (phobos vs. D) and general immaturity of the system. I'm sure things have improved since then but I really like Go's simplicity.
I've written some hundred thousand lines of production code in Go and D and feel they are very different languages. To sum it up: Go is a better C while D is a better C++.
Uh... no.
Ruby on Rails runs off a ruby webserver. Flask has its own built in webserver, web.py has its own built in webserver. Tho these are not languages, rather frameworks, (and in the case of web.py, a library), they have built in webservers
My point? These things came way before node.js, so no, node.js isn't the only one with a built in webserver.
The difference is node.js has a rather performant built in webserver (still, exeperience shows that a properly tuned gevent or netty beats a properly tuned node.js). The idea is that instead of spending time tuning these things, you can just wrap it in a uWSGI container, and let better tuned-out-of-the-box servers like nginx handle the webserving
