My Love Hate Relationship with Erlang

Yeah it’s true, lately I had a relationship with Erlang!! But unfortunately it turned out to be just an infatuation. Erlang is like most of attractive girls - looks promising from far but a real turn off when you interact with them. No, in-fact a lady not even a girl, it’s been there from two decades :-).

I have been interacting with Erlang from a year or so. No doubt it’s a powerful language best suited for mission critical system, effortlessly distributed in nature, no one can match its super scalability, inherent support for fault tolerance and its real hot - hot code swapping. Erlang is a Special purpose language.

With the evolution of multi-core culture from last few years it is getting lots of hype for wrong reasons. If you are among those who are attracted towards Erlang with overrated hype that it’s the next big thing and it will replace languages like Java or Ruby in near future, I beg to differ though. It has its own target audience but NOT general purpose programming language in true manner.


In this blog I will talk about “hate” of my love-hate relationship with Erlang. There are hell lots of reasons to dislike but here few of them:

Ugly Syntax - No dressing sense

Biggest turn-off for a developer interested in Erlang is its very very very ugly syntax. Today most of the developers are familiar with Java/Ruby/C like syntax whereas Erlang syntax is inspired from Prolog. It would take ages to get comfortable with its syntax and even after a year or so I struggle with it.

Bunch of confusing terminators

To end an expression you have as many as four terminators (explored so far).

1. Comma(,)
2. Period(.)
3. Semicolon(;)
4. No character()

It looks funny to start with, a bit confusing and irritates you in the time.

I will show you with this example:

is_valid_user(true) -> take_action_1(), take_action_2(); is_valid_user(false) -> take_action_3().

And if I want to reorder the flows, you can’t just cut and paste code from here to there:

is_valid_user(false) -> take_action_3(); is_valid_user(true) -> take_action_1(), take_action_2().

Or swapping the calling order of two actions, here again you have to take care of positional terminators:

is_valid_user(true) -> take_action_2(), take_action_1(); is_valid_user(false) -> take_action_3().

As you go along with the language if clauses, switch statements etc. are even more difficult to get syntax and terminators right. I can’t imagine how a developer can re-factorize code without having bunch of stupid syntactical errors. In short, you either has to be mental to get it right in one go or Erlang syntax with make you metal with series of errors.

Erlang syntax is a huge productivity killer!!

Big Bulky Strings

Erlang is a BIG NO NO as a language choice if your application or business logic involves fair bit of String and String related operations. It is the most in-efficient String implementation I have seen ever.
It’s hard to digest but in Erlang each character in a String eats 8 BYTES of memory. Yeah 8 BYTES/character!! Because Strings are internally implemented as list of characters are having 4 Bytes for each character and another 4 Bytes having pointer to next character in the string.

Let’s add insult to injury, given the fact that Erlang is functional in nature which means all variables are immutable in nature. So, I you want to modify a string you have to create a new string out of modified elements.
More insult, imagine message passing this string to say 10 processes and remember copying occurs during message passing in Erlang.

Final thought, don’t even think of Erlang once for performance oriented text processing applications.

Terribly Slow I/O

Yes it’s a known fact, Erlang’s io:get_line is TERRIBLY slow ! Problem is it reads the file content character by character. Actually it’s not an inherent problem with language rather more of an implementation shortcoming of virtual machine.
However, inefficient line-reading mechanism is not an excuse for any programming language it’s a big shame! Languages like C, Java, Ruby and others deal with line-based I/O quite efficiently.

Lastly just club the last two points; you can imagine slow sluggish performance of application involving text based processing of log files.

Closing my post here, I will cover remaining points why hate Erlang in my upcoming post. Remember I equally Love this language as much as I hate, so will cover most incredible features of this language in my next post.

Thanks.