3 ms·

I suspect that a lot of what can be done with actors can be done in Go using the "Don't communicate by sharing memory, share memory by communicating". Basically

I suspect that a lot of what can be done with actors can be done in Go using the "Don't communicate by sharing memory, share memory by communicating". Basically a consumer of a channel can act like an actor. What we don't get for free is the activation and resiliency. A closer one would be Erlang/Elixir on the BEAM. On the more advanced end would be using F# or Pony. Curious to see what the follow-up parts will post. I am interested in actor model programming and want to see different ways of understanding and using them.

suraci 2y ago
> a lot of what can be done with actors can be done in Go using the "Don't communicate by sharing memory, share memory by communicating" Yes, it is logically correct since CSP and Actors are solutions for the same problem(concurrency) And I do think CSP is easier to use compare with Actors as a programming model, but when it comes to distributed and business applications, the comparative advantage is reversed
asplake 2y ago
Why F# there?
- karmakaze 2y ago
  I was thinking of Mailbox Processor and available Actor libraries. Here's a pretty good rundown I found for some[0]: > Actor Model in .NET > In the .NET world, there are at least a few battle-tested frameworks that allow you to build stateful systems using the actor model. The famous ones are Akka.NET[1], Orleans[2], Proto.Actor[3], and Dapr[4]. All of these systems support distributed mode, as well as a bunch of other features like actor supervision, virtual actor, parent-child hierarchies, reentrancy, distributed transactions, dead letter queue, routers, streams, etc. In addition to these frameworks, .NET has several lightweight libs that do not have many of the listed features but still allow the use of the actor model. For example, F# has built-in support via Mailbox Processor[5] and also there the toolkits: TPL Dataflow[6] and Channel[7]. TPL Dataflow and Channel are not actor model implementations but rather foundations for writing concurrent programs with the ability to use the actor model design pattern. [0] https://medium.com/draftkings-engineering/entering-actor-model-nirvana-with-f-and-tpl-dataflow-b8ab34b84656 https://medium.com/draftkings-engineering/entering-actor-mod... [1] https://getakka.net/ https://getakka.net/ [2] https://dotnet.github.io/orleans/index.html https://dotnet.github.io/orleans/index.html [3] https://proto.actor/ https://proto.actor/ [4] https://docs.microsoft.com/en-us/dotnet/architecture/dapr-for-net-developers/actors https://docs.microsoft.com/en-us/dotnet/architecture/dapr-fo... [5] https://www.codemag.com/Article/1707051/Writing-Concurrent-Programs-Using-F https://www.codemag.com/Article/1707051/Writing-Concurrent-P... [6] https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/dataflow-task-parallel-library https://docs.microsoft.com/en-us/dotnet/standard/parallel-pr... [7] https://devblogs.microsoft.com/dotnet/an-introduction-to-system-threading-channels/ https://devblogs.microsoft.com/dotnet/an-introduction-to-sys...
  - CharlieDigital 2y ago
    Clarification: Dapr's actor system is not limited to .NET[0] It currently supports .NET, Java, and Python [0] https://docs.dapr.io/developing-applications/building-blocks/actors/actors-features-concepts/#actor-communication https://docs.dapr.io/developing-applications/building-blocks...
  - debugnik 2y ago
    These days, for F# I'd use a task builder loop with System.Threading.Channels and TaskCompletionSource, rather than the MailboxProcessor. Same thing, really; you could recreate the MailboxProcessor API with those in just a few lines.
jerf 2y ago
I view actors like I view "object orientation" in general. In fact they're not even all that dissimilar, being respectively "store and manipulate state attached to a single runtime context" (be it "thread" or "green thread" or async context or whatever) and "store and manipulate state attached to a single highly-structured value". (They go together pretty well, actually.) The primary value comes from the idea, and it can and should be managed and manipulated for the local context. Many people will come along and insist that you need every last thing according to some particular definition (e.g., in OO, "you need multiple inheritance and all of public, private, and protected, and you need virtual methods and you need and you need and you need OR YOU DON'T HAVE TRUE OBJECT ORIENTATION AND EVERYTHING WILL FALL APART"), and will insist that everything at every layer of your program will need to be structured in this paradigm OR YOU DON'T HAVE TRUE WHATEVER AND EVERYTHING WILL FALL APART, but both claims are observably false. I use actors in nearly every program I write, in almost any language I write in anymore if there's any concurrency at all. But they are a wonderful tool to drop in somewhere, and encapsulate some particularly tricky bit of concurrent logic, like an in-memory concurrent cache, without having to restructure everything to be All Actors All The Time. I spent a lot of years in Erlang and still sort of consider this a mistake, up there with Java trying to "force" everything into OO by forcing everything to be in a class, even if it has no business being there. You don't need to go down someone's check list and dot every i and cross every t "or you don't have true actors". It's very much an 90/10 situation where the vast bulk of the benefit is obtained as soon as you have anything even actor-ish, and the additional marginal benefit of going all the way down to some very precise definition can be marginal and may even be negative if it requires you to contort your code in some unnatural way just to fit into some framework that isn't benefiting you on this particular task (e.g., Erlang has a lot of nice tools but if you're building a purely-local command-line app with it for whatever reason you probably don't have a great need for clustering support or OTP in general).
- jeremycarter 2y ago
  My sentiments exactly - well said. The big mistake is forcing OOP onto everything. It's why I really have an affinity with the virtual actor, it has just enough OOP for me to have classes, methods and internal state - I don't need inheritance, polymorphism, etc - just naive little classifications of things we call objects. I also don't have to think of my system in a hierarchical supervised manner like earlier actor models. I just need cloud native distributed little objects. You can see some modern products coming out that are just that: 1. Cloudflare Durable Objects - https://developers.cloudflare.com/durable-objects/ https://developers.cloudflare.com/durable-objects/ 2. Restate Virtual Objects - https://restate.dev/ https://restate.dev/

