Disclaimer: I love Erlang. From 2005 to 2015 I ran erlanger.ru (mostly alone, as editor-in-chief, content creator, developer — you name it). It is my favourite language, and this isn’t going to change any time soon. Exactly because I love it, I see problems with it.
Other languages are getting better at being Erlang than Erlang is getting better at being other languages.
Erlang is first and foremost Ericsson’s baby. Thus, enterprise and telecom are the two things that influence Erlang the most. It is Erlang’s greatest strength and it’s greatest weakness.
Enterprise side of things made sure that Erlang has got to be one of the most stable languages out there:
Breaking changes, if any, are introduced very rarely, with clean and understandable upgrade paths often split over multiple releases.
New features are folded into the language or the standard library after a lot of careful deliberation and on an “absolutely needed” basis. They are also introduced gradually, often over the course of several releases.
Telecom side of things made sure that Erlang is also probably the language that got more things right from the start (or nearly from the start) than any other language:
immutability, gen_* patterns in OTP etc.
The problem, however, this no longer matters.
A Brief, Incomplete, and Mostly Wrong History of Erlang
1990s: Erlang is lightyears ahead of anyone with processes, distribution, OTP etc.
early-to-mid 2000s: Erlang is on the bleeding edge with SMP, distribution
late 2000s to mid-2010s: Erlang is … mainstream at best
Java is the new Erlang
This may be hard to swallow, but Java is the new Erlang. And other languages either piggyback Java, or are fast developing to provide competition in many areas.
Let’s look at the most common tools that everyone uses or knows about in areas where Erlang is supposed to shine: Hadoop, Kafka, Mesos, ChaosMonkey, ElasticSearch, CloudStack, HBase, <insert your project>.
For every single of your distributed needs you will take Java. Not Erlang.
In other rapidly developing fields such as IoT, there’s Java again, C/C++, Python. Rarely, if ever, Erlang.
And the trend will only continue. Server management and monitoring tools, messaging and distribution, parallel computing—you name it—sees an explosion of tools, frameworks and libraries in most languages. All of them encroaching on space originally thought to be reserved for Erlang.
Erlang Is the New … Nothing, Really
While others are encroaching on it’s territory, Erlang has really nothing to fight back with.
Even today Erlang is a very bare-bones language. An assembly, if you will, for writing distributed services. Even if you include OTP and third-party libraries. And, as a developer, you have to write those services from scratch yourself. Not that it’s a bad thing, oh no. But in a “move fast and break things” scenario having to write lots of things from scratch may break you, and not others.
Erlang is a language for mad scientists to write crazy stuff for other mad scientists to use or to be amazed at (see my lightning talk from 2012)
Anything else? Well,
There’s Java for anything related to distribution
There are Python’s great interfaces to scientific and statistical libraries
There’s basically any language for strings, images, graphs, database interfaces—anything, I tell you
This leaves Erlang… well, in limbo.
Is There Hope Yet?
I really really don’t know. I really hope though.
Due to its heritage Erlang will evolve slowly. It’s a given, and it’s no fault of the brilliant people who develop Erlang.
Other languages for the Erlang VM? Maybe. As we have seen with Elixir, in three years it’s got more development (both in the language itself and in the available libraries) than Erlang got in 10 years. We can only hope the drive will not subside. Will there be a “Hadoop.ex” to rival the Java Hadoop? I don’t know.
Incidentally, a lot of the praise that now comes towards Elixir mentions Erlang only in passing. As in “compiles to Erlang” or “runs on Erlang VM”. And may be this is exactly what Erlang needs: become for (Elixir|LFE|Efene|…) what JVM became for (Scala|Clojure|Groovy|…)?
Erlang is far from dead. It’s alive and kicking (some butt, if need be). Will it do that for long? In a “let’s choose between languages A, B, and Erlang for scenario X” will there remain a scenario X where Erlang will remain relevant and/or a valid choice?
I don’t know. I sure as hell hope.
I’m trying to do some good myself. I’m not bright enough to create something like the libraries mentioned here, but there’s neo4j-erlang and pegjs for what it’s worth.
No, this is not really a post about the upcoming Designing for Scalability with Erlang/OTP. Erlang is nearly unique among other programming languages in that almost all of the books on it are in the good to great range. This book is going to be no exception.
No, this is not about Erlang per se, as other languages have the same problem. But Erlang is a poster child for “scalable distributed 99.999999% cloud developer-to-user ratio <insert the next current rave here>”.
Recently I twitted:
Every single book on #Erlang spends 99% of text on reiterating the same basic principles. Most of them are worse than LYSE
This is a bit harsh. May be not 99%. And not necessarily worse. So, what do I complain about? Most books mostly concern themselves with “draw some circles”. Reality is quite often “draw the rest of the owl”. There is almost no info on the intermediate steps in between.
Scalability is the capability of a system, network, or process to handle a growing amount of work, or its potential to be enlarged in order to accommodate that growth.
To scale horizontally (or scale out) means to add more nodes to a system, such as adding a new computer to a distributed software application.
To scale vertically (or scale up) means to add resources to a single node in a system, typically involving the addition of CPUs or memory to a single computer.
So, in the case of Erlang, which is described as, praised for being, marketed as being scalable, distributed, durable, resilient etc. etc. it would be really nice to read up on at least some of these things:
setting up multiple nodes
testing a distributed app
deploying a distributed app
handling load balancing
handling netsplits (and not only in Mnesia. If we can add a process on node B to a gen_supervisor on node A, how do we handle netsplits, timeouts, restarts etc.?)
discovery of nodes
various VM options and their impact
securing connection between nodes
mitigating overflowing mailboxes
working from behind firewalls
<add your own>
Funnily enough, in an out-of-the-box Erlang:
there are zero answers to some of these questions, so it would be nice to find out how this can be solved (consul/etcd for node discovery? how? and similar questions)
already has excellent tools, but very little info on best way to use them: profiling, tracing, remote inspection (redbug, do you use it? etc.)
has performance problems with poorly documented workarounds or third-party solutions for some situations (running across thousands of nodes or thousands of cpus comes to mind)
has support for some scenarios, but very little info on them (there’s a total of about 1000 words on large scale testing with Common Test in the docs for example)
Unfortunately, most existing books emphasize beyond measure only one single aspect of Erlang: OTP. Even though OTP is no doubt essential to creating robust scalable distributed applications, people looking for the answers to questions above already grok OTP :) They already know how to draw the circles.
If you’re looking for answers, though, the landscape in Erlang books is quite bleak.
Among the commercially available it looks like only “Mastering Erlang: Writing Real World Applications“ doesn’t fall into the trap of spending all of it’s chapters on OTP with only one or two chapters dedicated to something else. (Update: I’m not even sure this book exists. It looks like it’s been “Coming soon” since 2010. Except perhaps here)
The other notable exception is the excellent “Erlang in Anger” which answers quite a lot of the questions above.
We’re quite ready to move beyond drawing circles. Some of us are not yet ready to draw the entire owl ;) Hjälp!