The Syndicated Actor Model | Hacker News Reader

The Syndicated Actor Model

syndicate-lang.org

168 pointssph43 comments

Interesting! I don't think I quite understand how this compares to the vat model of actors that was used in E and what tuplespaces are contributing here. I guess I'd just need to sit down and try using the language.

See also Goblins, an actor model + object capability system inspired by a lot of the same stuff (like E) that uses the Preserves-derived Syrup format for encoding messages over the network. https://spritely.institute/goblins/

There's also a standard in development for communicating capabilities over the network called OCapN: https://ocapn.org/

I think there's some pre-existing crossover with the projects (e.g. Spritely/Ocapn's Syrup serialisation format is a version of Syndicate's Preserves) https://preserves.dev/ https://gitlab.com/spritely/syrup

> Ambients-like treatment of system boundaries

Probably more in the thesis, but at a glance this mention isn't further defined or referenced. The https://en.wikipedia.org/wiki/Ambient_calculus is quite beautiful and IMHO doesn't get the attention it deserves. Undergrad as far as I know never covers it, and most people I meet have never heard of it. AFAIK tuplespaces also are not usually taught, and people that have heard of it tend to dismiss it as "just some obsolete old java thing" because the most popular implementation probably does fit in that category. A shame since this is really cool stuff.

One problem that I see with all 3 technologies (ambients, tuplespaces, and syndicate) is that they sit somewhere at the intersection of datastructures / infrastructure / frameworks, but don't have clear and obvious deployment options. Compare this with say, akka on kubernetes. No matter how cool your tech is, this is an immediate non-starter for everything except academic investigation or low-level systems programming. Synit for user-space sounds neat, but if syndicate is generally a better model than Akka and additionally productionizing the other great ideas of past concurrency research, then it would be awesome to see the gap for other use-cases addressed.

Ambients seem indeed cool and this is where I first heard about them.

> One problem that I see with all 3 technologies (ambients, tuplespaces, and syndicate) is that they sit somewhere at the intersection of datastructures / infrastructure / frameworks, but don't have clear and obvious deployment options.

I disagree. I think it's simply still science fiction and the cutting edge of distributed research which isn't very popular in academia these days. Actors (1978) are just now barely becoming mainstream with the hype of Elixir and rediscovery of Erlang, even though the world still runs on multithreaded C and dead locks.

The tech is cool, but no one is being paid just yet to create practical languages and environments out of this. As in many other scientific endeavours, mainstream programming paradigms tend to lag 20 or 30 years compared to the research.

There's been an increasing interest in the Fediverse and local-first programming. Not quite mainstream, but they are well out of the academia.

I have never heard of these ideas about the Syndicated Actor, but they seem like they might hold answers for issues in the Fediverse and make implementing local-first software more practical,.

We have things with synchronizing state between web clients and servers and jump though all kinds of hoops with that (example, Relay), and I wonder if this would help with that. Lumen (Elixir on WASM) has stalled in development and LiveView is popular, but maybe with this, that is not what we want to do anyways.

We have things like event-driven architecture, microservices, and DDD, but maybe that results from using narrowly-scoped primitives that isn't suitable for everything. But we use it for adjacent use-cases because that is all we have for commercial languages.

I'd love to see how this can work out in Elixir.

In a lot of ways elixir still seems like it’s waiting for the killer app, and yeah, things along these lines feel like a natural fit.

Phoenix Live View is the killer app IMO.

I know that's what a lot of people say, but meh, I was hoping for something more exotic, and there's already lots of ways to web. An implementation of the ambient calculus on top of libcluster would be more killerer :) And re: tuple-spacing, elixir's built-in support for pattern-matching fits really well with that.

Such a thing might handle web as a special case, and could maybe evolve towards secure by design / provably-secure in ways that could be new/interesting. Or it might be a more expressive kind of FaaS, or be wildly popular with the "kubernetes is too complex/expensive!" crowd, especially if it can somehow integrate components written in other languages.

Just dreaming though, I only wish this kind of stuff was my day job. And even if I had really concrete ideas, something more solid than a proof of concept for such things probably needs a small army of devs. Phoenix does have the major benefit of actually existing, which is nice!

Dissertation didn't touch on the connection to Ambients too much, but there's clearly some kind of "there" there. Future work, still, I'm afraid.

This sounds like a modern Linda which is itself a coordination language between parallel actors reduced down to a very simplified model of pattern matching and "pub/sub".

This kind of parallel programming fell out of favor with PVM and MPI kind of taking over the space in the late 90s, but I suspect Tuplespaces were just a bit ahead of their time.

Things like this can potentially really help with the observability of distributed systems, which has been a huge pain especially in areas of eventual consistency.

Agree. I thought the concept of tuplespaces was super interesting and, unfortunately and definitely, ahead of its time. IBM had some decent papers on it.

