Hacker News Reader

Comment by rossmohax | Hacker News Reader

It 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.

View on HN

https://github.com/stjepang?tab=overview&from=2020-12-01&to=...

"""smol (likely discontinued, since author left rust)""" doesn't seem well supported and smol is used by async-rs these days iirc.

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/mmastrac/stylus/

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.

Can't find async-std feature here: https://github.com/hyperium/hyper/blob/master/Cargo.toml

do you have an example?

Either way, "can be configured" means that custom code for each runtime must be written, it is not like lets say "Futures", which can be used generically.

Here is an example: https://github.com/async-rs/async-std-hyper/blob/master/READ...

You do have to write a ~50 loc compat layer. However, most of the compat layer is due to the fact that tokio's `AsyncRead` and `AsyncWrite` are different from the standard futures crate, which may change in the future [0]. After that, you just have to implement `hyper::Executor` for async-std's `spawn`, and `hyper::Accept` for async-std's `TcpListener`.

Of course, it is not as generic as "Futures", but it is relatively simple to do. As @steveklabnik mentioned above:

> 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.

[0]: https://github.com/tokio-rs/tokio/issues/2716

> tokio's `AsyncRead` and `AsyncWrite` are different from the standard futures

The standard futures library does not have an AsyncRead or AsyncWrite:

https://doc.rust-lang.org/std/future/index.html

Probably in reference to

https://docs.rs/futures/0.3.8/futures/io/trait.AsyncRead.htm...

https://docs.rs/tokio/1.0.0/tokio/io/trait.AsyncRead.html

Yup, that is what I was referring to.

It bugs me that that library will spin up a scheduler without being asked to do so.

As I understand it, that difference (vs Tokio) was the main driver behind the projects splitting.

I also think it's a bit presumptuous for them to name themselves "std". It'll be even more ridiculous in the likely event that Tokio becomes the std:: asynchronous I/O library. It's asking for confusion.

Since when did Stjepang leave Rust?

he posted a goodbye issue on a smol repo, but since then deleted it, so maybe he changed his mind

I found the github issue in Google cache. I'm not sure it's really fair of me to post this link here, but equally I think it's better to give the actual text rather than leave it vague.

https://webcache.googleusercontent.com/search?q=cache:PRjMyv...

Thanks for the pointer! It's really sad to hear this. I'm using smol in my project and really like it. I didn't know the author left until now. It's a great loss for Rust, in my opinion.

He switched to Go.

Stjepang is a very smart person and I'm actually quite excited about what he's going to bring to the Go world.

Rust/Go really are the Emacs/Vim of programming languages: little in common but commonly mentioned in the same breath.

Was there a blogpost? Or when/where was this announced?

> and there is smol (likely discontinued, since author left rust)

Whoa. smol is great. Why’d the author leave?

That's not entirely true. If you want to write an entire standalone application that compiles into a binary and starts up a scheduler, then yes, you have to pick a scheduler runtime.

If you're writing a library to be used by others you can very often expose only types which come from std::futures. The result will work with all of the runtimes.

Woah, I didn't know about that. Does this mean Rust only has one maintained runtime now? Namely Tokio.

I think it's rather that smol is "complete" and doesn't need much maintenance.

Maybe that's true. I don't know how complex these things are, or if they will be affected by future changes in the language, but it feels weird to say that a critical piece of software is complete. I wonder if many new libraries will use Smol.

One of the principles that stjepang was very keen on for smol was that libraries shouldn't depend on it. Libraries should be written in an async-executor generic way and the end binary should then be free to use smol as the executor, or tokio, or anything else.

I'm currently using smol (in an application I'm developing - not just a library) and I don't think this will scare me away. He appears to still be responding to pull requests, and smol consists of a reasonably small amount of very high quality code.

Async-std is still actively maintained and developed.

I was under the impression that it's based on Smol, but maybe I'm wrong.

It has separate maintainers (a whole team), who will continue to maintain the parts of smol they are using. Smol is relatively small and sinple.

If core rust provides an interface for async/await why does usage of it tie you to a specific runtime? Whats the point of that?

Usage of it, on its own, does not tie you to a specific runtime.

Using runtime-specific features and APIs ties you to a specific runtime.

Is this just an artifact of the current work in progress state of things? Is it just a matter of the interface settling and library authors providing a bit more configuration options to become runtime agnostic?

I am not a super expert in all of the exact details, but my understanding is that generally, there are a few features that don't have a common trait yet. For example, "spawn me a new task." Once those traits exist, libraries can be written against them, and it'll all be agnostic. But you only even run into that kind of problem if you need that specific API in the first place.

Reply on news.ycombinator.com