Is it a bad practice to depend on Tokio in a library?

[JonathanWilbur]

I fully expect my application to use Tokio, but I have a library that needs to write (and only write) to a TcpStream. It seems that my choices are either (1) use std::io::Write in this library, thereby relegating myself to sync I/O, or (2) use tokio::io::AsyncWrite, which means that any application that uses this library MUST use not only async writes, but Tokio, specifically.

With a lot of libraries becoming dependent on Tokio (and often, specifically version 1.x.x of Tokio), it seems like it could become a big problem if Tokio graduates to version 2.x.x or if some other better runtime comes along. Is this a valid concern? If so, is there some (elegant / canonical) way I can write my libraries to avoid this dependency?

[notgull]

Unfortunately, no. Writing to a TCP Stream (asynchronously at least) depends on the Tokio runtime. You can avoid the runtime dependency by only using the trait (or, alternatively, using the AsyncWrite from futures-io instead).

[Noah-Kennedy]

I believe that there are adapters to make other async implementations implement tokio's traits. As far as getting locked on to tokio, currently there isn't really a good cross-runtime set of abstractions for things like, say, connecting a TcpStream, so this is kinda an ecosystem issue.

I share your concerns about the ecosystem being as coupled to tokio as it is, unfortunately I'm not sure that this is going away anytime soon. That said, we are very much aware of how much use tokio has across the ecosystem and I don't think that tokio 2.0 is ever going to happen. Hopefully at some point we have better systems to abstract over multiple runtimes, but for now we do not.

To answer your question directly, it is not really considered bad practice, depending on what you are doing. If you want leave open the option to be cross-runtime, then I'd recommend only using tokio::sync and the traits in tokio::io. If this is too much trouble, just pull in tokio::net and accept that you are not runtime-independent.

I wouldn't really worry too much right now about runtime-independence. The ecosystem needs to evolve a bit before we can get this.