Why Erlang Matters
I&#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&#x27;t overcome the hurdle until you&#x27;re talking about thousands of processors.<p>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&#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.<p>If your problem set is lots and lots of small independent tasks that don&#x27;t have to finish overly quickly, then Erlang is fantastic.  Stuff like switching voice circuits for example.  But I&#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.<p>I know people do some big data stuff with Erlang, so these have to be solved problems somehow, but I can&#x27;t help but to suspect that they have to compromise some of the ideals espoused in this article to make it work.