Hacker News Reader

Comment by samsartor | Hacker News Reader

Actors in Rust still kind of suck because there are no first-class resume arguments. In order to provide a `&mut State` you have to either:

- 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.

View on HN

What is a first-class resume argument? How does it enable &mut State and non-sequential messaging within Rust's current futures design?

Right now the only arguments to Future::poll are self and the task scheduler context. Any borrows of mutable state have to be captured by self, which means only one future with access to the state can be inflight at a time. If `&mut State` was an argument on resume, then the actor could schedule many futures simultaneously, which each getting temporary access to the state whenever it makes progress.

Actix does exactly that, but it needs a bespoke ActorFuture trait with extra poll arguments. But until https://lang-team.rust-lang.org/design_notes/general_corouti... gets worked through, there is no way for actix to support async/await.

So you're looking for a way for a future to make use of temporary access to state just while being polled? The issue being that since a future captures references in self you can't have multiple futures able to reference the same data via a &mut pointer. Instead you need to use Rc.

If I'm understanding, then I don't yet follow the use case. You want to have multiple actors reading from the same message queue? Or different concurrent chunks inside of the actor?

This feels to me to strain against the actor design pattern a lot. I feel this often, that futures are somewhat in tension with actors. There are too many options.

Reply on news.ycombinator.com