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?
I believe message passing should be fine. That is what I would build.
I had async-std and tokio running alongside each other for a while without issues. But I was only communicating between sync code and tokio/async-std I think, never between the two of them.
If you start by building a small example where tokio sends a message to async-std you should be able to see if this works for you and which channel implementation to use.
I only got rid of async-std because I wanted to trim down on dependencies for the sake of purism and build speed. I didn't have issues from using both.
(I was using kanal as a channel, but that looks dead right now. So maybe try something else.)