[HN Gopher] The Syndicated Actor Model
___________________________________________________________________
The Syndicated Actor Model
Author : sph
Score : 135 points
Date : 2024-08-14 10:12 UTC (12 hours ago)
(HTM) web link (syndicate-lang.org)
(TXT) w3m dump (syndicate-lang.org)
| sph wrote:
| 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/
| pyinstallwoes wrote:
| 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?'
| sph wrote:
| 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.
| pyinstallwoes wrote:
| So like an implicit global mnesia accessed by "tuples" /
| some identity?
| layer8 wrote:
| 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.
| chuckadams wrote:
| 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.
| layer8 wrote:
| 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.
| convolvatron wrote:
| or you can just use namespaces
| layer8 wrote:
| 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.
| svieira wrote:
| 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/
| klabb3 wrote:
| 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!
| sph wrote:
| > 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.
| metadaemon wrote:
| I clicked around on Tony's site and found this listing of
| Syndicate related repositories: https://syndicate-
| lang.org/code/repos/
| photonthug wrote:
| > 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.
| sph wrote:
| 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.
| hosh wrote:
| 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.
| giancarlostoro wrote:
| 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.
| binalpatel wrote:
| 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...
| giancarlostoro wrote:
| Whats funny to me is Dapr is also by Microsoft, but at least
| you can use it with other languages too.
| bob1029 wrote:
| 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
| shortrounddev2 wrote:
| As an aside, I'm a big fan of this site's imitation of
| neoplasticism as a form of web design
| butterisgood wrote:
| 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.
| kayo_20211030 wrote:
| 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.
| convolvatron wrote:
| 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.
| jjtheblunt wrote:
| https://worrydream.com/refs/Carriero_1989_-_Linda_in_Context...
| davexunit wrote:
| 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/
| dannyobrien wrote:
| 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
| discreteevent wrote:
| 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/
| rjpruitt16 wrote:
| I am surprise to see no implementation in erlang, elixir, and
| gleam
___________________________________________________________________
(page generated 2024-08-14 23:00 UTC)