Rationale for using async-std rather than Tokio

Why was async-std used? Tokio has existed longer and is far more popular. GitHub Star History

1 Like

Also: Quinn (and quic-p2p) seem to use tokio. But running 2 reactors shouldn’t be that inefficient. I think you don’t need to run 2 executors, tho. If your main executor is tokio and you run async-std io functions it would just start the async-std ractior in the background, not sure if it would work the other way around.

Where exactly?

AFAIK majority of the code is using tokio…

safe-cli, safe-api, safe-ffi eg

1 Like

tokio is used there also.

Not sure what async-std is for there TBH. Perhaps it’s for a specific type… The event loops used are all tokio based though AFAIK.


It’s worth noting that at the mo we’re working on updating to latest tokio and futures (and having the lower libs be as purely async/await as we can).

1 Like

@joshuef

FWIW I can recommend the related projects GitHub - tokio-rs/tracing: Application level tracing for Rust. and GitHub - tokio-rs/loom: Concurrency permutation testing tool for Rust..

1 Like

Thanks @anon78698497, will check them out!

1 Like