Could you elaborate on this? I guess it adds complexity while working with futures is already complex enough.
What I mean is that in Rust, with its relatively safe multithreading, personally I’d prefer easy to use libraries that let me compose a proper solution using existing primitives if/when I need it.
Instead, Actix uses something called the actor model, which is a fancy name for having multiple agents that work independently, but communicate with each other through message passing.
The thing of it is, when I want multiple independent things to be done, in Rust there are safe and easy to use threads available, that also support message passing through channels. Therefore I wonder why it was necessary to 1. seemingly re-invent the wheel and 2. accepting that it is a part of Actix, why it has to be baked in rather than being some optional middleware.
There is the possibility that this was done for performance / scalability reasons (thousands of Rust/pthreads level threads do not scale nicely), but making an n:m scheduler (golang and Erlang/BeamVM have something like this) with actual good performance is no trivial task.