Why I Program in Erlang — Evan Miller
No matter how blocking and concurrent your application logic is, it is impossible to make a blocking network call in Erlang, or to spawn multiple OS processes. This design decision makes it so that an Erlang server will never crash the operating system. Having lost many nights of sleep to overloaded operating systems at a previous job, I believe that Erlang’s concurrency design is correct.
take string concatenation. If you pop open the implementation of string concatenation in Perl, Ruby, or JavaScript, you are certain to find an if statement, a realloc, and a memcpy. That is, when you concatenate two strings, the first string is grown to make room for the second, and then the second is copied into the first. This approach has worked for decades and is the “obvious” thing to do. Erlang’s approach is non-obvious, and, I believe, correct. In the usual case, Erlang does not use a contiguous chunk of memory to represent a sequence of bytes. Instead, it something called an “I/O list” — a nested list of non-contiguous chunks of memory. The result is that concatenating two strings (I/O lists) takes O(1) time in Erlang, compared O(N) time in other languages. This is why template rendering in Ruby, Python, etc. is slow, but very fast in Erlang.
Refactoring Java or Objective-C code usually becomes necessary because too many instance methods have been added to a class, and the developer must spend time figuring out which methods require which instance variables and how to best cut the carriage in half. This is simply not a concern in functional programming; moving a function to a different module requires very little hand-wringing and virtually no effort. “Refactoring” Erlang usually consists of breaking large functions down into smaller functions. There is not much mental effort involved; however, due to Erlang’s syntactic peculiarities, it can be tedious converting anonymous functions to named functions. Perhaps a clever IDE will eliminate this tedium one day.
I find that the transparency of data structures in Erlang makes programming much easier. In object-oriented programming, I am always worrying about what to name things; in Erlang, it usually doesn’t matter, as the data structure is half the interface. If you have never programmed in Erlang, you probably have no idea what I am talking about.
Functional programming is tough, and Erlang doesn’t put any sugar on the pill. The graphics toolkits are primitive, and there are no fill-in-the-code computer games such as are found in introductory Java courses. Reading any non-trivial Erlang code requires a firm understanding of recursion, a kind of abstract thinking that many people find difficult.
To a seasoned hobbyist programmer like myself, the only truly bad news about Erlang is that it is slow. For the server applications I have written, the speed of the language has not been an issue; the extra cost in CPU was more than made up by Erlang’s correct handling of garbage collection, network I/O, and string concatenation in a concurrent environment. In the language of complexity analysis, Erlang programs tend to have a large constant out front but excellent asymptotic properties.