Itâ€™s totally worth it. Erlang (Erlang/OTP really, which is what most people mean when they say â€œErlang has Xâ€) does out of the box a lot of things we would have had to either build from scratch or attempt to piece together existing libraries to do. Its dynamic type system and pattern matching (ala Haskelland ML) make Erlang code tend to be even more concise than Python and Ruby, two languages known for their ability to do a lot in few lines of code.
The single largest advantage to us of using Erlang has got to be its built-in support for concurrency. Erlang models concurrent tasks as â€œprocessesâ€ that can communicate with one another only via message-passing (which makes use of pattern matching!), in what is known as the actor model of concurrency. This alone makes an entire class of concurrency-related bugs completely impossible. While it doesnâ€™t completely prevent deadlock, it turns out to be pretty difficult to miss a potential deadlock scenario when you write code this way. While itâ€™s certainly possible to implement the actor model in most if not all of the alternative environments I mentioned, and in fact such implementations exist, they are either incomplete or suffer from an impedance mismatch with existing libraries that expect you to use threads.
The complete original post can be found here: blog.membase.com