I see eventual consistency here as a bit of copout. it really does limit the applicability of the approach by making really not obvious when things are starting to decohere. Someone else mentioned Alvaro in this thread, and I think thats a really fruitful body of work to look for answers that don't require a strong central serialization agent. Monotonicity, vector clocks, multi-panos style domain partitioning, these are partial answers for making this kind of thing be a foundation you can reason about and still scale.

https://worrydream.com/refs/Carriero_1989_-_Linda_in_Context...

I'm very interested in concurrency and new paradigms from a pragmatic perspective. Maybe it's because I'm practically minded, but I don't have the energy to parse this type of content (and that's ok, not blaming anyone).

That said, I really, really appreciate when I can see a tangible piece of code that solves a real problem. In the case of concurrency, perhaps a hello world from an actor, ping pong, a chat room, cancellation, timeout or similar. Show something that's easy to do in this model, which is tedious to do in different models. (This shouldn't be hard to find, since concurrency is ridiculously easy to get wrong in most languages).

If a partial goal is to engage practicians, then code samples is very effective. I usually don't need the full theory to grok code even in a foreign paradigm. If I can get an initial sense and I like it, then I am infinitely more willing to read up on the theory. Now, unfortunately, you're missing out on one very curious, albeit lazy, reader.

For the record, the closest I could find was some pseudo-code[1]. If there's more please share!

[1]: https://synit.org/book/syndicated-actor-model.html

EDIT: I'm stupid, there are a couple of examples on the linked page if you scroll down. I wish there were more!

> I'm very interested in concurrency and new paradigms from a pragmatic perspective.

Tell me about it. I also lack formal education, and a lot of advanced research into distributed communication models is basically expressed in alien languages to me, i.e. pi-calculus, rho-calculus, even Hewitt's research. It is both fun and a bit frustrating trying to figure out how they would work in practice from formal academic papers.

This one has a lot of actual Racket code though, you might want to read the history section for some practical examples.

I clicked around on Tony's site and found this listing of Syndicate related repositories: https://syndicate-lang.org/code/repos/

I'm sorry about the state of the docs. I am slowly working on improving the situation.

You might find the ~blog/journal part of the site interesting, wrt examples: https://syndicate-lang.org/journal/ -- still not exactly an embarrassment of riches, but it's something.

As an aside, I'm a big fan of this site's imitation of neoplasticism as a form of web design

I think my favorite Actor framework is Microsoft's Orleans, which uses a "Virtual Actor" model. It is mainly implemented in C#, and EA implemented their own version in Java then Kotlin called Orbit, but it feels very straight forward for what it does, it was also used extensively to scale the Halo online servers.

Decent articles on Orleans and Virtual Actor model.

https://learn.microsoft.com/en-us/dotnet/orleans/overview

https://darlean.io/the-virtual-actor-model/

Discussion on Orbit by EA:

https://news.ycombinator.com/item?id=31192795

This basically makes C# behave Erlang esque. You can have a single server running until load kicks off, and even if you destroy a node, spinning it up again is easy. Nodes maintain their own state and can be across systems as needed. You can also do zero-downtime updating like in Erlang. It's really neat. I assume Syndicated Actor Model solves a similar problem, but it looks like they make use of an MQ as needed.

What's funny about Orbit though is the Akka devs wrote some sort of "hit" piece about why their model is fine, and you don't need Virtual Actors.

Virtual actors are so nice, Dapr[1] uses them as well. You can get hack together something like a virtual actor with Ray too but I'm hoping their actors eventually evolve into something like virtual actors eventually.

[1] https://docs.dapr.io/developing-applications/building-blocks...

Whats funny to me is Dapr is also by Microsoft, but at least you can use it with other languages too.

I like the constraints these models impose for some applications, but I don't see them as fundamentally revolutionizing the application development space. You are still ultimately responsible for persisting every last byte of state that these virtual actors embody. Much of this looks like "How to Draw an Owl" [0] to me.

You could tie your own hands in approximately same way in a typical monolithic codebase by spinning out some Actor/Grain base types and enforcing a similar execution model around their implementations.

[0]: https://knowyourmeme.com/memes/how-to-draw-an-owl

Orleans is neat because it tackles orthogonal persistence and fault recovery at the same time. Lots of interesting future work remains to be done with persistence, though: wouldn't it be interesting if there were some "third way", somewhere in the middle of spectrum between (1) traditional orthogonal persistence, which serializes the entire nitty-gritty program state (stack, register file, heap, etc etc; totally implementation oriented), and (2) the Orleans or SQL-ORM approach, where the programmer manages records explicitly and, if they're lucky, gets a bit of support to give them a reactive feeling? I'm imagining some kind of domain-specific reflection on machine state, so, a bit like traditional persistence, but filtered through a domain-specific summarization function to yield a domain-relevant data structure describing the state of the actor.

