Why Tokio over other async runtimes?

[garikAsplund]

Hey, I'm a newer dev with a curiosity for Rust and system design. So sorry if this question isn't the most succinct.

I know Tokio has a large and mature ecosystem, but was wondering if there were other pros/cons to going with it over potentially faster async runtimes like glommio or monoio.

Would these newer runtimes even make sense in this application? Were they not around or still not stable enough to go with them and eke out some extra perf? I know they're also best for servers and maybe that's not as useful in this instance, but the thought of 3x performance for compute heavy workloads seems attractive.

[rtyler]

👋 There are a couple reasons, but mostly I would say Tokio is used because of inertia 😄 I tend to use async-std for a lot of projects myself. There are ways to adopt the futures crate and build runtime agnostic APIs, which we haven't done because for a lot of higher level operations which require datafusion which takes a tokio dependency anyways.

When designing futures-based APIs, you lose the ability to basically call any blocking operation too, which means everything should/must be async top to bottom, and you rely on the caller to block on things in their runtime. In some ways that would also represent a pretty big API shift for our work with negligible benefit, since we still have to build in tokio anyways 😆 😢