I'm by no means an expert, but I have written production Erlang applications (the instapaper-like functionality on bostonglobe.com). We initially had it running

I'm by no means an expert, but I have written production Erlang applications (the instapaper-like functionality on bostonglobe.com). We initially had it running as a network of 5 VPS systems (three web-facing servers with copies of the entire db in memory and two machines keeping disk copies), which performed more than adequately. Even with the db in memory, RAM usage really wasn't an issue for us. The runtime was initially designed to run embedded in telephone switches so it's pretty lightweight, all things considered. I've heard talk that things start to get a little hairy once you scale to around 100 nodes, due to the sheer amount of messages getting passed around (there are ways around this, like creating hidden nodes that communicate between clusters). Performance across multiple VPS systems is really going to vary dramatically between different applications and VPS setups. An app that has to make lots of requests to other nodes, which are located across the globe, is going to suffer a lot more than one that has relatively little internode communication between VPSs in the same server rack, but that's just common sense. I'd be really interested to know what companies like Basho (creators of Riak) and Facebook have experienced with large setups, as horizontal scaling is one of the language's selling points. More so than scaling across multiple cores and machines, I find that one of its strongest points is it's scheduler. If one request to a server is particularly processor intensive (or hangs), it's not going to affect other requests, which is an awesome feature to have even with a single core. Erlang's definitely not for everything, but once yo get the hang of it, it's really easy to prototype in, scales well, and is generally lightweight enough to run on a cheap cloud instance (or embedded on a Raspberry Pi).