Possibly similar (but I don't understand the Syndicated Actor Model well enough yet to be sure): Data Distribution Service (DDS)

https://www.dds-foundation.org/what-is-dds-3/

I am surprise to see no implementation in erlang, elixir, and gleam

Only so many hours in a lifetime. I'd like to do an Erlang implementation sometime though (especially considering that Erlang/RabbitMQ is one of the places where this research started from). Or find a student interested in doing one.

I'll attempt a tl;dr of this project:

Carl Hewitt's actor model (often seen in Erlang, Akka & co.) uses message-passing to communicate between concurrent actors, but doesn't easily allow for state synchronization or dynamic topologies of actors.

Tuple Spaces [https://en.m.wikipedia.org/wiki/Tuple_space] are another paradigm for distributed communication where message tuples are stored into distributed shared "space" and processes can pull messages that match a certain pattern. Very much like how biological cell communicate between each other, which allows for dynamic topologies, but you lose any concept of ordering (message X came before message Y)

The Syndicated Actor model is an attempt at bridging the two ideas to dynamically allow neighbouring actors to coordinate and communicate with each other using something like pub/sub.

---

The history page is very much worth reading: https://syndicate-lang.org/about/history/

Here's the author's doctoral thesis: https://syndicate-lang.org/papers/conversational-concurrency...

And SYNIT, a reactive layer for Linux which aims to replace most user-space subsystems with this model: https://synit.org/book/

I tried to understand Tuple Space a few times but I don't get it.

I understand Erlang and the actor model and how distributed processes work, but what is unique in the Tuple Space aspect? I vaguely recall getting it but it doesn't register for me now.

Maybe it's because Erlang already has pub/sub for every 'thing?'

In Erlang you have a PID and send messages directly to it. The topology is a directed graph.

Process in a tuple space just communicate through shared memory. Messages have no address. And processes can write or pattern match messages from this shared memory space.

    Process A:
    put({"foo", "bar", 123})
    put({"foo", "quux", 456})

    Process B, later:
    get({"foo", ?x, 123})
    # here x = "bar"

Imagine a cell communicating with others by squirting out molecules meant for no one in particular, and having external receptors to match specific other molecules.

This allows actors that have not been designed to work with each other to communicate, just by sharing the same tuple space.

So like an implicit global mnesia accessed by "tuples" / some identity?

This sounds like you effectively have a global schema (in the DB sense) that all actors have to be consistent with, causing everything to be coupled with everything.

They’re coupled only as far as agreeing on a message format constitutes coupling, which is something you have to do in any actor system anyway. Bigger issue is that tuplespaces tend to be centralized, so it is very much like an app listening to table events in a db, but without a predefined schema. It’s more like pub/sub except one subscribes by message structure, not channel identity.

You also have to prevent unrelated actors from choosing overlapping (conflicting) message formats. In other words, you can’t decide on a new message format without knowledge of all already existing message formats.

or you can just use namespaces

This would seem to counter “This allows actors that have not been designed to work with each other to communicate, just by sharing the same tuple space.” Alternatively, I don’t see the big difference to just using separate message queues with pattern-based retrieval. In the end, you always have to design who communicates with who in which format.

Absolutely. A message queue with pattern-based retrieval is a hacky way of getting the first two-thirds of a tuplespace. But, like using a database as a message queue, while it kinda sorta works for the most part, the benefits of the model come in when you start to treat it on its own terms rather than via an encoding. Tuplespaces have a little more to them (not a lot, but some) than just pattern-based retrieval, but some of the research work on them has been focused on appropriate fault-recovery strategies, strategies for sharding and distributing the spaces, etc etc.

The Syndicated Actor Model started off (see dissertation) without any notion of object or actor or entity reference at all. Actors inhabited a single dataspace and there was no baked-in addressing. Since then various developments have led to introduction of entity references (like object references in E). Taken together with dataspaces, this gives you several ways of introducing spacelike separation: you can use different message shapes+patterns, like in "classic" Syndicate or like in tuplespaces; you can use entity-references to have multiple dataspaces on the go at once, forcing isolation that way; or some combination of the two.

The author also directly relates this to Datalog and its descendants, so if you like Peter Alvaro's work this may be worth looking into more

> State management via dataspaces is directly comparable to a distributed datalog-based system, and enjoys many of the same benefits.

https://syndicate-lang.org/about/syndicate-in-context/

This sounds awfully similar to Scoped Propogators. https://news.ycombinator.com/item?id=40916193

Sorry, they are not at all the same thing, though I have been entertaining the idea of building a propagator with this model.

Yay! I'm currently working on this (slowly, among many other things). Come visit #syndicate on libera.chat, if you would like to chat about this stuff!

Certainly, as soon as I'm finished reading your dissertation. I've been researching this problem for a while now and it seems you have been a few steps ahead of me all along :)

Does that mean that, propogators can be implemented with the primitives fescribed in syndicated actors, but not the converse?

Reply on news.ycombinator.com