[ambicapter]

> Performance: It's getting much better, but the BEAM was never designed for maximum performance. People don't like slow platforms, despite the other advantages.

> Scale: much like one of the databases written in Erlang, Riak, you typically don't need a BEAM language until your solution is large enough that you've already written it in something else.

These two seem to contradict one another. How can it not be fast but scale well (I'm thinking of a way as I type this but I'll let you answer)?

[ffsm8]

Latency vs throughput.

If you just want to do 1+1, 1 million times in a sequence, then erlang will likely be one of the last to complete the challenge.

If you want to do 1 million 1+1 in parallel, then erlang will get you there with minimal overhead, even if each number crunched will take longer then java, golang etc... the way it branches out is very efficient

[bcrosby95]

When people talk about scaling they usually mean horizontally (more computers) rather than vertically (a more powerful computer).

Scaling like this tends to involve your system actually performing worse because, among other things, it has to go across the network.

[paradox460]

You can do one thing fast, or many things slowly. For many common applications, doing many things slow is more important than off-the-starting-block performance

[peoplefromibiza]

> How can it not be fast but scale well

soft realtime: Erlang gets slower with load, but keeps responding

fault tolerance: it's very hard to bring an Erlang application to a grinding halt

distribution: it's stupid easy to distribute an Erlang application and scale it horizontally