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.
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).
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:
I like supervision enough that I reimplemented it in Go myself. I have never found a very compelling reason for hierarchical supervision despite using supervision for well over a decade now in one form or another. I support it, because the supervisors themselves are also services pretty trivially. I've gotten a request to implement the other strategies, but when I asked "why", basically, there was no answer, other than "Erlang implemented it".
I find it useful architecturally to be able to have "a thing that is a service", but, if it turns into "two services", I can have that "thing" simply wrap two services internally with its own supervisor and not change its public interface to need to provide multiple services.
Reading Erlang documentation leads people to believe that they're going to create these elaborate hierarchies of actors that crash other actors if they crash and have complicated restart patterns... and I've never found anything useful other than "if this crashes, please restart it".
I'm sure the other use cases exist. It's a big world and there's lots of needs out there. However from what I can tell at least 90% of the actors in the world don't need much more than basic supervision. That is pretty useful, though. It's amazing what that can paper over out in the field sometimes.
> 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
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.
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.