or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
![image alt](https:// "title") | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | Emoji list | ||
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Syncing
xxxxxxxxxx
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
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 (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!
andFuturesUnordered
as well as the lack of portable libraries and idioms that work uniformly across runtimes.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:
We will establish these facts through several documents:
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, 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…
…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", 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:
foo.await
call doesn't go into the runtimeThe 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, 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:
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
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
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:
Dates and times
- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →.box
syntax- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →- The image file may be corrupted
- The server hosting the image is unavailable
- The image path is incorrect
- The image format is not supported
Learn More →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 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 likewith
-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 preludeasync Struct
notation (related to theasync Trait
stuff)nikomatsakis:
IntoFuture
sureYosh: Should regular types which have async methods need to include
async
or?async
in their name? We've also considered changingconst 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
orfn async read_to_stream
for consistency withtrait async Read
?Topic
name: prompt