[Arnavion]

>Except, this isn’t a problem with Rust’s async, it’s a problem with tokio. tokio uses a 'static, threaded runtime that has its benefits but requires its futures to be Send and 'static.

It's not a problem with tokio either. The author's point is specifically about the multi-threaded tokio runtime that allows tasks to be moved between worker threads, which is why it requires the tasks to be Send + 'static. Alternatively you can either a) create a single-threaded tokio runtime instead which will remove the need for tasks to be Send, or b) use a LocalSet within the current worker that will scope all tasks to that LocalSet's lifetime so they will not need to be Send or 'static.

If you go the single-threaded tokio runtime route, that doesn't mean you're limited to one worker total. You can create your own pseudo-multi-threaded tokio runtime by creating multiple OS threads and running one single-threaded tokio runtime on each. This will be similar to the real multi-threaded tokio runtime except it doesn't support moving tasks between workers, which means it won't require the tasks to be Send. This is also what the author's smol example does. But note that allowing tasks to migrate between workers prevents hotspots, so there are pros and cons to both approaches.

[Dowwie]

Actix-web uses the single threaded Tokio runtime per physical core. This architecture is harder to design for than multi threaded async Tokio. Performance gains aren't worth the effort.

[Arnavion]

We use the same design for a product at $dayjob and have had no difficulty in designing for it. There is a lot of benefit from being able to use Rc and RefCell instead of having to go for Arc and Mutex. (Of course it's best if it can be written to not have any RefCell / Mutex at all.)