Erlang is best suited for online applications (as opposed to batch processing) that require handling a high-rate of concurrent events and need to be fault-tolerant (highly available). Erlang was designed with those applications in mind, and provides just the right abstractions (and no more) for implementing them correctly and efficiently (like light-weight processes with mailboxes, complete process isolation, and supervision hierarchy).
But what I like most about Erlang (and I like Clojure for the same reason) is that it is not a kitchen-sink aggregation of programming language features thought to be useful or cool (like some other languages that I won't mention), but a perfect (or near-perfect) mix of just the right features, all made to work with one another in synergy.
In other words, Erlang, like Clojure, does not say, "here are the features you can program with", but rather, "this is how you should program". And the features these two languages provide are, I think, just the right ones for developing software with modern requirements (scaling and high-availability) on modern hardware (concurrency).
Erlang's features, however, do tend to focus more on programming in the large, or high-level software organization (they helps making your software scalable and fault-tolerant) and less on low-level constructs (it's hard or impossible to write a super high-performance data structure in Erlang). It delegates those low-level problems to units written in other languages. Clojure is the opposite, I think. It's designed to make building correct and efficient data structures and data-processing functions easy, but provides little guidance to high-level organization of complex, large software.
Both are also relatively easy to learn, which only shows their elegance (though Erlang does suffer from a somewhat antiquated syntax owing its origin to Prolog).
I'm curious too. The author implies that Erlang lets me manage memory explicitly like C does so that I can, by design, guarantee I never run out of memory and never get a GC at a critical time. How does Erlang handle that?
Erlang still uses GC, however because there is no shared memory (except ETS[1]), the GC can run independently for each process. This is eons better than JVM[2], with all the benefits of not having to worry about manual memory management. It’s not C, though, and I don’t believe author implies that in any way. In fact he acknowledges the exact opposite.
I wouldn't say it is "eons better than the JVM". The JVM GC, especially the new G1 collector, is probably the most advanced and performant garbage collector available on any platform. Erlang, however, does provide isolation.
There are versions of the JVM for hard real-time applications (Erlang is for soft real-time only), that provide explicit memory management, and a very fine-tuned GC, like this one: http://java.sun.com/javase/technologies/realtime/index.jsp
Mind telling me more about the fault-tolerant abilities/properties of Erlang? I'm not really able to conceptualize it right now. Maybe an example? :) Thanks.
