Recently, I found myself returning to a compelling series of blog posts titled
Zero-cost futures in Rust
by Aaron Turon about what would become the foundation of Rust's async ecosyste…
The new API of hyper proper is very low-level. Directly usable API is apparently moved to a hyper-util crate, which, as expected, does have a hard dependency on the tokio runtime.
So, while it’s good that hyper proper won’t hard-depend on tokio rt, it appears that non-tokio-rt usage will either depend on a higher-level 3d party crate, or a lot of effort
from direct hyper dependants to write a lot of glue code themselves.
AFAICT, the current hyper v1 release candidate only depends on tokio for
tokio::sync::{mpsc, oneshot}(andsyncis the only enabled feature).It’s intended to be runtime-agnostic. See also https://docs.rs/hyper/1.0.0-rc.4/hyper/rt/trait.Executor.html . I agree that its ecosystem is still very tokio-centric.
FYI, I had some time to check out
hyperv1 today.The new API of
hyperproper is very low-level. Directly usable API is apparently moved to ahyper-utilcrate, which, as expected, does have a hard dependency on the tokio runtime.So, while it’s good that
hyperproper won’t hard-depend on tokio rt, it appears that non-tokio-rt usage will either depend on a higher-level 3d party crate, or a lot of effort from directhyperdependants to write a lot of glue code themselves.