-
Cross-platform actors for .NET, Go, Java and Kotlin -
Actors for concurrency and distribution -
Grains for friction-free scalability -
Elastic and decentralized clusters
Simple Concurrency & Distribution
Asynchronous and Distributed by design. High-level abstractions like Actors and Virtual Grains.
Extreme Performance
Capable of more than two million messages per second between processes
Resilient by Design
Write systems that self-heal using supervisor hierarchies.
Built on standards
ProtoAct is built ontop of Googles gRPC and Protobuf, taking advantage of proven stability and performance.
Actor Model
The Actor Model provides a higher level of abstraction for writing concurrent and distributed systems. It alleviates the developer from having to deal with explicit locking and thread management, making it easier to write correct concurrent and parallel systems.
Actors were defined in the 1973 paper by Carl Hewitt but have been popularized by the Erlang language, and used for example at Ericsson with great success to build highly concurrent and reliable telecom systems.
Distributed by Default
Everything in ProtoAct is designed to work in a distributed setting: all interactions of actors use purely message passing and everything is asynchronous.
This effort has been undertaken to ensure that all functions are available equally when running within a single process or on a cluster of hundreds of machines. The key for enabling this is to go from remote to local by way of optimization instead of trying to go from local to remote by way of generalization. See this classic paper for a detailed discussion on why the second approach is bound to fail.
Virtual Actors
Virtual Actor abstraction, which provides a straightforward approach to building distributed interactive applications, without the need to learn complex programming patterns for handling concurrency, fault tolerance, and resource management.
Supervision & monitoring
Actors form a tree with actors being parents to the actors they've created.
As a parent, the actor is responsible for handling its children’s failures (so-called supervision), forming a chain of responsibility, all the way to the top. When an actor crashes, its parent can either restart or stop it, or escalate the failure up the hierarchy of actors. This enables a clean set of semantics for managing failures in a concurrent, distributed system and allows for writing highly fault-tolerant systems that self-heal.
