1. 22

  2. 5

    I consider myself pretty keyed in to the Rust community, but have avoided the async space until it’s settled (as it appears to be doing \o/). Is there some verbiage on how this compares/relates/contrasts to things like tokio and futures-rs? Because if I consider myself pretty close to the Rust space, but don’t know I’m sure it could begin to look confusing for someone outside the community.

    1. 9

      async-std is an async port of the Rust stdlib and a new runtime system for async/.await. It brings substantially different methods, though it may look somewhat similar to tokio at quick glance. async-std is built partially by previous tokio contributors.

      futures-rs is the Rust project-supported library on top of the std::futures::Futures trait, that provides additional abstract interfaces like Stream, AsyncRead and AsyncWrite traits. AsyncRead and AsyncWrite are fundamental for reading on sockets and files.

      async-std in contrast to tokio opts into these interfaces fully, which tokio doesn’t. That’s most clearly visible in that tokio doesn’t use AsyncRead and AsyncWrite, but instead their own versions, making them incompatible with any library that wants to use the futures-rs types for interfacing. The notion of “incompatibility” between those two libraries mainly stems from this: a lot of tokio-based libraries can be rather easily ported. (it’s harder in applications that want to be abstract over their runtime!)

      Finally, tokio and async-std have very different stability and documentation cultures. tokio has been unstable over the last 3 years, semi-frequently refactoring their interface. For a long time, docs were basically non-existent. async-std wants to commit to its interfaces (which is why we picked a known good one). tokio has just mentioned that the next tokio version after 0.2 will still not be a stable one.

      async-std comes fully documented and with a book since its release and is continuing to venture down that line. We are ready to take that responsibility and want to provide a stable foundation for people to work on now.

      async-std also innovated some areas of the space, e.g. being making all kinds of tasks available through a JoinHandle based system (which tokio just adopted) and providing the first practical implementation of single-allocation tasks (which tokio just adopted).

      It makes us happy that we have something to add to the space. But finally, I think the above philosophical differences make it clear how we can’t operate as the same project.

      1. 3

        As I understand it, async-std and tokio overlap substantially, but make different API choices. futures-rs came first, with tokio built to provide additional APIs for it. futures-rs provides the core utilities (the part of the futures API that’s been stabilized in std is quite small), while tokio and async-std provide additional common capabilities on top of it. async-std is newer, and a lot of the folks who work on async-std previously worked on tokio.

        So, to do a little survey:

        • Things found in futures-rs:
          • Stream trait: like a future, but for sequences of values.
          • Sink trait: something that values can be sent to asynchronously, like a channel or a socket.
          • A collection of basic executors (needed to actually run the futures built up with the async/await syntax), including block_on, ThreadPool, and LocalPool (like ThreadPool, but executing on a single thread).
        • Things found in tokio:
          • API for asynchronous file operations
          • API for asynchronous network IO
          • API for asynchronous process spawning
          • API for “futures-aware” synchronization
          • There’s more than this, but the gist is to say that tokio provides a lot of the building blocks you’d want to build real-world async code. In terms of API design, it has its own structure, terminology, and history that looks different from the standard library APIs they are providing async versions of.
        • Things found in async-std:
          • All the same things I listed above for tokio, with an API that looks a lot more like the structure and design of the Rust standard library (hence the name async-std).
          • async-std is also less mature, and not everything is implemented (async process spawning isn’t really ready yet)

        Just an overview, but hopefully it helps!

        EDIT: The exact timeline of futures-rs and tokio has been updated based on a correction from @skade.

        1. 4

          futures-rs came out of the tokio project, and contains a lot of the necessary utilities you’d want to doing practical work with futures, as the part of the futures API that’s been stabilized in std is quite small.

          You characterisation of futures-rs is technically correct, but not historically. futures-rs and tokio go back to each other, but futures-rs (by Alex Crichton) came first and tokio was built as a runtime for it. The projects later split.

          1. 1

            Thanks! I appreciate the correction.

          2. 2

            Exactly what I was looking for, this is super helpful thank you!

        2. 2

          Good morning. There was a slight clerical mistake yesterday (or rather: today, before I went to sleep late) from my side: it’s 0.99.12 ;).