@kellytk raises a point that other's have thought about several times. My view is this:
- Actors in the traditional Hewitt sense have been used as concurrency primitives. That is, concurrent programming used actors as the building blocks for concurrency. We see languages like Erlang use this model.
- Actors in the state + behavior sense are used to represent objects and how those objects should behave/flow. Actors are used for this because there are message guarantees that make working with concurrent changes easy to reason about. Languages like Scala use this model.
Really what needs to be considered is not just the actor model but actor model on a specific language. For Rust, actors are not concurrency primitives. Futures and Streams are concurrency primitives in Rust. Riker and other actor crates in Rust should not be used for IO, since for IO you want to use lower level concurrency primitives.
Actors in Rust allow us to build highly complex, concurrent systems that work with state and changing behavior. This often works well in combination with concurrency primitives (Futures and Streams), where you use streams to work with bytes to build meaningful data that is then offloaded to actors to do their thing based on the current behavior.
This is how I approach concurrency in a Rust project:
- IO: use Futures/Streams directly for smaller parts. Use Tokio if I really have complex IO.
- Computation: use Rayon.
- State: use Riker
- Coordination/orchestration: use Riker
Examples of 'state' in ecommerce could be an online payment or a shipping item. In computer vision is could be an object that is being tracked. In coordinating IO it could be to monitor sessions. State could exist less than a second, or it could be perpetual and use persistence. Ultimately, actors allow this: State is currently X and I receive message Y, what should happen. It allows us to do this regardless of concurrency.
@ArtRand has summarized this concisely above where he emphasized "and ordered processing of tasks".
We have a lot of Erlang programmers in the Rust community and it's natural for folks to see Rust Async/Await (i.e. futures) as a competing concurrency model to Rust Actors, since in Erlang actors are the concurrency primitive. But in Rust they are not comparable and they solve different problems. Actors in Rust are simply a layer on top of Futures to provide futures with ordered processing, messaging, easy state and behavior.
@leenozara @kellytk Thanks for fostering this productive conversation! You both bring up some interesting points.
actor model isn't optimal for IO
I interpret this to imply the use case where an application essentially takes tasks (or requests) and performs logic/IO with them largely independently. This is the classic use case for Go. Basically what you're doing is taking the difficulty of handling concurrency and pushing it down a layer (usually the DB). I agree that actors aren't really necessary for this case. You just want an ergonomic way to logic that appears synchronous without sacrificing performance (and ideally algebraic correctness).
OTOH, if the requests change the state of your application, e.g. you're implementing the database, then actors seem like a natural fit for the reasons elaborated here. I would be interested to know what the bounds of the performance costs are here.
Riker in most cases isn't a great fit for building other crates.
I'm surprised to hear this. I've been drafting up a plan to implement Kafka streams-like API on top of RIker or Actix (pluggable back end maybe?). I think there is potential to use actors to build APIs where you can abstract the complexity of handling concurrency. Ideally, the user of the API doesn't need to know anything about actors! I like this idea a lot, and would be happy to collaborate. With FWs like Actix and Riker becoming mature, with Tonic coming out, 1.39 coming soon, a good opportunity to make (to use a buzz word) reactive apps with all the advantages of Rust is coming soon.
Service trait that the Tower project is promoting there could be a similar suite of common traits for actor framework
Receive<T> can't receive any msg when I use try_tell. Please help me !
impl Receive<String> will log msg
this is my project, can you review it here .
https://github.com/zentechnhitran/nats_riker
I put it /src/bin
cargo run --bin natsactormanger
hga.try_tell("I've arrived safely".to_string(), None);
https://riker.rs/messaging/
Riker suggests using Multi-type Messaging
By utilizing Receive<T> and #[actor], complex message handling can be defined clearly and concisely
if everything is ok
And in the Cargo.toml dependencies only riker and log are necessaryI created config/riker.toml allow Riker print log :))
let _ = child.try_tell(msg.clone(), sender.clone());yields Err(()) and is silently ignored. If you have an
ìnfo!{ block instead of let _ = then you see Err(()).We have to find out where this error comes from. Unfortunately, it is a stack of
Result<(),()> so no error information given. Will dig in
pub fn take<T>... in branch if self.one_time {
match self.msg.take() {
Some(m) => {
if m.is::<T>() {
Ok(*m.downcast::<T>().unwrap())
} else {
Err(())
}
}
None => Err(()),
}yields Err(()). But i have no clue what is going on here, haha ;)
