1–10 of 29 posts
Or, if you’ve evaluated using them in production, but decided against it, I’d love to hear about that as well!
actors are a tool which is not to used solely. Need encapsulate state? Actors can help. Need concurrency? Perhaps futures are a better fit.
the question you ask is problatic at it sees actors as a single solution.
Imho its not so much the actor pattern but the single writer principle. actors are a tool which is not to used solely. Need encapsulate state? Actors can help. Need concurrency? Perhaps futures are a better fit. the question you ask is problatic at it sees actors as a single solution.
So even though Go has this green/micro thread behavior behind the scenes (go routines), it’s main innovation is around the concurrency safe queue (the channel) so those threads can communicate.
Now with actors you can imagine more of a pattern where each holds its own state and messages cause them to modify themselves or send messages to other actors. This behaves more like AI in a game simulation and is useful if independence rather than coordination is a good solution to the problem.
For lots of services this is not the case as the fastest path through all the queues is the best path and the problem isn’t about deciding what to do independently or hiding state within the actor but throughput through known paths. So that’s the difference. If you are tagging video with ML you want queues and throughput, if you are reacting to routing networking messages based on simple rules (erlang) you want actors.
The actor model itself is really good, it makes you think about problems differently, and in my opinion it's better than traditional OOP.
The only issue I have had with Akka is with the tooling around metrics/logging of async calls. The rest, what can I say, it's in production and I am barely on call because of issues- certainly not because I write bug free code, but because I believe the framework is really solid, while the actor model makes you think in a different and probably more simplified way which might help with developing simpler solutions.
I have also the feeling that it's niche, because of simpler frameworks like Springboot that offer most of what you need out of the box and it doesn't require additional "learning".
We run Flink for stream processing and Spark for batch processing, both of which are backed by Akka (and therefore the actor model).
Imho its not so much the actor pattern but the single writer principle. actors are a tool which is not to used solely. Need encapsulate state? Actors can help. Need concurrency? Perhaps futures are a better fit. the question you ask is problatic at it sees actors as a single solution.
Let me second this. For example in Go, the simplest way to use a channel is to queue work to it from several endpoints. Then another Go routine can pull it off, usually becoming the exclusive writer of whatever the next step the computation is. So even though Go has this green/micro thread behavior behind the scenes (go routines), it’s main innovation is around the concurrency safe queue (the channel) so those thread…
If someone were using Go routines and channels, what do you think is the “clear” moment that they would benefit from actors? When the sequence of steps in a workflow are non-deterministic?
We run Flink for stream processing and Spark for batch processing, both of which are backed by Akka (and therefore the actor model).
Very dumb question: when you say backed by Akka, what exactly do you mean? That you’ve configured a “binding” between Flint/Spark and Akka, which spins up actor instances (Java/Scala classes?) whenever some events occur? Or that Flint/Spark use Akka behind the scenes?
For the explicit actors, we use them to model state machines around I/O (e.g. stateful protocols). I've found that the application area is fairly niche, as many patterns of async work are clearer through queues, futures, or streams. The use of actors is insulated from the rest of the application code through interfaces that use futures or streams. But, internally, if you have to manage complex state where events can occur at any time and a mail-box like/internal queue is sufficient, then they tend to be easy to understand... once the initial ramp-up period is over.
Additionally, I've found them to require very little maintenance as developers tend to get to 100% _flow_ test coverage without a lot of difficulty.
We use them both implicitly (underlying Akka Streams) and explicitly (both classic untyped actors and typed actors). For the explicit actors, we use them to model state machines around I/O (e.g. stateful protocols). I've found that the application area is fairly niche, as many patterns of async work are clearer through queues, futures, or streams. The use of actors is insulated from the rest of the application code t…
And could you share the distinction between typed and untyped actors? Is that related to how the caller addresses/accesses methods on that actor?