When Carl Hewitt invented the Actor model in the early 1970s he was way ahead of his time. (link)
The main focus of the design is to be explicit with your software models, because that’s what makes it possible to understand a complex system. (link)
What is more, event-driven, reactive applications are inherently nondeterministic. (link)
Considering state transitions, as an actor handles each newly received message, it has the opportunity to prepare its behavior for future messages. In simple terms, an actor does this by exchanging its current receive function for a different one. (link)
The actor with a pending state transition must reply to any senders whose messages would overflow its pending work capacity with some kind of “sorry, but you’ll have to try again later” message (link)
According to Amdahl’s law, the speedup of a program using multiple processors in parallel computing is limited by the time needed for the sequential fraction of the program. (link)
All this enables an actor system to support high-performance, high-throughput, and low-latency operations (link)
By becoming another kind of message handler, the actor implements a finite state machine. (link)
In other words, you can solve any given problem by creating yet another actor.
Origin of Actors (link)
Actors are a more powerful computational agent than sequential processes or value transforming functional systems” [Agha, Gul]. (link)
Years before this statement, Alan Kay commented on messaging between components as “the big idea” that should be the focus, rather than the properties of objects and their internal behavior (link)
Perhaps you are at the inception of a strategic enterprise project. Compared to what you have previously been able to achieve with “normal” enterprise development tools, your strategic application may have to perform and scale off the charts. You are considering the Actor model to help you attain the inflexible and otherwise unreachable requirements. Beyond performance and scalability demands, you need to produce a software model that reflects the mental model of the business visionaries. (link)
Within each of the general areas across various industries listed earlier, and many others, there will be visions of yet-to-be-realized, company-defining enterprise applications (link)
One of the worst mistakes that a business can make is to try to shoehorn a packaged application into the position of strategic solution. (link)
In fact, reactive components are given no system-level assurance of the order in which any message may be received. (link)
Both the message-driven nature of reactive components and their location transparency lend to scaling applications on demand, that is, elasticity. (link)
In other words, reactive applications enjoy the benefit that their components have location transparency. (link)
. This can be supported by elasticity, which is scale on demand, which is reactive at the core. (link)
When using the Actor model, many of the patterns will be employed in greenfield applications, not just for integration. That is because the patterns are first and foremost messaging patterns, not just integration patterns, and the Actor model is messaging through and through. (link)