>>kioku+(OP)
A more legible version: https://dspace.mit.edu/handle/1721.1/6952

https://en.wikipedia.org/wiki/Gul_Agha_(computer_scientist)

>>kioku+(OP)
May be of interest: Pony Language is designed from the ground up to support the Actor model.

https://www.ponylang.io/

>>kioku+(OP)
Please change the title to the original, "Actors: A Model Of Concurrent Computation In Distributed Systems".

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.

>>lmm+dt
Fair, I worked a lot on data pipelines and found the actor model worked well in that context. I particularly enjoyed it in the Elixir ecosystem where I was building on top of Broadway[0]

Probably has to do with not fighting the semantics of the language.

[0] https://elixir-broadway.org/

>>Batter+0r
I was disappointed when MS discontinued Axum, which I found pleasant to use and thought the language based approach was nicer than a library based solution like Orleans.

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...

>>mjlaws+4A
Not books, but some inspiring resources. FModel [0] is a set of patterns for functional reactive DDD on the basis of event sourcing. In particular the Decider pattern is a great way to model aggregates, and test them using Scenario's that read like Gherkin in code (given.. when.. then). Combines well with actors to represent aggregates.

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/

>>kibwen+4d
Nurseries sound similar to run-till-completion schedulers [0].

> 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

>>kibwen+g61
The point I was trying to make is that you can apply the actor model to any system of isolated processes. Whether the isolated processes live on a distributed system of networked computers or on the same computer is an implementation detail. The critical issue is that each actor should own and mutate its own state. Whether all actors run on the same thread or on separate threads is also an implementation detail. For instance, AtomVM is a lightweight implementation of the Beam (actor model) that runs on microcontrollers [0].

> 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.

0. https://atomvm.org/

>>cmrdpo+An1
Note that Rust supports a form of structured programming (though only via thread-based concurrency, not via async), provided by the `std::thread::scope` API: https://doc.rust-lang.org/std/thread/fn.scope.html . The blog post above calls out an older version of this API as inspiration.

>>michae+7b
D language is also supporting actor model in the standard library for its concurrent, parallel and distributed programming [1].

[1] D (programming language):

https://en.wikipedia.org/wiki/D_(programming_language)

>>eaurou+Wh1
Structured concurrency is also a Kotlin thing https://kotlinlang.org/docs/coroutines-basics.html#coroutine... and a Python thing https://vorpus.org/blog/notes-on-structured-concurrency-or-g... and before that it was a C thing https://sustrik.github.io/250bpm/blog:71/

>>throwa+OP3
It is still developed, although it feels a bit like it was mostly "done" 10 years ago.

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.