Introduction
| This book is very much a draft and should be treated as such. Please reach out to us with your suggestions, reactions, constructive feedback, and encouragement. This is a labor of love. |
This is a book for the everyday practitioner, because when we surveyed the Actor model landscape, it appeared to us that resources fell at extreme opposite ends of an accessibility spectrum. Either literature was too abstract to be useful for the working software professional, or too specific as to have its content portable between concrete implementations. While we don’t feel that the Actor model itself is hard to understand, we do feel that the everyday practitioner, doing their best to go about building software for personal or professional advancement, could benefit from additional support. In our own work and research, we have found the Actor model an invaluable source of solutions, inspiration, and an overall benefit to improving our practice. We hope that this will fill the gap we, ourselves, ran into and allow others to dive into the Actor model and the many benefits it bestows upon those familiar with it.
Rules we try to follow
- Familiarity is good
-
Wherever possible, we chose to take inspiration from architectures with which readers will already be familiar. By putting familiar concepts in terms of the Actor model, we can compare and contrast to help deepen a shared understanding of these patterns' essential elements.
- Don’t cross the streams
-
Given the choice between a simple and a more complicated topological arrangement, we opt for the one with fewer overall edges in the graph. Ideally, the graph is also a directed acyclic graph.
- Root for team modularity
-
We will always seek to balance the functionality offered by any individual actor with the complexity and size of its interface.
- Code choice matters
-
This is a polyglot book focused more on practical applications of the Actor model itself rather than specific implementations. Ergo, we strive to use the programming language and/or framework which best expresses the given example which we’re explaining.
- State matters
-
Although one of the defining characteristics of an Actor is local state, we opt to focus on the topologies and connection patterns. Ergo, we elide various state details unless germane to the discussion at hand. ign. We make allowances and take some license with the elision of details not germane to the examples.
When not to use the Actor model
While we hope that the Actor model will provide you with additional tools for use in designing and constructing software, it is far from the solution for every problem. We specifically advise against leaning on the Actor model in cases where raw threads are required for performance reasons. We also acknowledge that your language might not have a mature, usable, or reliable implementation of actors, in which case you will surely wish to pursue another concurrency model.
More specifically, if you simply require asynchronous computation, we encourage you to consider simply using some sort of awaitaible task abstraction like futures/promises to reduce cognitive overhead. Similarly, if local state isn’t required, we anticipate that you could opt for a solution simpler than a full-flegded solution whose implementation relies upon actors.
We don’t find threads particularly ergonomic, but alternatives to threads abound nowadays. Consider, for example, the work on concurrent algebraic effects done by the multicore OCaml initiative [1].
Bibliography
[1] Leo White, “Effective Programming: Adding an Effect System to OCaml.” 2018, [Online]. Available: https://www.janestreet.com/tech-talks/effective-programming/.