51–60 of 88 posts
I have been wondering about this past couple of days. Does kafka streams make Actor Model obsolete? What can you do with actors that you can't with kafka streams if you were starting a project from ground up.
The article doesn't mention [Vert.x]( http://vertx.io/ ), another JVM library/framework (also works outside of the JVM with Javascript for example) that is loosely based on the actor model. And now with Kotlin coroutine support, they've managed to abstract away a lot of the nodejs like callbacks that clutter up your code - you still need to be aware of what's happening wrt callbacks and such, but it makes your code a…
Java
Apache Groovy
Ruby
Eclipse Ceylon
ScalaThe article doesn't mention [Vert.x]( http://vertx.io/ ), another JVM library/framework (also works outside of the JVM with Javascript for example) that is loosely based on the actor model. And now with Kotlin coroutine support, they've managed to abstract away a lot of the nodejs like callbacks that clutter up your code - you still need to be aware of what's happening wrt callbacks and such, but it makes your code a…
[1] http://vertx.io/docs/vertx-core/groovy/#_the_event_bus_api
If you consider a simple chain of actors that do some work and then send on a result to a next actor that then does some more work:
A -> B -> C -> D
This of course, is just the linear scenario. Consider a complex network where there may even be cycles (something D does could somehow indirectly result in a message coming back to A). You've essentially got a completely unstable, unpredictable system. The only way to avoid it is to ensure that every actor is massively over-resourced so that it can never fall behind on processing its messages.
Of course, the second stage of this is that you start designing scalable actor "pools" where more than one actor can service messages and you can scale the size of the pool up and down. But this is at the cost of adding even more dynamic, unpredictable behaviour, and to some extent you just lost the simplicity you were trying to gain by using Actors in the first place.
I'm curious if any thoughts from more experienced folks about how to handle these issues!
I recall that Microsoft Azure Service Fabric SDK is also based on the Actor Model.
I haven't given myself the opportunity to sit down and play with an actor model. But in the meantime, despite reading literature such as this, I have trouble envisioning what it actually entails day-to-day. I think of my experience with channel-based communication in Clojure, Go, and even Rust's mpsc. And every time I feel an instant feeling of debt because I know I'm just one or two more channels away from misunders…
A lot of folks here in the comments are confusing a channel system with actors. Channels can help with actor communication, but they are not the same thing. A problem with core.async in Clojure is that the scenario you describe is very simple to create. You’re managing channels and buffers (communication mechanisms) instead of managing logical modules that do work for you (actors).
If you want to succeed with actors, they need to really be a thing and you ideally want to abstract away the communication mechanism. This is what Erlang/Elixir have done and it’s beautiful. You don’t really spend a lot of time thinking about channels and buffers... you just talk to processes that are living things.
I haven't given myself the opportunity to sit down and play with an actor model. But in the meantime, despite reading literature such as this, I have trouble envisioning what it actually entails day-to-day. I think of my experience with channel-based communication in Clojure, Go, and even Rust's mpsc. And every time I feel an instant feeling of debt because I know I'm just one or two more channels away from misunders…
I too ended up replacing all channels with a mutex or two in a small web socket relay server in Go, and things became 10x easier to reason about. I think part of the problem is the lack of usage/support for channels in the Go stdlib itself (seems that the stdlib authors also prefer mutexs). The other issue with sending a close msg on a channel to let the consumer know there will be no more messages, and that an error…
From a quick skim of it I don't see any mention of the real difficulty I have encountered with the Actor model in practice: managing imbalanced actor workloads. If you consider a simple chain of actors that do some work and then send on a result to a next actor that then does some more work: A -> B -> C -> D Suppose something (anything) happens that make messages to B take slightly longer to process than the rate at…
https://ferd.ca/handling-overload.html
I don’t find that kind of fully async processing pipeline very idiomatic TBH, at least in Erlang - more typically, every request would be its own actor, and do blocking requests to other actors that own shared resources.
From a quick skim of it I don't see any mention of the real difficulty I have encountered with the Actor model in practice: managing imbalanced actor workloads. If you consider a simple chain of actors that do some work and then send on a result to a next actor that then does some more work: A -> B -> C -> D Suppose something (anything) happens that make messages to B take slightly longer to process than the rate at…
From a quick skim of it I don't see any mention of the real difficulty I have encountered with the Actor model in practice: managing imbalanced actor workloads. If you consider a simple chain of actors that do some work and then send on a result to a next actor that then does some more work: A -> B -> C -> D Suppose something (anything) happens that make messages to B take slightly longer to process than the rate at…
Check out this video which describes it pretty well: https://youtu.be/srtMWzyqdp8?t=1027