suraci 2y ago

> a lot of what can be done with actors can be done in Go using the "Don't communicate by sharing memory, share memory by communicating" Yes, it is logically correct since CSP and Actors are solutions for the same problem(concurrency) And I do think CSP is easier to use compare with Actors as a programming model, but when it comes to distributed and business applications, the comparative advantage is reversed

asplake 2y ago

Why F# there?

karmakaze 2y ago
I was thinking of Mailbox Processor and available Actor libraries. Here's a pretty good rundown I found for some[0]: > Actor Model in .NET > In the .NET world, there are at least a few battle-tested frameworks that allow you to build stateful systems using the actor model. The famous ones are Akka.NET[1], Orleans[2], Proto.Actor[3], and Dapr[4]. All of these systems support distributed mode, as well as a bunch of other features like actor supervision, virtual actor, parent-child hierarchies, reentrancy, distributed transactions, dead letter queue, routers, streams, etc. In addition to these frameworks, .NET has several lightweight libs that do not have many of the listed features but still allow the use of the actor model. For example, F# has built-in support via Mailbox Processor[5] and also there the toolkits: TPL Dataflow[6] and Channel[7]. TPL Dataflow and Channel are not actor model implementations but rather foundations for writing concurrent programs with the ability to use the actor model design pattern. [0] https://medium.com/draftkings-engineering/entering-actor-model-nirvana-with-f-and-tpl-dataflow-b8ab34b84656 https://medium.com/draftkings-engineering/entering-actor-mod... [1] https://getakka.net/ https://getakka.net/ [2] https://dotnet.github.io/orleans/index.html https://dotnet.github.io/orleans/index.html [3] https://proto.actor/ https://proto.actor/ [4] https://docs.microsoft.com/en-us/dotnet/architecture/dapr-for-net-developers/actors https://docs.microsoft.com/en-us/dotnet/architecture/dapr-fo... [5] https://www.codemag.com/Article/1707051/Writing-Concurrent-Programs-Using-F https://www.codemag.com/Article/1707051/Writing-Concurrent-P... [6] https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/dataflow-task-parallel-library https://docs.microsoft.com/en-us/dotnet/standard/parallel-pr... [7] https://devblogs.microsoft.com/dotnet/an-introduction-to-system-threading-channels/ https://devblogs.microsoft.com/dotnet/an-introduction-to-sys...
- CharlieDigital 2y ago
  Clarification: Dapr's actor system is not limited to .NET[0] It currently supports .NET, Java, and Python [0] https://docs.dapr.io/developing-applications/building-blocks/actors/actors-features-concepts/#actor-communication https://docs.dapr.io/developing-applications/building-blocks...
- debugnik 2y ago
  These days, for F# I'd use a task builder loop with System.Threading.Channels and TaskCompletionSource, rather than the MailboxProcessor. Same thing, really; you could recreate the MailboxProcessor API with those in just a few lines.

jerf 2y ago

I view actors like I view "object orientation" in general. In fact they're not even all that dissimilar, being respectively "store and manipulate state attached to a single runtime context" (be it "thread" or "green thread" or async context or whatever) and "store and manipulate state attached to a single highly-structured value". (They go together pretty well, actually.) The primary value comes from the idea, and it can and should be managed and manipulated for the local context. Many people will come along and insist that you need every last thing according to some particular definition (e.g., in OO, "you need multiple inheritance and all of public, private, and protected, and you need virtual methods and you need and you need and you need OR YOU DON'T HAVE TRUE OBJECT ORIENTATION AND EVERYTHING WILL FALL APART"), and will insist that everything at every layer of your program will need to be structured in this paradigm OR YOU DON'T HAVE TRUE WHATEVER AND EVERYTHING WILL FALL APART, but both claims are observably false. I use actors in nearly every program I write, in almost any language I write in anymore if there's any concurrency at all. But they are a wonderful tool to drop in somewhere, and encapsulate some particularly tricky bit of concurrent logic, like an in-memory concurrent cache, without having to restructure everything to be All Actors All The Time. I spent a lot of years in Erlang and still sort of consider this a mistake, up there with Java trying to "force" everything into OO by forcing everything to be in a class, even if it has no business being there. You don't need to go down someone's check list and dot every i and cross every t "or you don't have true actors". It's very much an 90/10 situation where the vast bulk of the benefit is obtained as soon as you have anything even actor-ish, and the additional marginal benefit of going all the way down to some very precise definition can be marginal and may even be negative if it requires you to contort your code in some unnatural way just to fit into some framework that isn't benefiting you on this particular task (e.g., Erlang has a lot of nice tools but if you're building a purely-local command-line app with it for whatever reason you probably don't have a great need for clustering support or OTP in general).

jeremycarter 2y ago
My sentiments exactly - well said. The big mistake is forcing OOP onto everything. It's why I really have an affinity with the virtual actor, it has just enough OOP for me to have classes, methods and internal state - I don't need inheritance, polymorphism, etc - just naive little classifications of things we call objects. I also don't have to think of my system in a hierarchical supervised manner like earlier actor models. I just need cloud native distributed little objects. You can see some modern products coming out that are just that: 1. Cloudflare Durable Objects - https://developers.cloudflare.com/durable-objects/ https://developers.cloudflare.com/durable-objects/ 2. Restate Virtual Objects - https://restate.dev/ https://restate.dev/