As far as my understanding goes - both async_std and tokio are different runtimes and are incompatible. Currently I have a lot of code built on top of tokio and it's various facilities, and recently I was looking at a new technology however, it's built on top of async_std.
Is it reasonable to pull in this new technology even if it uses async_std instead of tokio? I assume in order for this work I'll need a separate runtime just for the async_std stuff and then add some sort of shim/communication layer if I wanted this to talk to the existing tokio stuff.
Does this seem reasonable/doable? Or should I just drop the new technology since integration async_std and tokio would be too much to maintain.
There are workarounds when you need two async runtimes on the same project, but before taking you that route it would be better to know exactly what are you trying to do. Pulling a second runtime just for some new functionality is not something most would recommend.
The mentioned tech is a library called "Zenoh". It's basically a pub/sub&RPC framework for low latency network communication.
It's written in Rust and has a crate available to use - but it is built on async_std.
Pulling a second runtime just for some new functionality is not something most would recommend.
Makes sense - but if this had to be done what would be the best way to go about it? All of the other network I/O is done via tokio (or more specifically libraries that use tokio under the hood). So would I just keep all of the "Zenoh" comms separate and just do message passing between the two?