I absolutely love Erlang and think that, along with Clojure, it provides a complete ideology for developing modern software.
But the article implies (and more than once) that the rover's architecture borrows from Erlang, while the opposite is true. Erlang adopted common best practices from fault-tolerant, mission-critical software, and packaged them in a language and runtime that make deviating from those principles difficult.
The rover's software shows Erlang's roots, not its legacy.
It wasn't the intention to imply that one borrowed from the other. The concept of isolation and virtual memory protection goes back to at least the 60'es for instance. It would be unwise not to take the knowledge into account - even though we are extremely good at forgetting our past in this industry :/
The key take away is that these methods seems to work. They worked in a setting of C code on the existing rovers as well as the newest one. They worked on large telephony switches written in Erlang. My guess would be that many other mission critical systems will posses the same traits.
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.
But the article implies (and more than once) that the rover's architecture borrows from Erlang, while the opposite is true. Erlang adopted common best practices from fault-tolerant, mission-critical software, and packaged them in a language and runtime that make deviating from those principles difficult.
The rover's software shows Erlang's roots, not its legacy.