Actors: A Model of Concurrent Computation [pdf] (1985)(apps.dtic.mil) |
Actors: A Model of Concurrent Computation [pdf] (1985)(apps.dtic.mil) |
I'm not normally a stickler for HN's rule about title preservation, but in this case the "in distributed systems" part is crucial, because IMO the urge to use both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle and a huge dead end. Which is to say, if you're within a single process, what you want is structured concurrency ( https://vorpus.org/blog/notes-on-structured-concurrency-or-g... ), not the unstructured concurrency that is inherent to a distributed system.
Using actors also simplified greatly other parts of the app.
For something to be an actor, it should be able to:
- Send and receive messages
- Create other actors
- Change how the next message is handled (becomes in Erlang)
I think the last one is what makes it different it from simple message passing, and what makes it genius: state machines consuming queues.
It was a theme in part of my career to pick up something written in Scala that used actors that (1) didn't always get the same answer and (2) didn't use all the CPU cores and struggling for days to get it working right with actors then taking 20 minutes to rewrite it using Executors and getting it to work the first time and always work thereafter.
> IMO the urge to use both the actor model (and its relative, CSP) in non-distributed systems solely in order to achieve concurrency has been a massive boondoggle
Can't you model any concurrent non-distributed system as a concurrent distributed system?
0. https://en.wikipedia.org/wiki/Run-to-completion_scheduling
Yes, in the same way that you can give up `for` loops and `while` loops and `if` statements and `switch` statements and instead write them all with `goto`, but you don't do this, and anyone advising you to do this would be written off as insane. The entire thrust of this thread is that you can have a more reliable system that is easier to reason about if you use specific constructs that each have less power, and non-distributed systems have the option to do this. Unstructured concurrency should be reserved exclusively for contexts where structured concurrency is impossible, which is what the actor model is for.
I've been on more than one team that has broken their (in-process, single machine) process up into multiple "actors" (or "components" or "services") through communicating threads (usually over Rust channels) and then had a situation where they replicate some piece of state through messaging because they're been told that their system must not have global (mutable or immutable) state.
But now they've just created a whole pile of inefficient boiler plate (propagating copies of effectively the same piece of global state through different services) and created a new way of having race conditions and/or just plain old stale or inconsistent data. For what are essentially ideological reasons.
Every new feature in this model ends up being mostly plumbing of state replication between what are supposed to be isolated component models.
The answer to me is just to establish a discipline where a given piece of data is owned for writes by one task or component, but can be freely read by any.
If you truly have a stateless system or extremely clear data ownership boundaries, I can see the value of a CSP/actor approach. And in the context of Rust's borrow checker this model is fairly convenient. But it quickly becomes prone to cargo-culting and becomes a recipe for hairy, hard to maintain code.
I am convinced most teams blanket applying actors would be far better suited to more tuplespaces/blackboard/Linda type model for concurrent coordination. A way of working that never caught on, but has always been attractive to me.
I’m currently engineering a system that uses an actor framework to describe graphs of concurrent processing. We’re going to a lot of trouble to set up a system that can inflate a description into a running pipeline, along with nesting subgraphs inside a given node.
It’s all in-process though, so my ears are perking up at your comment. Would you relax your statement for cases where flexibility is important? E.g. we don’t want to write one particular arrangement of concurrent operations, but rather want to create a meta system that lets us string together arbitrary ones. Would you agree that the actor abstraction becomes useful again for such cases?
FWIW, this has become a perfectly cromulent pattern over the decades.
It allows highly concurrent computation limited only by the size and shape of the graph while allowing all the payloads to be implemented in simple single-threaded code.
The flow graph pattern can also be extended to become a distributed system by having certain nodes have side-effects to transfer data to other systems running in other contexts. This extension does not need any particularly advanced design changes and most importantly, they are limited to just the "entrance" and "exit" nodes that communicate between contexts.
I am curious to learn more about your system. In particular, what language or mechanism you use for the description of the graph.
Actors are still just too general and uncontrolled, unless you absolutely can't express the thing you want to any other way. Based on your description, have you looked at iterate-style abstractions and/or something like Haskell's Conduit? In my experience those are powerful enough to express anything you want to (including, critically, being able to write a "middle piece of a pipeline" as a reusable value), but still controlled and safe in a way that actor-based systems aren't.
Why is that so?
I've written a non-distributed app that uses the Actor model and it's been very successful. It concurrently collects data from hundreds of REST endpoints, a typical run may make 500,000 REST requests, with 250 actors making simultaneous requests - I've tested with 1,000 but that tends to pound the REST servers into the ground. Any failed requests are re-queued. The requests aren't independent, request type C may depend on request types A & B being completed first as it requires data from them, so there's a declarative dependency graph mechanism that does the scheduling.
I started off using Akka but then the license changed and Pekko wasn't a thing yet, so I wrote my own single-process minimalist Actor framework - I only needed message queues, actor pools & supervision to handle scheduling and request failures, so that's all I wrote. It can easily handle 1m messages a second.
I have no idea why that's a "huge dead end", Actors are a model that's a very close fit to my use case, why on earth wouldn't I use it? That "nurseries" link is way TL;DR but it appears to be rubbishing other options in order to promote its particular model. The level of concurrency it provides seems to be very limited and some of it is just plain wrong - "in most concurrency systems, unhandled errors in background tasks are simply discarded". Err, no.
Big Rule 0: No Dogmas: Use The Right Tool For The Job.
Please read and understand that blog post, I promise it's worth your time.
[1] D (programming language):
https://github.com/ponylang/ponyc
Quite a few recent commits and their blog/X account mentioned their LSP now being bundled with the language...
https://www.ponylang.io/blog/2026/02/last-week-in-pony---feb...
Dunno, now it feels like the "hot" thing is either manual memory languages like Zig, Odin an Rust or languages with novel type systems like Lean, Koka, Idris, etc... GC'd "systems" languages like Nim, Crystal, Pony, Go, etc... all seem kind of old fashioned now.
- Erlang and Elexir
- E
- AmbientTalkTo be fair, the problem was probably that particular implementation, but I'm wondering if there's any successful rollout of that model at any significant scale out there.
Juicy paper, not to mention the declassification. It really reminds me of asyncmachine.dev which has actors, relations, transitions, and embraces non-determinism.
To this day - we have only taken advantage of parallel architectures in GPUs - a lot of software still runs on single CPU threads. most programming languages- are made optimized for single threads - yeah we might have threads, virtual threads, fibers etc - but how many people are using those on a daily basis?
I was under the impression that parallel and concurrent code was the dominant paradigm for programming tasks currently going in most of the semi-mainstream domains. I am certainly willing to concede that I could just be in a bubble that thinks about and designs for concurrency and parallelism as a first class concern, but it doesn’t seem that way.
I mean one of the large features/touted benefits for Rust is the single mutable XOR multiple immutable semantics explicitly to assist with problems in parallel/concurrent code, all of the OTP languages are built on top of a ridiculously parallel and distributed first ‘VM’. It strikes me as peculiar that these types of languages and ecosystems would be so, apparently, popular if the primary use case of ‘safe’/resilient parallel/concurrent code was not a large concern.
One of the single most important things I've done in my career was going down the Actor Model -framework rabbit hole about 8 or 9 years ago, read a bunch of books on the topic, that contained a ton of hidden philosophy, amazing reasoning, conversations about real-time vs eventual consistency, Two-Generals-Problem - just a ton of enriching stuff, ways to think about data flows, the direction of the flow, immutability, event-logged systems and on and on. At the time CQS/CQRS was making heavy waves and everyone tried to implement DDD & Event-based (and/or service busses - tons of nasty queues...) and Actor Model (and F# for that matter) was such clean fresh breath of air from all the Enterprise complexity.
Would highly recommend going this path for anyone with time on their hands, its time well spent. I still call on that knowledge frequently even when doing OOP.
The Axum language had `domain` types, which could contain one or more `agent` and some state. Agents could have multiple functions and could share domain state, but not access state in other domains directly. The programming model was passing messages between agents over a typed `channel` using directional infix operators, which could also be used to build process pipelines. The channels could contain `schema` types and a state-machine like protocol spec for message ordering.
It didn't have "classes", but Axum files could live in the same projects as regular C# files and call into them. The C# compiler that came with it was modified to introduce an `isolated` keyword for classes, which prevented them from accessing `static` fields, which was key to ensuring state didn't escape the domain.
The software and most of the information was scrubbed from MS own website, but you can find an archived copy of the manual[1]. I still have a copy of the software installer somewhere but I doubt it would work on any recent Windows.
Sadly this project was axed before MS had embraced open source. It would've been nice if they had released the source when the decided to discontinue working on it.
[1]:https://web.archive.org/web/20110629202213/http://download.m...
It never felt like Nim, Pony, or Crystal were ever that popular that a diminished hype cycle registered as something thematic to me (not that I really intend to disagree with your perspective here).
On the BEAM used by Erlang, Elixir, and Gleam actors are called processes, and this guide [1] delves into domain modeling with them.
[0] https://fraktalio.com/fmodel/
[1] https://happihacking.com/blog/posts/2025/the-gnome-village/
These days I would recommend picking a framework and then ask claude & friends to do a deep dive with you and build an example project out. Ask it to explain concepts, architecture, trade-offs, scalability considerations, hosting considerations, compare it with other frameworks, hook it up to storage systems (sqlite, postgresql, blob storage) and so on. Try running them within a wireguard network and so on. Very interesting learning to be found.
Related to what you were saying, the protobuf schema has special dedicated entries for the entrance and exit nodes, so only the top level pipeline has them. Thus the recursive aspect (where nodes can themselves contain sub-graphs) applies only to the processor-y bit in the middle. That allowed us to encourage the side effects to stay at the periphery, although I think it’s still possible in principle. But at least the design gently guides you towards doing it that way.
After having created our system, I discovered the Reactor framework (e.g. Lingua Franca). If I could do it all over, I think I would have built using that formalism, because it is better suited for making composable dataflows. The issue with the actor model for this use case is that actors generally know about each other and refer to each other by name. Composable dataflows want the opposite assumption: you just want to push data into some named output ports, relying on the orchestration layer above you to decide who is hooked up to that port.
To solve the above problem, we elected to write a rather involved subsystem within the inflation layer that stitches the business actors together via “topic” actors. CAF also provides a purpose-built flows system that sits over top of the actors, which allows us to write the internals of a business actors in a functional reactive-x style. When all is said and done, our business actors don’t really look much like actors - they’re more like MIMO dataflow operators.
When you zoom out, it also becomes obvious that we are in many ways re-creating gstreamer. But if you’ve ever used gstreamer before, you may understand why “let’s rest our whole business on writing gstreamer elements” is too painful a notion to be entertained.
Since you still have C++ involved and if you are still looking for composable dataflow ideas, take a look at TBB's "flow_graph" module. It's graph execution is all in-process while what you describe sounds more distributed, but perhaps it is still interesting.
> The entire thrust of this thread is that you can have a more reliable system that is easier to reason about if you use specific constructs that each have less power
Easier to reason about, sure, fine. Your earlier comment claims the actor model is a dead end in non-distributed systems.
> Unstructured concurrency should be reserved exclusively for contexts where structured concurrency is impossible, which is what the actor model is for.
Results from my quick search on structured/unstructured concurrency were all references to Swift. Is this a Swift thing? In any case, the issue appears to be more about managing tasks that don't require a preemptive scheduler. As I see it, that issue appears orthogonal to distributed/non-distributed systems.
If you have two ways of structuring something, and the worse way is so predominant that it obscures even the existence of the better way, that's a dead end in my book. In the pre-structured-programming days when people had to fight tooth and nail to get people to acknowledge the value of `if` and `while` over `goto`, we would have also called `goto` a dead end; it's plain to see that we would be in a worse place today if the structured programming advocates had not managed to convince everyone of its superiority.
> Results from my quick search on structured/unstructured concurrency were all references to Swift. Is this a Swift thing?
I have no idea whether Swift supports it, but no, it's not a Swift thing any more than `while` and `if` are a Python thing. I highly, highly encourage people to read the linked blog post, it will be the best use of your time today.
At which point they're very much not actors any more. You've lost the deadlock avoidance, you can't do the `become`-based stuff that looks so great in small demos. At that point what are you gaining from using actors at all?
Things like data pipelines, and games etc etc.
Probably has to do with not fighting the semantics of the language.
you have to try really hard to do the inverse. Java's ergonomics, even with Akka, lends its self to certain design patterns that don't lend itself to writing code for distributed systems.
Extending it however reveals some benefits, locking is often for stopping whilst waiting for something enqueued can be parallell with waiting for something else that is enqueued.
I think it very much comes down to history and philosophy, actors are philosophically cleaner (and have gained popularity with success stories) but back in the 90s when computers were physically mostly single-threaded and memory scarce, the mutex looked like a "cheap good choice" for "all" multithreading issues since it could be a simple lock word whilst actors would need mailbox buffering (allocations... brr),etc that felt "bloated" (in the end, it turned out that separate heavyweight OS supported threads was often the bottleneck once thread and core counts got larger).
Mutexes are quite often still the base primitive at the bottom of lower level implementations if compare-and-swap isn't enough, whilst actors generally are a higher level abstraction (better suited to "general" programming).
In practice you want to keep the sharp knives away from junior programmers in larger contexts, handling a few ones in a limited scope is ok but when you start to reason about larger systems, actors in concurrent contexts can be explained even to junior programmers in terms of conveyor belts of messages or a similar analogy.
I don't know if you heard the story of how C++ was used and a large part of the collapse of that project was due to C++, OO and/or threading issues and how Erlang was then used in a crash project to successfully write a replacement on the same HW.
Some people claim that functional programming and/or actor systems are inherently superior, I don't really agree on that assessment, it's more that the actor patterns were easily handled in a distributed system and when used by less seasoned programmers it was possible for them to create their parts in mostly "single-threaded" contexts + message passing without causing trouble by using lower level concurrency primitives.
Really, imagine 500+ mid-junior programmers banging away concurrent code on a larger project that needs to be shipped soon.
This is what I mean by philosophically cleaner.
Horses for courses, as they say.