All these applications/services rely on the intrinsic scalability of Erlang as a platform.
I have to take issue with this assertion; I've seen a similar sentiment expressed here. Certainly, Erlang lets you naturally express concurrency in your application, but that doesn't automatically mean it will scale.
People have been writing high performance, message passing programs for a long time using libraries like MPI. The programming model used for creating distributed MPI applications is basically that of Erlang. The difference - and it is a big one - is that Erlang lets you do everything at a higher level with language constructs. This is a huge win.
But parallel applications don't automatically scale; scalability is a runtime behavior that depends on the problem you're solving and design decisions you made to solve that problem. How well a concurrent application will scale is usually not obvious.
There's no free lunch. You can't expect to start using Erlang and automatically get scalability. Like we've always done, you'll have to think carefully about issues such as data distribution (who has to know what when?), granularity (what's the smallest amount of work that should be parallel?) and synchronization overhead (does doing this concurrently actually cost more than sequentially?).
Erlang is not magic fairy-dust that suddenly makes you app scale. What makes Erlang different than most languages is that it does not get in your way when scaling becomes necessary. There are fewer leaky abstractions and hidden "gotchas" that will end up making your life hell. The fact that it happens to come with battle-tested frameworks for handling a lot of the dreary details for code and data distribution along with strong fault-tolerance features are nice benefits to be able to draw upon.
That all sounds excellent. I've never actually had the chance to use Erlang, but I do have experience with concurrent applications in general.
I think concurrency will be the norm in the future, so I'm excited by things like Erlang, even if I've never had the chance to use them. I just want to make point out that a language like Erlang makes solving a hard problem easier, but it's not the solution itself.
Thanks for infusing realism into the Erlang hype. As you point out "There is no free lunch". People also frequently tend to forget Amdahl's law when discussing Erlang and somehow assume that "Erlang = Linear Scaling" regardless of algorithm and problem.
I agree - however some slack can be cut to erlang - it has proven itself to be "carrier grade" (running exchanges). However, I think its most exciting attribute is reliable fault tolerant software you can bet your life on (relatively speaking !). Not so much the scalability (although its the scalability which gets all the press at the moment).
I think you can, if you really want to ;) eg think of "striping" user data and sessions across a farm of servers. You can scale out that way, yet one server goes down and some portion of users are not being serviced.
I guess that is possibly more reliable then you started with, as the rest of the servers are ok, so you are probably right.
I have to take issue with this assertion; I've seen a similar sentiment expressed here. Certainly, Erlang lets you naturally express concurrency in your application, but that doesn't automatically mean it will scale.
People have been writing high performance, message passing programs for a long time using libraries like MPI. The programming model used for creating distributed MPI applications is basically that of Erlang. The difference - and it is a big one - is that Erlang lets you do everything at a higher level with language constructs. This is a huge win.
But parallel applications don't automatically scale; scalability is a runtime behavior that depends on the problem you're solving and design decisions you made to solve that problem. How well a concurrent application will scale is usually not obvious.
There's no free lunch. You can't expect to start using Erlang and automatically get scalability. Like we've always done, you'll have to think carefully about issues such as data distribution (who has to know what when?), granularity (what's the smallest amount of work that should be parallel?) and synchronization overhead (does doing this concurrently actually cost more than sequentially?).