Comment by VWWHFSfQ
3 years ago
rust team needs to abandon their own execution runtime and just bless tokio and pull it into std. They're doing nobody any favors right now
3 years ago
rust team needs to abandon their own execution runtime and just bless tokio and pull it into std. They're doing nobody any favors right now
I'm struggling to get tokio out of my executable. I'm not using it, but stuff keeps pulling it in. Async contamination is a huge problem. For highly concurrent code with threads running at different priority levels, if async gets in there it makes a mess.
You know what they say about libraries; if you're not having problems, you're not using enough of them.
On a more serious note, "I want other people to write my code, but they're not following my standards" is rarely a sympathetic point of view.
Sorry if this is ignorant, but what’s the difference between async and concurrent? Is the problem that async schedules everything itself?
"Async" is optimized for the special case of a server that is I/O bound and spends most of its time waiting for network traffic. This covers most webcrap, so many people who do nothing else want that. It also works like JavaScript, a model with which many web programmers are comfortable.
It's a bad fit if you have enough compute work to keep all the CPUs busy. Then you're dealing with thread priorities, infinite overtaking and starvation, fairness, and related issues.
5 replies →
The Rust team doesn't have its own execution runtime. Tokio is certainly the closest thing to the "default".
Given that Linux kernel is using async Rust which is implemented on top of kernel workqueue, and tokio won't be usable in kernel, it is a good thing tokio is not blessed. That's what enables both userland and kernel to use async Rust.
There can be both a "blessed" executor, while staying optional for such cases.
For example, Rust std lib has blessed Mutex. Even though these can't be used in the kernel, it is still good to have them in the std lib for >90% of normal crates.
That is never going to happen, for both good reasons and bad reasons.
Yeah I figured. Fragmentation by design.
One person's "fragmentation" is another's "supporting multiple use cases is important, even if their requirements are divergent."