<story><title>Why Erlang Matters</title><url>https://sameroom.io/blog/why-erlang-matters</url></story><parent_chain></parent_chain><comment><author>atemerev</author><text>AFAIK, Erlang is still (as of 2016) the only distributed actor model implementation with preemptive scheduler.&lt;p&gt;All other major implementations (including Akka) have cooperative scheduling, i.e. forbidding blocking code in actors. Erlang allows it. This is huge.&lt;p&gt;And actor supervision is the best way to write reliable systems. I have wrote some code in Akka without much effort and testing (streaming market data aggregation), and it is still running with a few years uptime.</text></comment>
<story><title>Why Erlang Matters</title><url>https://sameroom.io/blog/why-erlang-matters</url></story><parent_chain></parent_chain><comment><author>jandrese</author><text>I&amp;#x27;m a very green Erlang noob, but given what I have seen from it I find articles like this kind of strange.  Sure concurrent programming is difficult and we need to think hard about how to make programs run quickly in a multiprocessor environment, but the fundamental architecture of Erlang seems to be in conflict with big data and high speed computing.  It seems like a language that can scale much better, but has such enormous constant time penalties that the scaling can&amp;#x27;t overcome the hurdle until you&amp;#x27;re talking about thousands of processors.&lt;p&gt;Every single state change requires a function call, every function call involves a pattern matching algorithm that has to account for all of your program arguments (effectively almost the entire state of your thread!) and isn&amp;#x27;t even strongly typed.  And then there is synchronization and data sharing between threads, which seems a bit handwavy and effectively requires a database running in your program that the threads can poll.&lt;p&gt;If your problem set is lots and lots of small independent tasks that don&amp;#x27;t have to finish overly quickly, then Erlang is fantastic.  Stuff like switching voice circuits for example.  But I&amp;#x27;m trying to imagine manipulating a 1TB dataset with thousands of worker threads if you have to make a copy on the stack for every change every worker makes.&lt;p&gt;I know people do some big data stuff with Erlang, so these have to be solved problems somehow, but I can&amp;#x27;t help but to suspect that they have to compromise some of the ideals espoused in this article to make it work.</text></comment>