Merrits of Erlang style for real-time systems

While that makes sense to me, when I think of Erlang I think about its history and why it was specifically created for telephone exchanges. When software is used in a real-time embedded system, halting a physical device because of an error would be a bad thing. A common way to handle such errors in a embedded system is to use a Watchdog timer.

So while what you say is true, I find that many programmers either have no to little experience with embedded systems, or that embedded system is all they do. So the concept of let it fail to someone not use to embedded system programming would sound shocking, but many don’t know that when it is allowed to fail, the watchdog timer will kick in and reboot the system. Also such systems know this and are designed to reboot very quickly. In some systems, even taking a second is to long to reboot.

As I like to often note, when you fly in a plane (Boeing or Airbus) who or what is really flying the plane. Most would say the pilot, but it is really the software running on the computers, the pilot just gives input to the computer. If the software were to crash, think of the problems.

Don’t take this to mean that all errors in a embedded system use the fail and reboot, that is also far from reality. The key difference is that in embedded systems, you just reboot as a last course of action instead of just halting.

The same technology has been moving into the automotive world for the last few decades.