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.