Migrating from `async-std` to `tokio` #41

Open
opened 3 weeks ago by joepio · 3 comments
joepio commented 3 weeks ago
Collaborator

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?
Owner

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!
Poster
Collaborator

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!
Owner

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 :)
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: NextGraph/nextgraph-rs#41
Loading…
There is no content yet.