The future of computing is going to be concurrent. Even desktop CPUs are multicore nowadays, and when customers are buying more and more CPUs to their servers, they expect their applications to scale well to utilize their new investment. But that’s not going to happen with many software systems of today.
Handling concurrency is hard. The problem itself is hard, but it doesn’t help that the concurrency mechanisms in the widely used programming languages are low-level mechanisms compared to many other abstractions in the same languages. It’s a lot to deal with, but there are ways to make it easier.
Ralph Johnson wrote a blog post about Erlang being the next Java. Erlang has a fundamentally different view of inter-process communication, and Ralph argues that even though the Erlang style of concurrency can rather easily be added to other languages, they will have trouble competing.
I do not believe that other languages can catch up with Erlang anytime soon. It will be easy for them to add language features to be like Erlang. It will take a long time for them to build such a high-quality VM and the mature libraries for concurrency and reliability. So, Erlang is poised for success. If you want to build a multicore application in the next few years, you should look at Erlang.
And there may be more things to get as free side effects. Joe Armstrong, the creator of Erlang, wrote that the challenges of scalability, fault-tolerance and runtime upgradable systems share a solution. He said that even though these are different kinds of problems,
“a system that is fault-tolerant can easily be made scalable and easily made so that we can do in-service upgrade”.
Armstrong accredits all this to Erlang having a correct set of primitives for failure detection and for stable storage. Since Erlang was built with telecom systems in mind, all of these aspects are important, and Ericsson has built Erlang systems with an uptime of 9 nines. That translates to a downtime of 31 ms a year.
The Erlang take on concurrency differs from the mainstream languages by not having any shared state. The processes are very lightweight, and if a process wants to communicate with another process, it communicates by sending messages. This architecture makes it possible to scale and distribute systems in quite a different way than systems that uses shared memory for communication between processes or threads. To dive deeper into this way of thinking about concurrency, a good introduction of the concept (which requires no Erlang knowledge) was written by Slava Akhmechet.
Maybe it’s time to approach the concurrency problem in a different way? Maybe it’s even time to learn to new language?