# Async Rust Vision Doc, 2024 update

###### tags: `deep-dive`

This is a (draft) revamp of the async Rust vision doc. The goal is to outline three things

* Where do we want to be by Rust 2023 -- greatest level of detail, scheduled down to months
* Where do we want to be by Rust 2024 -- key goals for the upcoming Rust edition
* Where do we want to be by Rust 2027 -- longer term prospects, a bit hazy

The goal is that, when we're done with this process, we know what we know concretely what we are trying to achieve by 2024 and the big steps we'll be taking to get there (some of which have to happen this year). The 2027 goals are more speculative, but we should have agreement on the "overall shape", if not the precise details or path.

## Tenets

These are the criteria and beliefs that we used to form this roadmap. They are ordered such that, if in conflict, we give priority to the first one.

**Continuous progress.** People are building foundational layers in async Rust *now*. We need to ship incrementally, building our way to the end goal, but improving stable Rust along the way.

**Be ambitious.** We need to continue supporting the async Rust code that exists today, but we shouldn't be held back by it. The current experience isn't where we want it to be, and we shouldn't be afraid to propose and make ambitious changes, as long as there's a path from here to there.

**Enable the Rust ecosystem**. The primary role of the Rust org is to build the interconnections that allow the ecosystem to scale and interoperate. Sometimes standardizing one layer simplifies further development atop it, allowing for a flourishing ecosystem.

**Consistency is better.** The async Rust experience right now varies dramatically depending on your domain, and getting started involves a lot of decisions with non-obvious and long-lasting implications. We need to find ways to make async Rust more uniform.

See also the [Rustacean design principles][rdp] (Reliability, Performant, Supportive, Productive, Transparent, Versatile, in that order). The Async Rust experience as it stands now arguably puts Versatility above Reliability, Supportiveness, and Productivity through constructs like `select!` and `FuturesUnordered` as well as the lack of portable libraries and idioms that work uniformly across runtimes.

[rdp]: https://rustacean-principles.netlify.app/how_rust_empowers.html

## Rust 2023: Async fundamentals

*How it feels by end of year:* Much like today, but async functions in traits work, and there is progress towards portability.

### Top-line goal: static async functions in traits.

Our most important for 2023 is **stabilize statically dispatched async functions in traits**. To feel comfortable stabilizing, we need to establish:

* that we are stabilizing a big enough chunk of functionality to be useful, even if some moderate workarounds are required.
* that our design will support future standard library functionality like async read/write traits, async iterators, and async closures:
* Can we enable a single sync/async trait definition with different modes, or do need a separate family of traits? If the former, we need to ensure that our definition of async functions in traits is compatible with that.
* We don't need to know the exact trait definitions, but we do need to know we can support the features they require (e.g., async iterators need async closures).
* That we know it is compatible with future support of dynamic dispatch.

We will establish these facts through several documents:

