This book is, as far as I can tell, a competent introduction to Erlang. It feels a bit "you're probably on Windows, but I prefer Unix" in places, and it's on the practical side - i.e. lots of code examples to run through. It's a bit preachy on style and design, and waves the pom-poms for Erlang a little too hard, but most of the advice sounds sane. So, a competent practically-oriented book.
And now... Erlang? I read the book because I knew next to nothing about Erlang, and it kept getting bucketed with Haskell as one of "those" languages. I mainly knew about it for supervision trees and stuff like that.
It turns out that the core of Erlang seems a fairly small and uninspiring dynamically-typed interpreted language. It's multi-threaded, but with the only communication being message-passing. Which is fine, except for when it isn't, but the book doesn't cover that.
The message passing view of the world, together with the fairly comprehensive built-in support for serialisation/marshalling makes it good for distributed systems. Message passing plus interpreted gives you the ability to upgrade components on the fly. Message passing plus the handling of thread death gives you supervision trees.
And this seems to be Erlang's trick: The language may be uninspiring, but the conventions plus libraries allow you to build up these monitorable, failure-tolerant distributed systems, much in the same way that Java's threading model isn't particular special, but the newer concurrency libraries actually work nicely. The ideas and model could be stolen for other languages, although the explicit restrictedness of Erlang removes the temptation to do things outside its model.
In the end, what I learnt about Erlang surprised me. There was no magic in the box, but just a simple model of how things should be done that put the emphasis on simple to keep maintainability, even in the complexity of multicore distributed systems.
Yet still... this message-passing is mostly RPC in disguise, or perhaps more accurately co-routines, which gives the ability to switch implementations. I start to look at this and think there are some interesting theoretical shapes involved, and how I should have learnt more pi calculus and...