undefined | Better HN

0 pointssteveklabnik5y ago0 comments

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 interoperation points are still being worked out, so it's not perfect yet.)

0 comments

12 comments · 3 top-level

olalonde5y ago· 8 in thread

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 "runtime agnostic" libraries in the future?

steveklabnikOP5y ago

Yes, that is what I alluded to at the end. There's a few points here that still need some interop work. The intention is to fix that, but it's non-trivial. We'll get there.

bogeholm5y ago

Steve, just want to say thanks for your dedication - I find you’re always around when there’s a Rust thread on HN

1 more reply

pimeys5y ago

You can make libraries runtime agnostic, but it requires a bit of design to get right. We tried our best with Tiberius[0], so you just need to provide an object implementing the AsyncRead and AsyncWrite traits from the futures crate, such as the TcpStream from async-std or tokio (using their compat module).

It is not perfect yet, and especially how tokio does not follow the rest of the ecosystem by implementing their own traits is kind of disappointing. We can work around that, but I was hoping they would fix this by version 1.0...

[0] https://github.com/prisma/tiberius

Matthias2475y ago

Yup, building libraries on IO traits which then are implemented by the particular runtimes is a good way to have a runtime agnostic library. Ideally the IO traits are defined in the library itself, to make them not again dependent on another moving target. You can provide implementations of the "glue code" for particular runtimes in separate crates to ease integration for users.

Another way to be runtime agnostic is to start a particular runtime as part of your library, which is used internally. The public interface of your library can provide async functions which are agonstic to a particular runtime, since all actions will be deferred/forwarded to an internal runtime. That approach has a bit more overhead, but can ease usage.

mesh5y ago

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.

jkelleyrtp5y ago

You can make async-std mimic a tokio runtime by adding “tokio02” or “tokio03” to the list of features for async_std. At its core, futures and future combinators work under all runtimes, it’s just some features will complain if they don’t detect the tokio runtime.

le_didil5y ago

that's a good point, when playing a bit with rust last year I found that the libraries that deal with "async stuff" (like http clients, db clients etc) are mostly split, some use tokio and some use async-std, and they were incompatible. Not sure if the situation has improved now but it looked like an ecosystem split at the time.

sanxiyn5y ago

Work is in progress, but the situation hasn't improved yet for end users.

pfraze5y ago· 1 in thread

As always, very elegant. Thanks for the added info.

steveklabnikOP5y ago

You're welcome, thanks :)

If you want to dig deeper:

* https://www.infoq.com/presentations/rust-2019/

* https://www.infoq.com/presentations/rust-async-await/

1f60c5y ago

I knew you needed to use a library like Tokio with asynchronous Rust, but I never understood why, so thanks.

That said, the last time I looked at it, Tokio was much too complex for my tastes.

j / k navigate · click thread line to collapse

0 comments

12 comments · 3 top-level

olalonde5y ago· 8 in thread

steveklabnikOP5y ago

Yes, that is what I alluded to at the end. There's a few points here that still need some interop work. The intention is to fix that, but it's non-trivial. We'll get there.

bogeholm5y ago

Steve, just want to say thanks for your dedication - I find you’re always around when there’s a Rust thread on HN

1 more reply

pimeys5y ago

[0] https://github.com/prisma/tiberius

Matthias2475y ago

mesh5y ago

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.

jkelleyrtp5y ago

le_didil5y ago

sanxiyn5y ago

Work is in progress, but the situation hasn't improved yet for end users.

pfraze5y ago· 1 in thread

As always, very elegant. Thanks for the added info.

steveklabnikOP5y ago

You're welcome, thanks :)

If you want to dig deeper:

* https://www.infoq.com/presentations/rust-2019/

* https://www.infoq.com/presentations/rust-async-await/

1f60c5y ago

I knew you needed to use a library like Tokio with asynchronous Rust, but I never understood why, so thanks.

That said, the last time I looked at it, Tokio was much too complex for my tastes.

j / k navigate · click thread line to collapse