Is it a concern that both Tokio and stdlib have AsyncRead+AsyncWrite traits that seem to be incompatible?
Tokio 1.0 – async runtime for Rust
41–50 of 422 posts
Re: Tokio 1.0 – async runtime for Rust
#42It is unfortunate, that libraries have to be coded against specific runtime and not generically. There is tokio and there is smol (likely discontinued, since author left rust), maybe other runtimes will emerge, but whole ecosystem is already tied to tokio.
async-std [0] is pretty widely used as well. [0]: https://github.com/async-rs/async-std Most libraries can be used with different runtimes. Hyper for example, which uses Tokio by default, can be configured to use an async-std executor.
I always get a weird vibe from async-std. I respect the people working on it, but it feels like it's trying to boil the ocean.
I'd be very interested in hearing other opinions, as my Rust project [1] is currently stuck on an older version of Tokio while I wait for deps to update. I'm either going to have to bite the bullet and replace deps or bite more bullets and find a different runtime.
Re: Tokio 1.0 – async runtime for Rust
#43Earlier quoted context omitted.
To provide some more color on why this isn't built in, different runtimes provide different kinds of guarantees and performance profiles. A webapp has very different requirements than an embedded system, and so we don't want to provide a single runtime. The language contains the basic things needed for the ecosystem to exist, and interoperation points, and then leaves the rest to said ecosystem. (Some of those intero…
When learning Rust a few months ago, I built a small client library for a REST API using reqwest (which uses Tokio). I then started writing a web app using Tide ( https://github.com/http-rs/tide ). I eventually realized that it would be difficult to use the library I had built earlier since Tide uses the async-std runtime rather than Tokio. That was very disappointing. Is there any plan to make it easier to write "ru…
I had the exact same experience. I think it can be a pretty big barrier to getting started, as you really have to lock into a sub-set of the ecosystem (i.e. I can only use crates that have support for Tokio).
I understand the reasoning for not wanting this in the core language, but perhaps there could be some standard implementations which would still allow for custom runtimes.
Re: Tokio 1.0 – async runtime for Rust
#44Huge thanks to all the contributors! I've been using Tokio in a few projects and it has been a very good experience. Also thank you all for the welcoming community. I once posted on Tokio's Github about a quirky (in my eyes) behavior of a particular edge case and got an answer almost in real time. This really makes Tokio a kind of a project where I could see myself contributing if an appropriate opportunity arises.
Thanks again! Looking forward to all the good things still in the pipeline!
Re: Tokio 1.0 – async runtime for Rust
#45It is unfortunate, that libraries have to be coded against specific runtime and not generically. There is tokio and there is smol (likely discontinued, since author left rust), maybe other runtimes will emerge, but whole ecosystem is already tied to tokio.
Since when did Stjepang leave Rust?
Re: Tokio 1.0 – async runtime for Rust
#46Earlier quoted context omitted.
async-std [0] is pretty widely used as well. [0]: https://github.com/async-rs/async-std Most libraries can be used with different runtimes. Hyper for example, which uses Tokio by default, can be configured to use an async-std executor.
I always get a weird vibe from async-std. I respect the people working on it, but it feels like it's trying to boil the ocean. I'd be very interested in hearing other opinions, as my Rust project [1] is currently stuck on an older version of Tokio while I wait for deps to update. I'm either going to have to bite the bullet and replace deps or bite more bullets and find a different runtime. [1] https://github.com/mmas…
Warp should be out pretty soon. It was mainly waiting for hyper, which is already out for 1.0.
Re: Tokio 1.0 – async runtime for Rust
#47Can someone explain to a non-rustacean what Tokio introduces that's not part of Rust? It looks like Rust provides the async/await semantics, so I'm guessing this is an event loop and dispatching system?
tokio is to rust what asyncio is to Python.
Re: Tokio 1.0 – async runtime for Rust
#48Earlier quoted context omitted.
I always get a weird vibe from async-std. I respect the people working on it, but it feels like it's trying to boil the ocean. I'd be very interested in hearing other opinions, as my Rust project [1] is currently stuck on an older version of Tokio while I wait for deps to update. I'm either going to have to bite the bullet and replace deps or bite more bullets and find a different runtime. [1] https://github.com/mmas…
Warp should be out pretty soon. It was mainly waiting for hyper, which is already out for 1.0.
Ah thanks. I researched this a while back and it didn't seem like there was any ETA but perhaps I can just wait for a bit now.
Re: Tokio 1.0 – async runtime for Rust
#49Earlier quoted context omitted.
what did you pivot to and why, if you don't mind me asking?
Can't speak for the commenter, but I used to work for a team couple years ago that used rust and tokio extensively, and some projects were just not a good fit. At the time, futures were well fleshed out but the community hadn't caught up, so we were lacking a futures-compatible postgres and redis client. We wrote the redis client ourselves, and for the main project using rust that was sufficient. But for postgres, th…
The ecosystem has moved forward a lot since then. Pretty much all IO libraries provide an asynchronous API now.
Re: Tokio 1.0 – async runtime for Rust
#50Congratulations on 1.0! Tokio and the ecosystem surrounding it (tracing, hyper, prost, tower) are incredibly well thought out and a pleasure to use for building fast performant services with solid latencies.