11–20 of 48 posts
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.
Isolation: Since actors process messages they receive sequentially, there are no concurrency issues within an actor. This simplifies reasoning about state mutation and transitions.
...
Fault Tolerance: 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.
Isolation: Since actors process messages they receive sequentially, there are no concurrency issues within an actor. This simplifies reasoning about state mutation and transitions. ... Fault Tolerance: 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. The system model in which each actor instance is s…
Please tell me more about its irrelevance, etc, I'd love to learn!
Isolation: Since actors process messages they receive sequentially, there are no concurrency issues within an actor. This simplifies reasoning about state mutation and transitions. ... Fault Tolerance: 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. The system model in which each actor instance is s…
Does anyone care to share an example of the OrderService that is not anemic?
If you work this back to DDD, then the Order entity would have an AddOrderLine method. The central service would be responsible for handing out Order entities and saving them once modified.
Up until a few years ago (prior to my previous job) I was a hypothetical believer in DDD and actors as two equally viable alternatives. I am now strongly against DDD, but still agree with the article on a hypothetical basis about actors.
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…
Isolation: Since actors process messages they receive sequentially, there are no concurrency issues within an actor. This simplifies reasoning about state mutation and transitions. ... Fault Tolerance: 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. The system model in which each actor instance is s…
I don't see how this isn't still both possible and entirely relevant to modern systems. An actor is not necessarily a system process/thread. It has more to do with scope/context than any particular execution model. Think more like a request handling context in an async language.
That may not be how some folks understand the concept of crashing, but it's definitely how most folks understand it, at least insofar as they write software.
1 service instance needs to be able to handle O(1k+) concurrent requests at scale, and a failure in any given request can't impact other in-flight requests. Those failures aren't crashes, and that software isn't crash-only -- using those terms just obfuscates things, and makes everything harder for everyone.
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.…
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 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.…