When you are writing a massively complex highly distributed system, you need more just than a language, Erlang is just a programming language. You need architectural patterns, you need to start thinking in term of how you distribute your system.

Erlang was specifically designed for fault tolerance, it was not designed for anything else.

I wanted to build fault tolerant systems and pretty soon I realized that you can’t make a fault tolerant system on a computer, because I think in the entire computer might crash, so I needed lots of independent computers.

One way I think Erlang was a kind of software emulating Tandem machine.

The cornerstones of fault tolerant programming are to isolate errors to make sure if one thing crash it does not crash anything else. That's what the processes in operating system do.

In Haskell, C or Java, or any these languages, that function composition will fail at compile time. Type system will say: we'll not allow you to compose things together because the types are wrong. But in Erlang, you can do anything you bloody would feel like just found together and know it at run time not at compile time. Some people think that is not so good. Some people think that is pretty cool. I will tell you why it's pretty cool. It's actually late binding, it makes decision late.

WHEN BIG SYSTEMS FAIL, THE FAILURE IS OFTEN BIG

They're going right to building them bigger and bigger and faster and faster. They'd do much better to build a system of computers and have them operate in parallel. We'd get much more done, faster. (…) My analogy is that back in the early days of this country, when they moved heavy objects around, they didn't have any Caterpillar tractors and they didn't have any big cranes. They used oxen. And when they got a great, big log on the ground and one ox couldn't move it, they didn't try to grow a bigger ox. They used two oxen.

A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.

[In the year 1957] I have just returned from an exciting meeting of the American Society for Engineering Education where I heard a paper on the new discipline of systems engineering. It is no longer sufficient for engineers merely to design boxes such as computers with the expectation that they would become components of larger, more complex systems. That is wasteful because frequently the box component is a bad fit in the system and has to be redesigned or worse, can lead to system failure. We must learn how to design large-scale, complex systems from the top down so that the specification for each component is derivable from the requirements for the overall system. We must also take a much larger view of systems. We must design the man-machine interfaces and even the system-society interfaces. Systems engineers must be trained for the design of large-scale, complex, man-machine-social systems.

It is hard to say whether increasing complexity is the cause or the effect of man's effort to cope with his expanding environment. In either case a central feature of the trend has been the development of large and very complex systems which tie together modern society. These systems include abstract or non-physical systems, such as government and the economic system. They also include large physical systems like pipe line and power distribution systems, transportation and electrical communication systems. The growth of these systems has increased the need not only for over-all planning, but also for long-range development of the systems. This need has induced increased interest in the methods by which efficient planning and design can be accomplished in complex situations where no one scientific discipline can account for all the factors. Two similar disciplines which emerged about the time of World War II to cope with these problems are called systems engineering and operations research.

a key figure in the development of applications that run on distributed collections of computers

In order to handle failure, you need two machines. [...] You have to be interested in distributed programming. You have to be interesting in parallel computing. You have to be interested in concurrent programming.

Don't be deluded into thinking that is sort of ultimately fault tolerant. You can only provision it for the faulty things that might happen and then for a large class of things it could happen.