owned this note
owned this note
Published
Linked with GitHub
---
title: WG-async goal planning 2023-12-07
tags: ["WG-async", "open-discussion", "minutes"]
date: 2023-12-07
discussion: https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/Goal.20planning.202023-12-07
url: https://hackmd.io/4bnHpZRFQgCFdp9qpU8ANw
---
# Goal planning for 2024
Attendance: TC, eholk, tmandry, Adam Leventhal, CE
Minutes: TC
---
## Roadmap pre-planning
* Maybe Async (Trait Definitions)
* AsyncIterator
- `poll_next` vs `async fn next`
- boats: https://without.boats/blog/poll-next/
- yosh: TODO, many posts
- tmandry: https://tmandry.gitlab.io/blog/posts/for-await-buffered-streams/
- wg-async: https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/barbara_battles_buffered_streams.html
* AsyncFnNext
* Async Generators
* Async Drop
- Prototype from eholk:
- https://theincredibleholk.org/blog/2023/11/08/cancellation-async-state-machines/
- https://theincredibleholk.org/blog/2023/11/14/a-mechanism-for-async-cancellation/
- yosh: https://blog.yoshuawuyts.com/tree-structured-concurrency/
- tmandry: https://tmandry.gitlab.io/blog/posts/2023-03-01-scoped-tasks/
- boats: https://without.boats/blog/the-scoped-task-trilemma/
- boats: https://without.boats/blog/changing-the-rules-of-rust/
- boats: https://without.boats/blog/follow-up-to-changing-the-rules-of-rust/
- boats: https://without.boats/blog/generic-trait-methods-and-new-auto-traits/
- niko: https://github.com/nikomatsakis/moro/
- yosh: https://hackmd.io/KqASjHfBR6am3z5INtKCJA
* Async Cancellation
* Async Closures
* Basically exist already, but we need to decide if we want keyword generics or `AsyncFnOnce`, `AsyncFnMut`, `AsyncFn`, etc.
* Finishing AFIT: RTN
* Finishing AFIT: Dyn dispatch
* TAIT
* Concurrency and Parallelism
* Executor/Spawn traits (portability)
* Static concurrency primitives
* Dynamic concurrency primitives
* Organizational - checkboxes for wg-async, what's our relationship to other teams, etc.
* Start stabilizing parts of [futures-concurrency](https://docs.rs/futures-concurrency)
* Starting with: `impl IntoFuture for {Vec, Array, Tuple}`
* 2024 Edition changes
* Future, IntoFuture in prelude
* Documentation
* Revive the async book?
```mermaid
flowchart LR
MaybeAsync["Maybe Async (Trait Definitions)"]
MaybeAsyncInStd["Using MaybeAsync in traits in std"]
AsyncIterator["AsyncIterator"]
AsyncFnNext["async fn next"]
AsyncDrop["Async Drop"]
AsyncCancellation["Async Cancellation"]
AsyncGenerators["Async Generators"]
AsyncClosures["Async Closures"]
BecomingTeam["Becoming a Team"]
RTN["Return Type Notation"]
AFITDyn["Dyn dispatch for AFIT"]
ExecutorSpawn["Executor/Spawn traits"]
TAIT["Type alias impl Trait"]
FuturesConcurrency["futures-concurrency"]
ForAwait["for await syntax"]
AsyncSocketsAPI["Async sockets API"]
AsyncFileAPI["Async file API"]
DefaultAsyncRuntime["Default async runtime"]
AsyncMain["async fn main and #[test]"]
AsyncScopedTasks["Async scoped tasks"]
StructuredConcurrency["Structured concurrency"]
StructuredParallelism["Structured parallelism"]
Combinators2["Combinators 2.0"]
ProtocolPortability["Portability for protocol implementations"]
IouringSupport["Support for iouring"]
AsyncRead["AsyncRead, AsyncWrite, AsyncBufRead, etc."]
MaybeAsyncInStd -->|dep| MaybeAsync
AsyncIterator -->|dep| MaybeAsync
AsyncIterator -->|maybe dep| AsyncFnNext
AsyncFnNext -->|dep| TAIT
FuturesConcurrency -->|dep| AsyncIterator
AsyncCancellation -->|dep| AsyncDrop
```
Project board:
https://github.com/orgs/rust-lang/projects/28
Recent blog post from boats:
https://without.boats/blog/a-four-year-plan/
## High-level goals
* People can't write things they want to write
* People have to use external crates for things that should be in std
* Ecosystem crates can't interoperate well because we don't have foundations in std
* Async is too hard? In what ways?
* Portability for protocols
* Expressiveness gaps
* Where we define expressiveness as "the ability to express something at all", at least without going to extraordinary lengths
## Big questions
* How do we integrate async traits into std?
* Maybe Async trait definitions
* "Do we call it `AsyncIterator` or `async Iterator`"
* I/O Traits
* Should async, sync be the same
* Definitely possible to have convergent APIs (async-std)
* But Tokio has diverged (partly in ways that aren't specific to async)
* https://yoshuawuyts.notion.site/yoshuawuyts/a644246eada64ebab4163fec8a1141e7?v=10b1a319e9d04f5c87cf44849810f281 - catalogues which traits could be made maybe-async, maybe-const, maybe-try, etc.
* Structured concurrency: What it depends on
* async drop, maybe
## Discussion
(Discussion leading to async closures...)
CE: I can add those, but I want to ensure people want it.
tmandry: Yes, we want that.
CE: Because I don't want to do the work and then have people say, "well, we really don't want to do this until we have some generic effect mechanism so we don't have to name these `AsyncFn` etc."
eholk: We could always merge `AsyncFn` etc. into effect generics later. Having names for specific sets of keywords could be helpful, the same way we have `Option::or`, `Option::map`, and `Option::map_or`.
tmandry, TC: +1.
---
tmandry: The biggest thing we're missing is async closures. It'll allow us to prototype things on the library side.
tmandry: The biggest async problem is that it's less reliable in the sense of "if it compiles it works". We should fix that.
tmandry: It'd be good to iterate on the primitives that we have. E.g. replacing `select!`.
TC: +1.
eholk: That could be a good motivating mission for 2024.
Adam: What pathologies are we alluding to here?
tmandry: E.g.:
https://tmandry.gitlab.io/blog/posts/for-await-buffered-streams/
The other one is unexpected cancellations. This is exacerbated by `select!` that drops all the futures that aren't first to complete.
tmandry/TC: The problem is the lack of linear types.
TC: In synchronous Rust you don't notice the lack of linear types as much because you can use the ability of functions to control unwinding to get most of the control you need. In async Rust that doesn't work, and you see that in the bugs in async projects.
---
Adam: Better documentation on async Rust would be helpful.
Adam: There's a lot of caveats around cancellation safety, etc. that are enforced by documentation and the power of being a good programmer. The kind of thing that Rust helps you avoid in the area of memory safety. E.g. mutexes don't work the way you expect.
eholk: What I'm hearing you suggest is that we should perhaps focus on delivering more short-term value. People have been feeling that we've been shipping slowly. We did recently ship AFIT, but the fact that it took 4 years is a fair criticism.
Adam: There are lots of non-technical ways you could improve it as well.
TC: Part of what happens here is that the people in this WG are unsatisfied with async Rust, so we spend our limited time trying to work out how to improve that in the language rather than documenting or training people on the current state of things.
Tyler: Honestly I would love to document best practices, but not the right person because I don't know them.
Adam: Working group leads and sets priorities, you can ask for help.
TC: There's a balance between what's handled by us and what's handled in the ecosystem, e.g. by Tokio. They provide good documentation about how to use async Rust correctly with their tools, e.g. the mini-redis example that they maintain.
Adam: Once you understand cancellation it's clear, but that doesn't help write code that's correct with respect to cancellation.
Adam: It'd be good to publish a blog post that was candid about where we wish async were versus where it is. It might be good to actually discourage some users from using it. I understand this may be a hard document to write.
TC: That document is maybe difficult to write for an unobvious reason. The degree to which it's useful to be unhappy about something is related to the degree to which we think we can make it better. If we were to believe something couldn't be made better, then it'd be a case of "it is what it is and make the best of it". But working out *whether* and *to what degree* we can make things better, and getting consensus on that, is the hard problem.
tmandry: Here's an excerpt from my blog post draft:
> If there was one principle that guides my thinking, it would be "reliability above all else". Rust is not the most succinct language or the easiest to learn. Its most important feature is that programs written in Rust behave predictably in a wide variety of situations. This makes the upfront costs of writing Rust worth it in the end: You might spend more time learning Rust and writing an initial implementation than you would in Python, but your program will behave much more predictably, your reviewers will have an easier time, and you'll spend less time fixing bugs.
>
> With Async Rust I want the story to be just the same. But today, there are many more footguns to avoid in Async Rust programming than in normal Rust. Some of this comes from the inevitable complexity of the problem space, but much of it comes from the interaction between that problem space, the language, and the libraries we use to write async code. We have a long way to go before Async can truly be on equal footing with the rest of Rust.
Adam: I'd say, to your first paragraph, "your time is well spent in Rust." Maybe not so much in async. If you invest your time in understanding lifetimes, etc. where people get tripped up, it will pay off in that your programs will work by construction. In async, you're going to struggle upfront and later.
TC: The question is always, "compared to what?" If you're writing something in async Rust to hit a certain performance profile, your alternative is writing the manual state machines by hand in C, since that's what Rust is doing for you. If you had to do it that way, would you hit these same problems? You probably would and then some. We should keep this in mind when framing and positioning it.
Adam: Totally agree. You can make a comparison to that, and you can make a comparison to Rust's values (to paraphrase Tyler).
---
TC: We've uncovered some good guiding goals here. E.g., "async Rust programs that compile should likely work, as they do in sync Rust." And, that it should be true that "your time is well spent writing async Rust."
TC: What do we think about adopting portability across executors as one of our guiding goals?
eholk: We might be a bit early to do that. AFIT was a big step here. I'm not sure it's a huge pain point. People might be happy with Tokio.
tmandry: Two aspects to consider. In terms of the overall health of the ecosystem, it'd be better for it to be dense, so people can move between things. But I agree with eholk that it's important but not urgent. I'd like to continue iterating on what the actual primitives are that people use to build async programs. There, the lock-in to Tokio may become more urgent. Something like a spawn trait to abstract the executor might be helpful.
TC: There's a organizational imperative as well as a technical one. When there's an intermediary, especially a good one, the people that have that need talk with the intermediary. That interferes with backpressure of user needs toward the team members on the language side. This can give us a skewed impression of what's important. The vacuum that creates gets filled in with other things.
---
TC: To what degree do we think `AsyncIterator` is a priority as compared with other things?
CE: In terms of priority multiplied by effort, the effort is small compared with the benefits of making this first class. I don't see why we shouldn't put effort into it.
eholk: `AsyncIterator` is a way that we can add real tangible value to users quickly. Having a win like that would be great.
tmandry: It's fairly easy for us. Generators are not that far off and it'd be a huge win. I'm a little less sure about `for await`. We should start experimenting.
eholk: Rust has so many features that are 95% done. That's almost a cultural problem. It'd be nice to take a small step here to change that culture.
CE: I'd say that cultural problem is a mischaracterization. A lot of these features have really hard decisions. The cultural problem is that we don't decide them. That's not the case for `async gen` though. There, someone needs to just sit down and do it.
TC: We're also commonly making tradeoffs between, "should we do this the way we can do it now and deliver value immediately?" or "should we wait and maybe be able to do it better later?". Often we can imagine how some thing could be done better, and that in itself can block us from stabilizing what we have today.
(The meeting ended here.)
Sign in with Wallet
