How is a nine-nines reliability record (as achieved, for example, by Erlang http://stackoverflow.com/questions/8426897/erlangs-99-999999...) not relevant to safety-critical applications?

In the second example, you stand on firmer ground though.

Predictable reliability is relevant, certainly. Safety critical systems are frequently hard real-time,[0] by definition resource-constrained.

Aspects of functional paradigms are good for safety critical systems, e.g., using pure functions when possible, when it leads to more predictable and testable systems. Recursion and non-strict evaluation, however, are clearly problematic viz. stack consumption, system load, and execution time; ditto for purely functional data structures and associated functions.

[0] I'm hedging here with frequently, but I'm having trouble thinking of safety critical systems that aren't hard real-time off the cuff… perhaps supervised expert systems, say an automated pathology platform, might count?

> Recursion and non-strict evaluation, however, are clearly problematic viz. stack consumption, system load, and execution time; ditto for purely functional data structures and associated functions.

What you'd want is not a Turing complete language by default, but one that's guaranteed to halt. (And only have Turing complete bits as a fallback, just like unsafePerformIO today.)

Primitive Recursion might be a good limited but useful model of computation. Or something along the lines of Agda.

With such a more restricted notion, recursion doesn't necessarily have to be compiled to a stack.

> problematic viz. stack consumption

Not if one codes towards TCO (Tail Call Optimization): http://stackoverflow.com/questions/310974/what-is-tail-call-...

TCO doesn't address unpredictable system load or execution time. Recursion doesn't lead to predictable systems.

internally message passing, futures and actors are all about state. especially in erlang and scala. the libraries just wrapping that state so you don't need to care about.

also there is always state. look at the io front there your application needs to deal with state, if you are using fp your program maybe doesn't contain state. but the public api mostly deals with it.

Functional programming is about carefully managing your state. Ideally, you want to separate the pieces with the complicated logic, from the pieces that do the state persisting. Then each piece can do one thing and do it well.

There are lots of useful stateless services. But that's the nirvana, and not possible with all things you might want to offer.