One rule that should be added here, but it might be a bit late:
* choose a language that supports async operations so that you aren't waiting for external webrequests or database calls to get back to local code.
A synchronous language can turn your big, beefy machine into a single concurrent transaction language and _that_, beyond any other pain, can really, really, really reduce your total throughput.
Pick languages that can do other things while they're waiting for IO.
Well, most any language you'd use for web will have the capability. I think more pick a language that makes it -easy-.
Ruby doesn't.
Python, until recently, didn't.
Ruby does via libraries ( https://github.com/socketry/async for instance). Which is my point. Pick a language that makes it easy.
Even then, it's a bit misleading; make it so concurrency, in general, is easy and efficient. Async is immaterial if you have green threads or similar (a la Go or Erlang). Point is, you shouldn't risk a model that ends up unnecessarily blocking/synchronizing execution.
This is news to me. Very nice :)
Do you have any examples of this being used with Rails? I'm having a bit of trouble finding examples of both Socketry and Rails being used concurrently; and, I will admit, my Rails knowledge is a bit .... intermediate or less.