[Jtsummers]

Erlang's model is entirely appropriate, but the language and VM aren't. This code is often running on small embedded chips (so you'd need to port the VM) and the software has hard real-time requirements, which the Erlang VM is not (currently) set up to handle, nor would it necessarily be able to achieve on the commonly used processors. Another strike against the language (as much as I love it) is that it's dynamically typed. That's less appropriate for this sort of software. There are static analysis tools for Erlang that mitigate this, but it's still an issue. Large classes of bugs and errors can be eliminated or minimized with statically typed languages or with static analysis tools if they're well integrated into the build process. A real-time, statically typed language with Erlang's semantics and compiled to native binaries would be a boon, however.

I'll speak to the 787 avionics system. It used a system of channels/buffers and processes very much like what Erlang and Go use for interprocess communication (I'm trying to remember now if channels could be received in multiple processes like Go or if only a single process could receive like in Erlang). This was an excellent model for what we were doing, and really for a lot of systems this sort of CSP and actor style model maps well.