Syndicated Actors for Conversational Concurrency

What it gives you beyond the usual actor model is a way to decompose/compose your actor's behaviour to treat each conversation it is engaged in separately. A bit like having a supervision hierarchy internal to each actor.

This includes associating actor-internal state with particular interactions it's having with peers, as well as routing incoming events to conversational components within the actor.

It also allows incremental view maintenance: you can "subscribe" to "published" state from peers, again routing updates in that state to particular conversational components.

And of course it handles partial failure elegantly, by allowing actors to tear down conversational components when a peer crashes. It lets you precisely scope the lifetime of intra-actor state to a given (sub)conversation.

Finally, it's not a single-language thing. It's a polyglot thing. Because it's a very simple model, with a correspondingly simple protocol, it's easy to bring programs written in different languages into the same conceptual actor framework. The biggest Syndicate deployment I've had so far had participating programs written in Racket, JavaScript, Rust and Python all interoperating.

I started down this research line as a result of using Erlang when I was writing the RabbitMQ server. In a lot of ways, AMQP and Erlang were trying to do the same thing; each had great characteristics the other lacked. So now, Syndicated Actors and Dataspaces are a unifying perspective on what makes "messaging middleware" great as well as what makes the Actor model great.