My experience with actors in embedded telecom contradicts several points of your article:
> Idempotent Design: Messages can be safely retried without unintended side effects.
- This is going to be very hard to achieve. You cannot synchronize states of actors. One actor cannot know the current state of another actor. And if it queries the state, it may change any moment. Thus, for something like money transfer, you cannot write transfer(42, source, destination). You cannot do destination.Set(destination.Get() + 42). You are left with destination.Add(42) which is not idempotent.
> Actors can host multiple interconnected state machines, creating complex yet manageable system behaviors. They are the protected enclave of order.
- It's just the opposite. Actors are chaos incarnate. There is no way to make them behave as you want like them to because unrelated events sneak in and change their states to nobody knows what while you were running your complex use case. And an average actor gets scores of event handlers, each of which implements pieces of logic from several unrelated use cases. The code is unintelligible because every use case is scattered all around the whole source file.
> Aggregation involves thinking of your actors as part of a graph, where smaller, downstream actors notify upstream actors about important events, metrics, or states.
- There was an old pattern Presentation-Abstraction-Control. It's long dead and buried, probably not for no reason. You have just outlined it.
Thank you for sharing your experiences! In the articles I've written we're talking about the Virtual Actor pattern using Microsoft Orleans, or at least a subset of those capabilities.
You should follow the tutorial and give it a go - just to see from my perspective. I'd be happy to zoom call and show you around the framework. These are different from Erlang actors, but I still feel that the modelling/thought process involved is similar.
In Orleans you can create transactional actors, where states can be synchronized. Other Virtual Actor systems also provide this functionality (through forms of distributed transaction coordination), but not all do.
I'll do some research on Presentation–abstraction–control, but on the surface, there are some differences, and I do see the similarity. What I'm talking about is an intelligent hierarchical coupling, not a static PAC relationship. Because actors can do things autonomously their relationships with other actors in a graph can be dynamic.
I have tried to write the articles for people who have had no exposure to thinking this way. It's not a "do it this way for everything!" type model, but rather I'm trying to prompt the reader with "did you know you can do it this way?".
I appreciate you bringing these points to the discussion.
My experience with actors in embedded telecom contradicts several points of your article:
> Idempotent Design: Messages can be safely retried without unintended side effects.
- This is going to be very hard to achieve. You cannot synchronize states of actors. One actor cannot know the current state of another actor. And if it queries the state, it may change any moment. Thus, for something like money transfer, you cannot write transfer(42, source, destination). You cannot do destination.Set(destination.Get() + 42). You are left with destination.Add(42) which is not idempotent.
> Actors can host multiple interconnected state machines, creating complex yet manageable system behaviors. They are the protected enclave of order.
- It's just the opposite. Actors are chaos incarnate. There is no way to make them behave as you want like them to because unrelated events sneak in and change their states to nobody knows what while you were running your complex use case. And an average actor gets scores of event handlers, each of which implements pieces of logic from several unrelated use cases. The code is unintelligible because every use case is scattered all around the whole source file.
> Aggregation involves thinking of your actors as part of a graph, where smaller, downstream actors notify upstream actors about important events, metrics, or states.
- There was an old pattern Presentation-Abstraction-Control. It's long dead and buried, probably not for no reason. You have just outlined it.
Thank you for sharing your experiences! In the articles I've written we're talking about the Virtual Actor pattern using Microsoft Orleans, or at least a subset of those capabilities.
You should follow the tutorial and give it a go - just to see from my perspective. I'd be happy to zoom call and show you around the framework. These are different from Erlang actors, but I still feel that the modelling/thought process involved is similar.
In Orleans you can create transactional actors, where states can be synchronized. Other Virtual Actor systems also provide this functionality (through forms of distributed transaction coordination), but not all do.
I'll do some research on Presentation–abstraction–control, but on the surface, there are some differences, and I do see the similarity. What I'm talking about is an intelligent hierarchical coupling, not a static PAC relationship. Because actors can do things autonomously their relationships with other actors in a graph can be dynamic.
I have tried to write the articles for people who have had no exposure to thinking this way. It's not a "do it this way for everything!" type model, but rather I'm trying to prompt the reader with "did you know you can do it this way?".
I appreciate you bringing these points to the discussion.