What? The only possible way that constraint could be satisfied (working under any hardware failure) would be if erlang didn't let you write any programs that did anything.

The argument is that Erlang (and its OTP environment) gives you the tools to distribute your system in such a manner that hardware failure is observed and that the failed portion of the system is restarted elsewhere. The granularity provided is better than most STONITH models. It provides a lot of help, but one still needs to make an effort to assure that, e.g., merchandise is not sent unless an invoice is generated.

STONITH: https://en.wikipedia.org/wiki/STONITH

Excuse the aside, but this reminds me of this old Bash quote:

  <FreeFrag> The most secure computer in the world is 
             one not connected to the internet. 
  <FreeFrag> Thats why I recommend Telstra ADSL.

Also, agreed. Some elaboration on that point would be most welcome.

It would be nice if you could add a citation, or elaborate a little bit!

I think the parent poster's point is more that the article's extensive focus on side effects and monadic encapsulation as the central concern for reliable software engineering is short-sighted, as Erlang is a dynamically typed impure functional language that nevertheless is robust in its use of multi-node distribution, supervisor trees, sophisticated error/exception models, scheduling guarantees, SMP, dynamic code upgrade as first-class VM constructs, as well as the language itself being homoiconic and driven by a small number of basic data structures (tuples and lists).

The language's module system offers namespacing and then the OTP framework implements standard behaviors that have (in gen_server's case) state calculation, supervision, code change, termination and messaging callbacks all exported.

I presume "surviving hardware failures" was in reference to native Erlang epmd machine distribution, which is intended for fault tolerance and based on heartbeats. It's one step further than most languages go.

Ultimately, there is much more to be considered than state and side effects.

Yes, exactly. Well put :)

Even when the hardware breaks? What?

If radiation hits the CPU, Erlang won't save you.

It will, if by "Erlang" you mean "language + set of libs + set of conventions (all of this battle-tested for years)".

In short: (some) Erlang systems have backup hardware and support moving running systems from one machine to the other (or one cluster to the other, etc), achieving very high "uptime" values.

If radiation hits, oh say, a CPU register it might just change the value in a register. That is completely uncatchable and almost unobservable on modern hardware.

With any system on relying on hot switching to backups you must have a mechanism to detect errors. The mechanisms exist in many languages there are plenty of robust C++, Java, php, ruby, and sadly cobol systems out there. No new language gets to claim backups as a core feature of the language, unless cobol does too.

I am moving to my third job that has a cobol legacy system being replaced by something new. All three of these shops have backup systems that the business owners would never consider separating from their legacy cobol apps.

It is catchable and observable on modern hardware; mainframes have been doing it for years, with the operation also existing on some specialty Intel chips. Cores are paired, with each operation going through each of them simultaneously with the results compared. If the results don't match, they're run through again. If they still don't match, that pair of cores is shut down and operations are redirected.

Pairing like that would find this kind of error. It is also believable that mainframe shops would be willing to cut their throughput in half to get that level of reliability.

I was completely unaware of it even in a research setting. Yet I was aware of things like ECC RAM, RAID, Chipkill RAM and algorithms for continuous checking of results including some implemented in hardware to isolate faulty CPUs but they all added extra hardware or software and none reused existing commodity cores. Its so simple, of course it should be a thing.

Could you post a link to some reading on this?

This link from wikipedia has pretty much a good laundry list of descriptions different companies have taken for doing lock-stepping, etc https://en.wikipedia.org/wiki/Lockstep_%28computing%29 . It's also one of the reasons this level of machine is so expensive. Each mainframe core would be two cores in a "normal" system, plus mainframes have logic to decommission a cpu without needing a shutdown, by migrating the workload to a spare processor.

I only spoke with such confidence in my previous post because I thought I had worked on high end machines. I worked with a number of Sun and oracle machine with CPU failure detection and CPU hot swapping. But This feature was always flaky. I am eager to learn about what I missed.

In theory, Haskell could do that too.

Some people even started a fork of GHC aimed at cluster parallelism a few years ago, but I don't think they got it working.