4 ms·
> It degrades API surfaces to the worst case :Send+Sync+'static because APIs have to be prepared to run on multithreaded executors This isn't true at all. The
by Ygg2 6mo ago
> It degrades API surfaces to the worst case :Send+Sync+'static because APIs have to be prepared to run on multithreaded executors
This isn't true at all. The Send+Sync+'static is basically the limitation of tokio::spawn
https://emschwartz.me/async-rust-can-be-a-pleasure-to-work-with-without-send-sync-static/ https://emschwartz.me/async-rust-can-be-a-pleasure-to-work-w...
Change the executor, and the bound changes.
- iknowstuff 6mo agoI think they mean tokio::spawn’s signature forces libraries that want to be easy to use with it to expose send+sync APIs (and thus use Arc+Mutex internally)
- Ygg2 5mo agoSee what they wrote: > Async ruined Rust for me, even though I write exactly the kind of highly concurrent servers to which it's supposed to be perfectly suited. It degrades API It refers to async in Rust, and everyone else is responding as if it is talking about async in Rust. That's a mischaracterization. You don't have to use the Tokio executor. It's a bit like saying, "Graphics in Rust are ruined. I need to use Vulkan to make my game." No, you don't. If your use case is unique enough, use something else. There are bindings for OpenGL, DirectX, etc.
- iknowstuff 5mo agoI generally agree but taking a birds eye view I totally understand why tokio’s defaults cloud the image of the entire ecosystem