Ractor – a Rust Actor Framework

To me, Rust has adequate concurrency tooling to make ad hoc actor designs roughly on par with more developed ones for many tasks, but supervision is both highly valuable and non-trivial. Briefly, I'd say Rust is top-notch for lower-level concurrency primitives but lacks architectural guidance. Supervisor trees are a great choice here for many applications.

I've tried implementing supervision a few times and the design is both subtle and easy to get wrong. Even emulating OTP, if you go that route, requires exploring lots of quiet corner cases that they handle. Reifying this all into a typed language is an additional challenge.

I've found myself tending toward one_for_all strategies. A reusable Fn that takes some kind of supervisor context and builds a set of children, potentially recursively building the supervision tree beneath, tends to be the best design for typed channels. It forces one_for_all however as it's a monolithic restart function. You can achieve limited (batch-y) rest_for_one by having the last thing you boot in your one_for_all be another one_for_all supervisor, but this feels a little hacky and painful and pushes back against more granular rest_for_one designs.

You then probably want a specialized supervisor for one_for_one, similar to Elixir's DynamicSupervisor.

    struct State { counter: usize, control: mpsc::Receiver<Msg> }
    struct StateActor { addr: mpsc::Sender<Msg> }
    enum Msg {
        Increment { reply: oneshot::Sender<()> }
    }

    impl StateActor {
        pub async fn increment(&self) {
            let (tx, rx) = oneshot::channel();
            let msg = Msg::Increment { reply: tx };
            self.addr.send(msg).await.unwrap();
            rx.await.unwrap();
        }
    }

    impl State {
        fn start(self) {
            tokio::spawn(async move {
                /* ... tokio::select from self.control in a loop, handle messages, self is mutable */
                /* e.g. self.counter +1 1; msg.reply.send(()) */
            })
        }
    }

    // in main
    some_state_actor.increment().await // doesn't return until the message is processed

To me it's simpler than bringing in an entire actor framework, and it's especially useful if you already have control loops in your program (say, for periodic work), and want an easy system for sending messages to/from them. That is to say, if I used an existing actor framework, it solves the message sending/isolation part, but if I want to do my own explicit work inside the tokio::select loop that's not strictly actor message processing, I already have a natural place to do it.

https://docs.ruby-lang.org/en/master/Ractor.html

https://docs.ruby-lang.org/en/master/ractor_md.html

One of the promises of Elixir/Erlang is that you can call a process/Actor on different machine just like you can one on same once you put together a bunch of machines in a cluster

Show HN: Kameo – Fault-tolerant async actors built on Tokio - https://news.ycombinator.com/item?id=41723569 - October 2024 (58 comments)

Also another square that I have not circled with async actor other than actix is that all of them use mutable self and they dont have a great way to have long running tasks. Sometimes you would want to call a remote server without blocking the actor, in actix this is easy to do and you unamed child actors to do that. All those newer frameworks don't have the primitives.

For context, the `async_trait` crate makes futures from trait methods that are wrapped in `Pin<Box<dyn Future<...>>>`, which means that every async call to a trait method must make a heap allocation. This is currently a necessary thing to do if async trait methods were invoked with dynamic dispatch (through `dyn Actor`), but the `Actor` trait has associated methods, so that is already not generally possible.

I realize that methods on the `Actor` trait return futures that are `Send`, but specifically for an actor framework that feels like a very specific design choice that isn't universally good or necessary. Another design would give let the spawned task that executes the actor's messages exclusive access to the actor (so `handle()` could take `&mut self`).

I've ended up implementing a simple alternative design in my own project (it's not fundamentally very hard, but doesn't have all the features, like supervision) because the per-message heap allocations and internal locking became wasteful for my use case.

- handle messages sequentially per-actor (like Ractor, and like Bastion in practice)

- create your own future trait without async/await (like Actix)

I keep hoping the language team will get coroutines off the ground, but it hasn't happened yet.