I really don't see what having multiple app server instances behind reverse proxy has anything to do with Ruby vs Go. App servers behind reverse proxy is an architectural decision. You can write a Go web app that must be put behind a reverse proxy, or you can write a Go web app that is supposed to act as its own web server. Likewise, your Ruby app does not have to run multiple app server instances behind a reverse proxy. You can run it together with your main web server (Apache or Nginx) and you can run a single instance instead. See https://www.phusionpassenger.com/

Of course, installing dependencies still matters. For Ruby, you can just use the Brightbox Debian/Ubuntu packages.

All the mainstream ruby web frameworks require something like nginx in front of multiple instances of something like thin. You can use something like phusion, unicorn or rainbows that do forking for you instead of launching multiple processes by hand, but you still have to configure them and they're still running multiple app instances.

Go's built-in http library, and all the associated frameworks, run multi-threaded out of the box, and are fast enough that you don't need to put nginx or haproxy in front of them.

I love ruby, I've been building and deploying rails apps since 1.0, the ease of deploying go apps is precisely the type of thing the Ruby/Rails community cares a lot about: making developers' lives easier.

It is not true that they must run multiple instances. Rails has been multithreading-capable for years. Other Ruby frameworks have been multithreading-capable for much longer. With Phusion Passenger Enterprise, not only do you not have to setup reverse proxying, the sole instance can run multithreaded.

As for "fast enough that you don't need to put nginx or haproxy in front of them" - the point of reverse proxying is not performance, it's security. If anything, reverse proxying makes things slower (theoretically) because the kernel has to make one extra copy of the data. You reverse proxy stuff so that nginx or haproxy can properly handle I/O management and concurrency, and so they can sanitize HTTP headers, not because it gives you a performance boost. If Go frameworks are multithreaded by default, instead of events, then Go too can benefit from reverse proxying.

If you don't want to think about any kind of reverse proxy setup, there's Passenger Standalone in the Ruby world. You type 'passenger start', and you have a fully-functional, production ready server listening on any port you, that does not require reverse proxying.

"the point of reverse proxying is not performance, it's security."

Not true. You absolutely need forking/multiple processes on rails deployments to enable even a small number of concurrent requests. If phusion wasn't forking and load balancing between those running instances, your performance would be far lower.

EDIT: See this article from the Passenger folks on tuning a passenger deployment, it should be more clear after reading that how Passenger is dealing with concurrency (by running multiple app instances and load balancing between them): http://blog.phusion.nl/2013/03/12/tuning-phusion-passengers-...

I wrote that article. :)

The concurrency tuning explained in that article has got nothing to do with reverse proxying. You don't need multiple processes either: the article says that you can use multithreading, and especially in the case of I/O-bound apps, that's enough. If you want to leverage multiple CPU cores however, that's a different story, but it depends on your Ruby implementation. If you use JRuby or Rubinius then threads are enough. But that is still unrelated to the question of whether to reverse proxy or not.

Don't confuse being able to naively sort of multithread with a runtime that isn't hampered by a Global Interpreter Lock.

That's why there's JRuby and Rubinius.