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!
Gotcha. I'll still have to work on a tokio implementation for AtomicServer compatibility, so I expect to open a PR for that (which could be just a temporary thing).
You were saying that AtomicServer would also be refactored to use axum maybe?
Well, if I'd start the project again I'd go for Axum, but it would be a pretty costly change now I think. Is probably far easier if I change NG to Tokio!
Gotcha. I'll still have to work on a `tokio` implementation for AtomicServer compatibility, so I expect to open a PR for that (which could be just a temporary thing).
> You were saying that AtomicServer would also be refactored to use axum maybe?
Well, if I'd start the project again I'd go for Axum, but it would be a pretty costly change now I think. Is probably far easier if I change NG to Tokio!
You can for sure do a PR for just switching to tokio in NG, without using a feature for compatibility with smol or async-std. Then I will do the "feature" thing probabyl before I accept your PR. Probably starting on the 19th of July, if this is OK for you.
All in all we both want this refactor in NG to happen very soon, so I will help.
Axum is compatible with both tokio and smol, so all good about that on NG side.
I am giving you access to make PRs in the repo :)
You can for sure do a PR for just switching to tokio in NG, without using a feature for compatibility with smol or async-std. Then I will do the "feature" thing probabyl before I accept your PR. Probably starting on the 19th of July, if this is OK for you.
All in all we both want this refactor in NG to happen very soon, so I will help.
Axum is compatible with both tokio and smol, so all good about that on NG side.
I am giving you access to make PRs in the repo :)
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!
Gotcha. I'll still have to work on a
tokioimplementation for AtomicServer compatibility, so I expect to open a PR for that (which could be just a temporary thing).Well, if I'd start the project again I'd go for Axum, but it would be a pretty costly change now I think. Is probably far easier if I change NG to Tokio!
You can for sure do a PR for just switching to tokio in NG, without using a feature for compatibility with smol or async-std. Then I will do the "feature" thing probabyl before I accept your PR. Probably starting on the 19th of July, if this is OK for you.
All in all we both want this refactor in NG to happen very soon, so I will help.
Axum is compatible with both tokio and smol, so all good about that on NG side.
I am giving you access to make PRs in the repo :)