Tokio

“it will cancel whatever async operation the task is currently running. And it does so reliably.”

“Tokio works well because Rust's ownership model overlays with tokio nicely.”

“channels deserve more emphasis here too, especially because they change the architecture rather than just swapping synchronization primitives”

“A more "correct" approach would be to call tokio::spawn with the future to print AB.”

“Tokio shares one buffer pool for all threads so as you scale to 100+ threads the whole thing grinds to a halt.”

“Tokio is very complex and work-stealing is arguably a very bad default in terms of development complexity”

“All the hard works are done by those skillful maintainers of the language and some core libraries such as tokio.”

“Tokio was not starved so handled network requests at low latency”

“Tokio was not starved so handled network requests at low latency.”

“libs like tokio and actix-web were so well-designed that I actually enjoyed reading the code in my free time”

“I'm a big fan of a lot of the things that the tokio project has built”

“rather than exposing a common interface for many executors, the Rust async ecosystem went with a Tokio monoculture”

“For genuine CPU-bound work, submitting to a Rayon worker pool is the way to go.”

“The docs for Tokio even mention this, and provide a number of worked examples of integrating/bridging sync and async code.”

“I'm both an Erlang programmer and a big fan of Tokio and Rust's async/await implementation”

“Tokio especially is extremely widely used for all kinds of things it doesn't work well for.”

“Tokio uses a thread pool with work stealing so it is definitely more advanced than Windows 3.1's model!”

“Tokio's API is not the right one for io_uring, buffer pools for reads changes everything.”

“Tokio and Axum make it quite friendly, and depending on what you are connecting to it becomes super easy”

“you'd probably just want to center on tokio and axum, then stick to the tokio ecosystem”

“pretty much the default if you aren't in a specific, resource constrained use case”

“There are issues in particular with core traits for IO or Stream being defined in third-party libraries”

“tokio (and C++ equivalents) provide you the flexibility to do more things than the native Python/Node runtime does”

“Pulling in Tokio makes your project compile an entire thread management system even if you're just compiling Hello World”

“In pretty much every bit of code I've written both professionally and leisurely I have always used tokio.”

“you pay an allocation for every future unless you do some complex organization of your futures”

“You shouldn't have to pull in big complex dependencies to do what should be primitive things”

“tokio does a whole-program transformation that does its most restrictive checking only after all local checks have been resolved”

“The large majority of the concurrent code I write uses nothing specific from the tokio crate, including spawn.”

“Tokio can also get mad at you if you nest runtimes within one another on the same thread”

“a motley bunch of libraries that are written to use particular modes of tokio that don't necessary play well together”

“Libraries like Tokio (mentioned in the article) have support for this built-in.”

“in tokio codebases where the general expectation is that futures will be Send”

“Start with tokio. Please vend one dependency battery included, and vendor in/internalize everything, thanks.”

“the async models in rust (along with tokio/axum, etc) have been pretty nice and clean in practice”

“The particular implementation of async used by Tokio forces a litany of undesirable traits and lifetime issues into your application code.”

“So instead I have to go look for a similar function but of the other color, probably from tokio.”

“Tokio provides crash-resistant synchronization primitives, but it cannot recover complex structures you've been handling”

“the performance of just using tokio is already pretty good”

“there are costs in portability and supply chain attack surface area when you bring in tokio”