Actors: A Model of Concurrent Computation [pdf] (1985) • Hacker News Board

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#71

Post by throwaway17_17 » Tue, Feb 03, 2026, 3:04 AM UTC

dzonga wrote: post #51

> It is generally believed that the next generation of computers will involve massively parallel architectures. 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 basi…

I will be glad to be wrong about, but…

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.

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#72

Post by throwaway17_17 » Tue, Feb 03, 2026, 3:08 AM UTC

michaelsbradley wrote: post #4

May be of interest: Pony Language is designed from the ground up to support the Actor model. https://www.ponylang.io/

Is Pony still an actively developed language? I remember watching several talks while they brought the language up to release, and read several of the accompanying papers. However, I thought with the primary corporate sponsor dropping the language it had gone basically EOL. Which was a pretty large bummer as I was very interested to see how the reference capability model of permissions and control worked at large scale for concurrency control and management (as well as its potential application to other domains).

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#73

Post by dismalaf » Tue, Feb 03, 2026, 4:54 AM UTC

throwaway17_17 wrote: post #72

michaelsbradley wrote: post #4

May be of interest: Pony Language is designed from the ground up to support the Actor model. https://www.ponylang.io/

Is Pony still an actively developed language? I remember watching several talks while they brought the language up to release, and read several of the accompanying papers. However, I thought with the primary corporate sponsor dropping the language it had gone basically EOL. Which was a pretty large bummer as I was very interested to see how the reference capability model of permissions and control worked at large sca…

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.

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#74

Post by galaxyLogic » Tue, Feb 03, 2026, 8:50 AM UTC

lmm wrote: post #14

galaxyLogic wrote: post #9

Earlier quoted context omitted.

> 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. Why is that so?

Well, lots of people have tried it and spent a lot of money on it and don't seem to have derived any benefit from doing so.

Isn't this a bit theoretical since most real world systems are distributed these days, using a browser as GUI?

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#75

Post by frumiousirc » Tue, Feb 03, 2026, 10:59 AM UTC

sebastos wrote: post #53

frumiousirc wrote: post #37

Earlier quoted context omitted.

Data flow graphs could arguably be called structured concurrency (granted, of nodes that resemble actors). 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 syste…

We’re using the C++ Actor Framework (CAF) to provide the actor system implementation, and then we ended up using a stupid old protobuf to describe the compute graph. Protobuf doubles as a messaging format and a schema with reflection, so it lets us receive pipeline jobs over gRPC and then inflate them with less boilerplate (by C++ standards, anyway). Related to what you were saying, the protobuf schema has special de…

Sounds good. Thanks for describing it.

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.

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#76

Post by blandflakes » Tue, Feb 03, 2026, 6:49 PM UTC

dismalaf wrote: post #73

throwaway17_17 wrote: post #72

Earlier quoted context omitted.

Is Pony still an actively developed language? I remember watching several talks while they brought the language up to release, and read several of the accompanying papers. However, I thought with the primary corporate sponsor dropping the language it had gone basically EOL. Which was a pretty large bummer as I was very interested to see how the reference capability model of permissions and control worked at large sca…

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 ty…

Go seems to have some enduring affection and popularity for new projects and companies. I recently felt like a lot of the recent shift was less about GC and more about runtime characteristics (static binaries, lean resource consumption, lack of an in-your-face virtual machine).

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

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#77

Post by koakuma-chan » Wed, Feb 04, 2026, 12:53 AM UTC

crustycoder wrote: post #33

koakuma-chan wrote: post #22

Earlier quoted context omitted.

So you're just using actors to limit concurrency? Why not use a mutex?

You are using mutexes, they are on the Actor message queues, amongst other places. "Just use mutexes" suggests a lack of experience of using them, they are very difficult to get both correct and scalable. By keeping them inside the Actor system, a lot of complexity is removed from the layers above. Actors are not always the right choice, but when they are they are a very useful and simplifying abstraction. Horses for…

Can you share some insights why mutexes are difficult to get correct and scalable?

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#78

Post by pancsta » Wed, Feb 04, 2026, 7:34 AM UTC

> It captures the nondeterminism in the order of delivery of communications. The Subsequent transition captures fairness arising from the guarantee of delivery. We provide a denotational semantics for our minimal actor language in terms of the transition relations.

Juicy paper, not to mention the declassification. It really reminds me of asyncmachine.dev which has actors, relations, transitions, and embraces non-determinism.

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#79

Post by whizzter » Thu, Feb 05, 2026, 3:19 PM UTC

zozbot234 wrote: post #44

whizzter wrote: post #40

Earlier quoted context omitted.

In this simple case they're more or less equivalent if the only task is limiting concurrency, but in general usage of mutexes multiplies and soon enough someone else has created a deadlock situation. 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 histor…

Atomic operations, memory barriers, condition variables, thread/"virtual processor" scheduling are philosophically cleaner since they're what the specified hardware/OS concurrency model actually provides, and can implement all of locks, mutexes, structured concurrency, arbitrary queues, actors etc. etc.

I was implicitly including all those with mutexes in the last sentence, it might be easier to reason about each in isolation because you're an experienced programmer that can/want to reason about the details.

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.

Re: Actors: A Model of Concurrent Computation [pdf] (1985)

#80

Post by brabel » Thu, Feb 05, 2026, 8:31 PM UTC

lmm wrote: post #70

brabel wrote: post #42

Earlier quoted context omitted.

Actors can be made to do structured concurrency as long as you allow actors to wait for responses from other actors, and implement hierarchy so if an actor dies , its children do as well. And that’s how I use them! So I have to say the OP is just ignorant of how actors are used in practice.

> Actors can be made to do structured concurrency as long as you allow actors to wait for responses from other actors 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?

If you don't think actors are useful just because you need to wait for responses, I guess you've never used actors. That's just so implausible someone would say that if they just, you know, did it.