21–30 of 48 posts
Some background: https://en.m.wikipedia.org/wiki/Communicating_sequential_pro...
CSP is a bit different from the actor model (see the comparison section in the page you linked).
The biggest difference is that CSP communication is synchronous.
is this AI generated? I flagged because seemed very low on substance and just generic bullet points
is this AI generated? I flagged because seemed very low on substance and just generic bullet points
Does anyone care to share an example of the OrderService that is not anemic?
Some actor frameworks (Erlang, Orleans) would interpret each order being an actor instance, and each order line being an actor instance. To make that clearer: each order row would _logically_ have an actor running somewhere in your cluster. This would mean that an order actor would, by nature, have a "add order line" receiver (i.e. method). Each is in charge of how its data is stored. In reality, you'd _probably_ onl…
I love actors as a concept and I heard some large companies (Expedia) implemented large parts using them. But I also saw how hard it is to understand a large system that built using actors. It is just hard to comprehend all the communication pathways and what happens in the system.
But to be fair, it's never that simple and you always end up with some part of a system that's less "well-designed". In that case,figuring out who talks to who can quickly become a nightmare.
Actors are great on the paper, but to benefit from them, you need great understanding of your domain. I tend to use it later in the development process, on specific part where the domain is rich and understood.
And that's the part I never managed to solve, personally. The state of actors tend to look "a lot like" your domain objects, but you don't want to store it until the very end.
Do you have a data-model for each actor to store their own snapshots ? When do you snapshot ? When do you sync with the "ground truth" ? Do you have different tech for each kind of state (eg "term storage" for actors, then relational db for ground truth ?)
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.…
Why F# there?
> 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-mod...
[2] https://dotnet.github.io/orleans/index.html
[4] https://docs.microsoft.com/en-us/dotnet/architecture/dapr-fo...
[5] https://www.codemag.com/Article/1707051/Writing-Concurrent-P...
[6] https://docs.microsoft.com/en-us/dotnet/standard/parallel-pr...
[7] https://devblogs.microsoft.com/dotnet/an-introduction-to-sys...
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.…
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).
> State can be persisted (e.g., to storage, database or event log) between messages. If an actor crashes, it can recover its state on another node and resume processing. And that's the part I never managed to solve, personally. The state of actors tend to look "a lot like" your domain objects, but you don't want to store it until the very end. Do you have a data-model for each actor to store their own snapshots ? Whe…
If I go all in, then modelling as actors makes sense. The domain model is modelled as in-memory actors, using erlang features for persistence and what not.
But most of the time this isn’t what we want in modern software: instead our state is in a database and we are executing in a request-response setup. This seems to be mismatched with actors, as, it seems to me, at least, you’re mapping the database states into your actors on each request and then back on response, at which point, what do actors actually buy you?
The same mismatch exists with OO too, of course, but with actors there are a bunch of benefits that you get by going all in, which it seems to me are lost if you’re simply building a database backed request-response system.
I mean, many of the OP’s pros of actors rely on actors being long lived things, rather than short lived within a request.
Maybe I’m just missing something. But maybe it’s also just not suited to typical web api backend?