The Java protection model is in many ways less strict than the process isolation model exploited in Erlang. Giving each programmer responsibility for their pool

The Java protection model is in many ways less strict than the process isolation model exploited in Erlang. Giving each programmer responsibility for their pool of classes may sound like a good way to limit their ability to damage the rest of the system, but as long as anyone else is dependent on the stability of their API (and the absence of unchecked runtime exceptions), a single bad line of code can easily bring down an entire system. Also, while it may technically be a "functional" language by virtue of disallowing destructive update of values, it really reads more like a scripting language. Variables are dynamically typed, and the functions only have an arity, not a signature. Programmers used to the expressive type systems and polymorphism of more "academic" functional languages like ML or Haskell, on the other hand, would probably chafe at Erlang's lack of support for any abstractions other than forking and message-passing. Real rocket scientists, on the other hand, would probably like Erlang, since the semantics of the language are simple, and its fault-tolerance and concurrency features could be well-suited for high-availability systems like mission data collection. (Its lack of hard real-time features make it a non-starter for actual avionics.)