1. 56
  1. 14

    FD: minor contributor here, please read adjusting for my biased enthusiasm but I’m incredibly excited about this!

    This is the first time I’ve enjoyed working with async rust after years of frustration with the ergonomics and lock-in of the old libraries. This is the work of Stjepan Glavina, who has authored some of the high-performance foundations that libraries like rayon and tokio depend on in their most critical hot paths, and his perspectives on sound API design and performance-critical software really came together strongly for this.

    The main punchline: if you’re familiar with the rust standard library, you already know how to use async-std. If multi-hour compiler sparring matches are your thing, you will be sorely disappointed.

    The second punchline: async-task has been able to achieve single-allocation tasks that finally realize the goal set out years ago to achieve a zero-cost async abstraction. Other attempts until now have needed at least two allocations, and involve far more unsafe code. This is a seriously nice foundation to build atop.

    One of the first things people have mentioned to me when I’ve told them that this was coming was concern over fragmentation in the Rust ecosystem. Never fear! This is built in such a way that you can run the futures in a totally runtime-agnostic way, which unfortunately has not been a goal with many existing rust async libraries.

    Once async-await lands on stable, the rust ecosystem is going to begin a great migration away from the combinator-heavy style used until now. As a long-time async Rust skeptic, I finally feel like there’s a way to do asynchronous programming that doesn’t require much thought beyond what I know from the standard library.

    Check it out :D

    1. 5

      There is still a fragmentation: is code async or not.

      My fear would be that most new libraries start to favor being async just to be more ‘flexible’, which actually means they require a runtime and have a less ergonomic coding style even at times when you don’t actually need async.

      For me personally, I like rust because it doesn’t have a runtime and can use it in contexts where that matters.

      1. 2

        I don’t see your point? That was there before, code was either a mountain future code or green.

        We actually advocate for measured use of async, we see huge problems with async-only codebases. But we see this as a teaching problem. All of the main authors of async-std are by the way training Rust, so we see ourselves in a great position for “when not to async”.

        The point behind Rusts async/await support is that it doesn’t mandate a runtime and you can link one if wanted.

        1. 2

          The parent comment seemed to be saying there was no fragmentation because you can choose your own runtime.

          I was saying there is fragmentation because you must choose a runtime to use this code. The amount of fragmentation, or if it is a problem in the long run is something I don’t know. I was just pointing out it exists.

          Of course, for what it does do, rust async is amazing, and definitely does provide benefit.

          1. 1

            To clarify what I meant by fragmentation, I was referring to the existing async rust ecosystem, which async-std takes care to be a team player with by avoiding hard-wired runtime decisions that cause lock-in.

            You’re right that when you depend on a future, you then additionally need a way to drive it to completion, and that additional complexity needs to be considered in terms of its effect on developer productivity, latency distributions, and throughput for your specific workload on realistic hardware. I’ve long been a harsh critic of what I’ve called “gratuitous asynchronicity” in the rust ecosystem, but a huge part of why I’m excited about async-std is how much lower it makes the costs of using async along each of those vital aspects.

            1. 1

              Agreed, async-std itself is a step in the right direction lowering the costs for everyone.

    2. 2

      @skade, are you the author of this?

      1. 12

        Somewhat. I’m one of the project managers, I wrote the website, an ample amount of docs, some code and partially ghostwrote the announcement. The implementation is mainly Stjepan Glavina. I was a bit on the edge of marking it is as author, but erred on that side.

      2. 2

        That looks great! Thank you for making this.

        I’ve been meaning to convert my code to async/await, but wasn’t sure if various pre-std-futures libraries have been updated yet. Having one package that’s guaranteed to work makes it much more appealing.