Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

apps.dtic.mil

Post reply on HN
Print view View original

21–30 of 80 posts

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

#21

Post by raphinou »

kibwen wrote: post #5

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…

I'm working on an rest API server backed by a git repo. Having an actor responsible for all git operations saved me from a lot of trouble as having all git operations serialised freed me from having to prevent concurrent git operations.

Using actors also simplified greatly other parts of the app.

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

#22

Post by koakuma-chan »

raphinou wrote: post #21
kibwen wrote: post #5

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…

I'm working on an rest API server backed by a git repo. Having an actor responsible for all git operations saved me from a lot of trouble as having all git operations serialised freed me from having to prevent concurrent git operations. Using actors also simplified greatly other parts of the app.

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

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

#23

Post by sparkie »

BatteryMountain wrote: post #12
rubenvanwyk wrote: post #7

I think Microsoft Orleans, Erlang OTP and Scala Play are probably most famous examples in use today.

Orleans is pretty cool! The project has matured nicely over the years (been something like 10 years?) and they have some research papers attached to it if you like reading up on the details. The nuget stats indicate a healthy amount of downloads too, more than one might expect. 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,…

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

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

#24

Post by jen20 »

viccis wrote: post #16
keithnz wrote: post #8

Earlier quoted context omitted.

I would think Akka in Java world is more famous than orleans

Akka's not open source anymore so people tend to look at similar or competing systems like Scala Play.

Apache Pekko is an open-source fork of Akka from before their licensing changes.

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

#25

Post by melting_snow »

charles_f wrote: post #19

Actor model is one of these things that really seduces me on paper, but my only exposure to it was in my consulting career, and that was to help migrate away from it. The use case seemed particularly adapted (integration of a bunch of remote devices with spotty connection), but it was practically a nightmare to debug... which was a problem since it was buggy. To be fair, the problem was probably that particular imple…

I was in a team that built a bigger telco project for machine to machine communication, using akka actors. It was okayish, the only thing that I hated was how the whole pattern spread through the whole code base

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

#26

Post by raphinou »

koakuma-chan wrote: post #22
raphinou wrote: post #21

Earlier quoted context omitted.

I'm working on an rest API server backed by a git repo. Having an actor responsible for all git operations saved me from a lot of trouble as having all git operations serialised freed me from having to prevent concurrent git operations. Using actors also simplified greatly other parts of the app.

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

This might be a question of personal preference. At the design stage I already find it more approachable to think in separated responsibilities, and it naturally translates to actors. Thinking about the app, it's much reasier for me to thin "send the message to the actor" than call that function that uses the necessary mutex. With mutexes, I think the separation of concerns is not as strong, and you might end up with a function taking multiples mutexes that might interfere. With the actor model, I feel there is less risk (though I'm sure this would be questioned by seasoned mutex users).

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

#27

Post by mjlawson »

BatteryMountain wrote: post #12
rubenvanwyk wrote: post #7

I think Microsoft Orleans, Erlang OTP and Scala Play are probably most famous examples in use today.

Orleans is pretty cool! The project has matured nicely over the years (been something like 10 years?) and they have some research papers attached to it if you like reading up on the details. The nuget stats indicate a healthy amount of downloads too, more than one might expect. 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,…

Do any of the books you read on the topic stand out as something you'd recommend?

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

#28

Post by rapnie »

mjlawson wrote: post #27
BatteryMountain wrote: post #12

Earlier quoted context omitted.

Orleans is pretty cool! The project has matured nicely over the years (been something like 10 years?) and they have some research papers attached to it if you like reading up on the details. The nuget stats indicate a healthy amount of downloads too, more than one might expect. 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,…

Do any of the books you read on the topic stand out as something you'd recommend?

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/

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

#29

Post by weatherlight »

lmm wrote: post #18
ianbutler wrote: post #17

Earlier quoted context omitted.

Except Akka in Java and for the entirety of Erlang and its children Elixir and Gleam. You obviously can scale those to multiple systems, but they provide a lot of benefit in local single process scenarios too imo. Things like data pipelines, and games etc etc.

I've worked on a number of systems that used Akka in a non-distributed way and it was always an overengineered approach that made the system more complex for no benefit.

Really depends of the ergonomics of the language. In erlang/elixir/beam langs etc, its incredibly ergonomic to write code that runs on distributed systems.

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.

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

#30

Post by rurban »

koakuma-chan wrote: post #22
raphinou wrote: post #21

Earlier quoted context omitted.

I'm working on an rest API server backed by a git repo. Having an actor responsible for all git operations saved me from a lot of trouble as having all git operations serialised freed me from having to prevent concurrent git operations. Using actors also simplified greatly other parts of the app.

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

Because actors were invented to overcome deadlocks caused by mutexes. See page 137. With mutexes you can forget concurrency safety.
Post reply on HN