This will be more of a rant, than a properly done analysis, maybe that will follow at times, but for now, this is the rant-y version. So wait, let me quickly change this headline here…
Okay now it looks better.
So, for the most part of 2015 I really took a lot of time to learn about erlang a lot. I love this language. I really do. It is an amazing language and you can do so many things with it. And it also solves big problems with super large scaling applications with such elegant ease, that it amazes me to a point, where I occasionally find my self just gawking at the code, or the wiki page, or any resource about it.
Now explaining why the consideration for erlang might turn out good, is a little tough, because sure there are some downsides to it, but hear me out, and maybe you get the basic idea of why I deeply root for erlang within the next 5 years.
First things first, erlang is the best language when it comes to ultra high-available, highly concurrent, fault tolerant software. It is extremely robust, to the point that they offer the often quoted “9 nines” (as in 99.999999999% availability). Yes, you can run a software that, once started, will be able to run forever without ever restarting it. You can still update your code on the fly, with that awesome hot code reloading functionality, and sequentially add to your software without ever having to stop it.
When properly used, you can make it extremely fault tolerant. Most of the time it will just work, and if anything happens, then you can have an extra service running, that just restarts your application. So crashes can happen, and are perfectly fine, and you don’t need to waste time developing complicated fault tolerant code, because you can just let it restart and deal with the exceptions at a later time.
Next comes concurrency. With other languages, like C++, you need to learn about multi-threading, mutexes, deadlock shennenigans, in order to make a concurrent software. Ask C++ devs. Yes you can make it pretty straightforward, but as the software gets more complex, so do the security functions to avoid problems that come with memory that is being accessed by multiple threads. This problem is non existent in erlang, as the language is designed from the ground up to deal with these problems. Creating new threads is easy, running into problems is non-existent, you just need to learn the kinks of immutable state.
Did I forget something? Oh yes, scaling. When using the tools the language provides you with right, then your app will most likely scale automatically. Even throughout multiple computers. But even, if you run your software on just one server, it is proven to handle way more concurrent interactions than similar other software with other languages. WhatsApp showed how it was done, before Facebook went into rewriting it, just because they don’t have enough erlang developers.
And that is one of the downsides to it. It is not well known of a language, the tools that are available are scarce, entry is somewhat hard and the community is not big enough to easily find help with weird problems you might run into.
But this might change. As we are running into a stop of GHz power in a CPU, and start to just add more cores, erlang has what it takes to be ready for this problem with ease. Where other programs need to adapt to multi-core programming patterns, erlang is ready for it since 1986.
Ultimately, the fact that erlang is here for so long, learned all the lessons already, is able to look chin-up into the multi-core future, and has what it needs to become the platform for the next awesome app, service, web page or platform, will show its clear advantages over all the other competitors.
Only the future will show, but I am certain that erlang will become significantly important in the near future. Mark my words, 5 years!