Foreword

I have been fascinated by concurrency and distributed computing for as long as I can remember. I still remember the joy of solving the classic dining philosophers problem using my own semaphore library built on top of the pthreads C library back in university many years ago. A few years later a new language called Java came along. Java made a lot of things easier for us developers; it had, for example, automatic memory management and a rich standard library. It also came with a single unified abstraction over threads and had concurrency utilities built into the language (for example, wait, notify, and synchronized), which was later expanded with the rich java.util.concurrent library. I embraced Java as my primary language of choice. The problem was that writing concurrent programs still needed too much low-level plumbing and was still way too hard. The main reason for this was that Java blindly adopted the C/C++ concurrency paradigm; shared-state concurrency, e.g., concurrent access to shared mutable state, which in most cases is not what you need and therefore the wrong default.

Over the years I have done my share of programming with threads and locks, spending late nights and weekends at the office tracking down concurrency bugs. One day I just had enough. I started reading up on alternative concurrency paradigms, in particular message-passing concurrency as implemented by the language and runtime Erlang, and dataflow concurrency from an esoteric academic language called Oz. I was amazed by both of these languages and their approach to concurrency; in particular, Erlang and its actor-based programming model. Actors raised the abstraction level from threads and locks and made it so much easier to write, understand, and maintain my concurrent code. Instead of spending time getting the plumbing right, I could focus on the workflow—how the messages flowed in the system—which made my code so much easier to understand and maintain. So I fell in love with Erlang and its actors. Actors also turned out to be great not only for concurrency but also for fault tolerance and distributed computing. I had finally found a tool that I could use to scale up, utilizing symmetric multiprocessor (SMP)/multicore machines, scale out on the cluster, and write highly available systems. Life was good.

About five years ago I discovered and fell in love with Scala. In Scala, I found a fascinating language that blended object-oriented and functional programming with rare elegance, ran on the JVM, was statically typed with the same performance as Java, and...had actors. It couldn't be better. All the goodness of Erlang on the JVM. I started using Scala and Scala's actors as my main language and tool set for writing scalable, fault-tolerant, and highly concurrent systems. This eventually led me to create Akka, an actor runtime that builds upon the Scala foundation by adding even richer tools for concurrency and distributed computing.

I have a lot to thank Philipp Haller, one of the two authors of this book and the creator of Scala actors. Without his excellent work I would probably not have started using Scala and would not have created Akka. I would have missed out on a lot of fun. I am really glad that Philipp and Frank have taken the time to write this book. Now we finally have an introductory book that teaches how to use actors in Scala and that covers both Scala's actors library as well as Akka. It is a great first step into the wonderful world of actors. See reading this book as an investment: it will help you to write correct, performant, scalable, and available systems in less time, giving more time to more important things in life.

Jonas Bonér
CTO Typesafe
Uppsala, Sweden
November 1, 2011