async-std has kind of lost the race against tokio. It is incompatible with increasingly more libraries like reqwest, axum, actix, tonic, sqlx, hyper.
I think nextgraph should migrate to tokio.
The README states A tokio-based version (as a feature) might be available in the future., I'd suggest to only use tokio to minimize maintanance costs.
Migration cost
async_std::main to tokio::main. Trivial.
use tokio::fs instead of std::fs. Trivial.
replase async_std::task. sync and stream etc. Trivial, I think.
replace pyo3_async_runtimes. Not sure how impactful this is.
Maybe some other things?
`async-std` has kind of lost the race against `tokio`. It is incompatible with increasingly more libraries like reqwest, axum, actix, tonic, sqlx, hyper.
I think nextgraph should migrate to `tokio`.
The README states `A tokio-based version (as a feature) might be available in the future.`, I'd suggest to only use `tokio` to minimize maintanance costs.
## Migration cost
- `async_std::main` to `tokio::main`. Trivial.
- use `tokio::fs` instead of `std::fs`. Trivial.
- replase `async_std::task`. `sync` and `stream` etc. Trivial, I think.
- replace `pyo3_async_runtimes`. Not sure how impactful this is.
- Maybe some other things?
Congrats for your first issue on here nd the beginning of our collaboration :)
What is sure is that async-std is discontinued and its developers redirect to smol.
There are still good technical reasons to avoid tokio, for those who want that, and I fine with refactoring with 2 features : tokio and smol.
I see that azum and hyper have both tokio and smol bindings.
You were saying that AtomicServer would also be refactored to use axum maybe?
For the python bindings, I will have to switch to using tokio, because async-std will be discontinued on our side, and it doesn't seem they pyo3 handles smol, so it is just fine.
Thanks for the issue!
Congrats for your first issue on here nd the beginning of our collaboration :)
What is sure is that `async-std` is discontinued and its developers redirect to `smol`.
There are still good technical reasons to avoid `tokio`, for those who want that, and I fine with refactoring with 2 features : tokio and smol.
I see that azum and hyper have both tokio and smol bindings.
You were saying that AtomicServer would also be refactored to use axum maybe?
For the python bindings, I will have to switch to using tokio, because async-std will be discontinued on our side, and it doesn't seem they pyo3 handles smol, so it is just fine.
Thanks for the issue!
async-stdhas kind of lost the race againsttokio. It is incompatible with increasingly more libraries like reqwest, axum, actix, tonic, sqlx, hyper.I think nextgraph should migrate to
tokio.The README states
A tokio-based version (as a feature) might be available in the future., I'd suggest to only usetokioto minimize maintanance costs.Migration cost
async_std::maintotokio::main. Trivial.tokio::fsinstead ofstd::fs. Trivial.async_std::task.syncandstreametc. Trivial, I think.pyo3_async_runtimes. Not sure how impactful this is.Congrats for your first issue on here nd the beginning of our collaboration :)
What is sure is that
async-stdis discontinued and its developers redirect tosmol.There are still good technical reasons to avoid
tokio, for those who want that, and I fine with refactoring with 2 features : tokio and smol.I see that azum and hyper have both tokio and smol bindings.
You were saying that AtomicServer would also be refactored to use axum maybe?
For the python bindings, I will have to switch to using tokio, because async-std will be discontinued on our side, and it doesn't seem they pyo3 handles smol, so it is just fine.
Thanks for the issue!