* Case studies covering key applications we want to enable. We believe that the current support for async fn and RPITIT, combined with a solution for send bounds, would suffice for the following:
* Customization points within the AWS SDK ([in progress](https://hackmd.io/EWDCg5ycQNeLHvGBUNbrDQ))
* Embedded async applications with Embassy (already using static async functions in traits, so the goal here is to describe)
* Microsoft Project X (eholk?)
* Tower and middleware (under discussion)
* *For each of these, we will document:* (a) what use cases the project has for async functions in traits; (b) what minimal set of features is required to support the use case adequately; (c) what workarounds would be required and how they could be removed in the future.
* Design sketches to ensure we will be compatible with Rust 2024 goals:
* Portability requirements to allow hyper, quinn, or another such library to be runtime independent
* Design sketch for async closures and async iterator -- the goal here is to show how the functionality could work, not to sketch the ideal API
* Dynamic dispatch design space. This is fairly well understood but pulling the blog posts and things together would be useful.

**Maybe-async plans.** The biggest unknown here is send bounds and the library. Currently we are considering a "maybe-async" plan similar to what [Eric proposed here](https://theincredibleholk.org/blog/2023/02/16/lightweight-predictable-async-send-bounds/), which would in turn enable (but not require) a single definition of read/write/iterator that can be "made async". To settle this debate, we need to author RFC(s) laying out the plan we expect to take, to be approved by T-lang and T-libs. We don't need to fully implement support for "maybe-async" traits, though, we simply need to ensure that syntax users use to declare "always async" traits is forwards compatible with that work.

To be very concrete, while the RFC(s) would lay out sufficient plans for "maybe-async" traits that can be used in sync or async mode...

trait ?async Iterator {
    
}

...we only need to implement support "always-async" traits like `trait async KeyProvider` for the initial stabilization.

**Dynamic dispatch workarounds.** Most of the above applications do require support for dynamic dispatch, but they don't actually need it to be provided by the language. For the AWS SDK, for example, it's possible to use the ["erased trait workaround"](https://smallcultfollowing.com/babysteps/blog/2021/10/15/dyn-async-traits-part-6/), and furthermore that workaround is encapsulated within the library and not exposed to end-users. Hopefully this pattern holds true for other applications. We may wish to ship some kind of rust-lang crate to automate the workaround with a procedural macro.

### Secondary goal: support for operator tooling?

One of the most common complains from async Rust users is that the tooling story is not great. Common asks:

* dump all the active tasks; help me diagnose my deadlock
* async-aware CPU profiles that show "per task" data
* step-through debugging where pressing "step over" on a `foo.await` call doesn't go into the runtime

The Rust org is not currently in a position to deliver on these needs, and it's likely that many of them should be served by projects like [tokio console](https://github.com/tokio-rs/console), that live outside the org. However, we may be able to *help* by building in some key enablers. What are they?

### Tertiary goals

There are also some nice to haves:

* Improve code generation efficiency -- futures are too big, this costs performance (pnkfelix is currently investigating this)
* Lift common limitations of current generators -- e.g. knowing when a local variable has been moved

## Rust 2024: The async is all right

*How it feels by end of year:* The standard library is enriched with common traits for iterators, I/O, and they are starting to be used within the ecosystem. Dynamic dispatch works.

### Top-line goals

* async iterator API
* enable convenient portability for libraries like Hyper and Quinn:
* async read, write trait
* async timer trait
* async task spawning trait
* dynamic dispatch for AFIT

## Rust 2027: Async awesomeness

*How it feels by end of year:* To get started with async Rust, you open the Rust book, and it shows how to use standard library traits to create common async patterns. Those same patterns work for embedded async, for the most part. You go to the hot new web framework "Rusty Rocket" and things just work; later on, you toggle a switch in your `Cargo.toml` and deploy it using the Fuchsia runtime.

### Top-line goals

* support for async drop and structured parallelism
* stdlib includes APIs for structured parallelism and concurrency, listening for connections, other basic needs
* adequate to build a something like rocket or axum without relying on a particular runtime
* default runtime makes getting started easy, but easily changed

This is the dreamy future, and it's obviously a bit hazy. It's not even clear that it's *possible* -- certainly achieving things like structured parallelism will require some extensions.

Here are some of the known extensions required that we need to be exploring *now*:

* *Resource types*, meaning some way to define a global "resource" (e.g., an allocator) that must obey a trait, code against that (unknown) type, and then have it specified by the end artifact. This would be used for async runtimes.
* *"True linearity"*: if we want to safely support structured parallelism, we need a way to prevent forgetting futures, or possibly modifications to the future trait, something like that. There are similar challenges for async drop, to avoid the problem of async values being dropped from inside sync code.

## Dates and times

| Item | Who | Q1'23 | Q2'23 | Q3'23 | Q4'23 | H1'24 | H2'24 |
| ---- | --- | ----- | ----- | ----- | ----- | ----- | ----- |
| **Towards 2023 goals:** |
| • AWS SDK case study | ![nm][] ![mg][] | ▓▓░ |
| • Microsoft study | ![eh][] | ░░░ |
| • Tower case study | ![sm][] ![lf][] | ░░░ |
| • Embassy case study | ![db][] | ░░░ |
| • Async Fn plan | ![nm][] ![tm][] | ░░░ |
| • Async Iterator plan | ![nm][] ![tm][] | ░░░ |
| • Dyn dispatch plan | ![nm][] ![tm][] | ▓▓░ |
| • RPITIT RFC | ![tm][] | ░░░ |
| • ?async trait RFC | ![yw][] ![os][] ![eh][] | ▓░░ | ░░░ |
| • Minimal impl | ![os][] | ▓░░ | ░░░ |
| • Stabilization (1.73 branches July 17) | | ░░░ | ░░░ | :dart: |
| • Smaller futures | ![fk][] | ▓▓░ | |
| • Generator limitations | ? | |
| **Towards 2024 goals:** |
| • Implement "dyn*" traits | | | ▓░░ | ░░░ |
| • Design notes for `.box` syntax | ? | | ░░░ | ░░░ |
| • Stabilize dyn dispatch | | | | | ░░░ | ░░░ | :dart: |
| • Nightly support for ?async traits | | | | ░░░ | ░░░ | | |
| • Stabilize ?async read/write | | | | ░░░ | ░░░ |:dart: | |
| • Stabilize ?async Fn | | | | ░░░ | ░░░ | :dart: | |
| • Stabilize ?async iterator | | | | ░░░ | ░░░ | :dart: | |
| • Stabilize ?async timer | | | | ░░░ | ░░░ | :dart: | |
| • Stabilize ?async spawning | | | | ░░░ | ░░░ | :dart: | |
| **Towards 2027 goals:** |
| "Resource types" RFC | ![jt][] ![nm][] | ▓░░ | | | |
| Async-drop plan | ? |

[nm]: https://github.com/nikomatsakis.png?size=20
[tm]: https://github.com/tmandry.png?size=20
[yw]: https://github.com/yoshuawuyts.png?size=20
[os]: https://github.com/oli-obk.png?size=20
[eh]: https://github.com/eholk.png?size=20
[mg]: https://github.com/compiler-errors.png?size=20
[fk]: https://github.com/pnkfelix.png?size=20
[sm]: https://github.com/seanmonstar.png?size=20
[lf]: https://github.com/luciofranco.png?size=20
[db]: https://github.com/dirbaio.png?size=20
[jt]: https://github.com/joshtriplett.png?size=20
[nc]: https://github.com/nrc.png?size=20

---

# Discussion

Copy the template below to leave questions and comments for discussion.

---

## Definition of task

eholk: Do we want to define what a task is in the language?

tmandry: Yeah, eventually we want some std APIs to talk about it.

nikomatsakis: Feels like the more ambitious vision, skeptical of jumping straight there now since the vision might change.

---

## Logical stack traces

jackwrenn: Been investigating approaches to this. Interested in pursuing an "async frame pointer" approach.

eholk: Relation to mw's work?

jackwrenn: Interested in language/runtime inspection as opposed to crashdump. Should help with both.

nikomatsakis: Would like to identify some mechanism that enables several use cases and define an initiative.

tmandry: I would like to find an approach that works for future approaches that aren't an intrusive tree data structure – something like DWARF.

nikomatsakis: Tension between generality and efficiency.

nikomatsakis: More focused meeting in the future?

tmandry: Yep

tmandry: What's in scope?

nikomatsakis: This feels closer to the mental model, productivity, etc. of the core stuff we're working on than efficiency.

---

nikomatsakis: What's the status of drop tracking?

eholk: Slow burn, waiting on decision on the MIR-based analysis by cjgillot to prioritize. That's cleaner architecturally, but there are potential issues.

nikomatsakis: I sense that there are polish bugs that come up often, workarounds that you have to learn. One is working around drop tracking, another is the "type not general enough" error. Do we have a list, and how important do people think those are?

tmandry: I think they're a big deal

nikomatsakis: We should pull this into the roadmap and make sure a types team discussion happens.

eholk: Could work on burning down the drop tracking more.

tmandry: Should try to get to a point of "we think this will/won't have time soon".

nikomatsakis: eholk and I should sync up on issues

---

## Async main and tests

vincenzopalazzo: I think there is a good probability to have a design
for [async main and tests](https://vincenzopalazzo.github.io/async-main-and-tests-initiative/index.html) that I start to investigate maybe is there is
consensus on the design would rust 2024 (in beta/nightly maybe) would be a good goal?

nikomatsakis: Maybe good goal for 2024, or 2027 since it needs the ability to talk about the runtime (which is the 2027 feature).

yosh: I don't think we *have* to be able to talk about the runtime initially. We could have an `async fn main` / `#[test] async fn` working, and figure out the interface to make it portable later on. I suspect this could probably be done using something like `with`-clauses? See also: the next section.

nikomatsakis: that assumes that runtime init. etc happens lazilly, right? I'm not sure if we want that. But we should drill in.

yosh: I was thinking this could desugar to a sparkling `block_on` basically, at least initially. But yeah, let's drill in (perhaps some other time!)

yosh: (apologies for the clunky text-only engagement)

---

## Designing interfaces vs designing types

Yosh (on a mandatory work training, so can't be on the call right now): I'm seeing
a big emphasis on portable interfaces for timers and spawning tasks in the 2024 section. I don't know how this is being discussed in the call, but I'd like to share that I think
in terms of ordering we should be prioritizing defining the actual end-user APIs we want to expose for this functionality *prior* to providing any (stable) abstract interface people can rely on.

An example of this will be "task spawning". What we want to expose from the stdlib may not necessarily be compatible with what's currently in use in the ecosystem. We seem to have soft consensus that structured concurrency is good. But the ecosystem relies on APIs which are unstructured. I'd like to make sure that we're clear on the APIs we want to expose and support prior to providing portable interfaces to this.

tmandry: I do want to see us exploring this. We'll have to talk about it before we stabilize anything related to spawning.

eholk: Timers different?

nikomatsakis: Maybe, kind of a task.

tmandry: Feels like we can stabilize a simple `Spawn` trait that takes `&self` without spelling out the whole structured concurrency story – but we should have an idea of what it looks like.

nikomatsakis: Maybe a roadmap item. I feel the tension between continuous progress and ambition here.

nikomatsakis: We're going to need some kind of root spawn, should we start with that?

yosh: I don't think we have clarity on "work-stealing spawn" vs "non-work stealing spawn"; making `Send`-bounds a sticking point. I think this is also a thing we need to drill deeper into; would be happy to do a presentation on this if anyone's interested? Just want to make sure we don't over-promise on: "we will deliver compatible interfaces", when it may be tricky?

tmandry: I think we can all agree that there should be a design meeting on the space of possibilities and how it relates to structured concurrency.

Yosh: definitely

nikomatsakis: Need to work backward and figure out what goes in Q2/Q3 that help us know what this design looks like.

---

## 2024 edition changes

Yosh: I think we should make sure to take a look at whether there are any changes we want to make related to the 2024 edition. These are not super important, but we also should not overlook them. Some things which we should probably talk about:

- `Future` / `IntoFuture` in the prelude
- `async Struct` notation (related to the `async Trait` stuff)
- …more?

nikomatsakis: `IntoFuture` sure

Yosh: Should regular types which have async methods need to include `async` or `?async` in their name? We've also considered changing `const fn` to `?const fn`. We should talk about these, not sure what to do.

nikomatsakis: Especially because lang team prefers to settle questions on the edition this year. Also, discussion around defaulting to requiring `Send` etc.

eholk: Also something about separating `async` in signature from async block.

Yosh: Loopy: should it be `async fn read_to_stream` or `fn async read_to_stream` for consistency with `trait async Read`?

---

## Topic

name: prompt

---