I agree with Armstrong that it is impossible to write concurrent code in a side effect free manner. You can be sure that the code you are writing is free of dead-locks, starvation and similar problems. Even your QA team can say so after testing the program 9 times. But in the 10th run, a problem you didn’t expect might arise.

Thinking of the above paragraph, to abstract concurrency sounds like a very good idea. Factoring out concurrency code make it easy to create and maintain a solid base. The Armstrong idea is to have a generic component which deals with all the concurrency code and different plug-ins written in pure sequential code. That way, expert programmers can code concurrency, and beginners can code the sequential parts.

Software fault-tolerance is possible to achieve using basic techniques like crash catching and timeouts. The thesis also talks about a more advanced techniques using dedicated processes called supervisors, which only task is to handle error. That create two categories of processes: workers and supervisors. That way, workers have not to worry about handling errors.

I think that both, error handling and concurrency abstraction, is possible to achieve using other programming languages (not Erlang) as well. Java could be a good example. I have no experience with those patterns thou, but seems doable.

The Erlang view of the world, everything is a process and that processes can only interact by exchanging messages, helps a lot when creating an HTTP server; spawn a new process for each connection, accept a request from the client and respond appropriately. Lighttpd is a good example: high speed io-infrastructure, scalability and effective management of CPU load by using concurrency.

At the end of the chapter Armstrong talks about Intentional Programming, a style of programming where the reader of a program can easily see what the programmer intended by their code. This style is very useful when maintainability is about.