• d_k_bo@feddit.de
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    In fact, I would hypothesize that, from an ecosystem adoption POV, tokio’s only killer feature is hyper’s dependence on it.

    AFAICT, the current hyper v1 release candidate only depends on tokio for tokio::sync::{mpsc, oneshot} (and sync is 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.

    • BB_C@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      FYI, I had some time to check out hyper v1 today.

      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.