In the interest of sparking a little discussion (not too spicy please, we’re having a nice clean start here) I thought I would ask the question. It’s something I’m legitimately wondering about as someone who has reached for tokio by default for years.

I’m aware of async-std and smol, probably unaware of others. If you’ve used or prefer a different async runtime, what trade-offs might I be interested in or what features am I missing out on?

  • Aloso@lemmyrs.orgEnglish
    13·
    1 year ago

    There are executors for more specific use cases.

    • For example, bastion is a “Highly-available Distributed Fault-tolerant Runtime”, inspired by Erlang, and including an async executor.
    • embassy includes an async executor specifically for embedded systems.
    • fuchsia-async is an executor for use in the Fuchsia OS.
    • wasm-bindgen-futures converts Rust Futures to JavaScript Promises and schedules them to run to completion. It could also be seen as a (very basic) executor.
    • ids1024@lemm.eeEnglish
      6·
      1 year ago

      I think gtk-rs is another interesting example. The glib crate provides an async executor, since glib already requires running its main loop. So if you just need to run a couple futures you don’t need another executor in one or more other threads, and tasks spawned in the glib executor can call functions that need to be run in that thread, since gtk types are generally not thread safe.

      So integrating into other things could be a reason to use a different executor…