Stream: wg-async-foundations

Topic: priorities for 2020


tmandry (Jan 07 2020 at 19:12, on Zulip):

ok, I'm going to put some of my thoughts here

tmandry (Jan 07 2020 at 19:16, on Zulip):

there's.. a lot we can work on :)

tmandry (Jan 07 2020 at 19:20, on Zulip):

On the implementation side, overall categories I came up with were

On the lang/libs side, we have things like

tmandry (Jan 07 2020 at 19:21, on Zulip):

I guess documentation can go in either category

tmandry (Jan 07 2020 at 19:22, on Zulip):

I'm sort of trying to differentiate between "things we can do now" vs "things that need design discussions"

tmandry (Jan 07 2020 at 19:22, on Zulip):

and trying to focus more on the former, for now

tmandry (Jan 07 2020 at 19:24, on Zulip):

First and foremost, I think we should be making async/await easier to use

tmandry (Jan 07 2020 at 19:24, on Zulip):

that includes Diagnostics and Documentation above, as well as Debugging

tmandry (Jan 07 2020 at 19:28, on Zulip):

we should probably set aside some time to take stock of the async book, and what the state of the overall documentation is

tmandry (Jan 07 2020 at 19:28, on Zulip):

diagnostics is clearly ongoing, and we're making great progress there

tmandry (Jan 07 2020 at 19:29, on Zulip):

as for debugging

tmandry (Jan 07 2020 at 19:32, on Zulip):

there's some discussion within Fuchsia about doing a deep integration with our debugger, and I think that would be a good place to prototype the interfaces

tmandry (Jan 07 2020 at 19:34, on Zulip):

that will likely involve work in both the compiler and (eventually) in a standard interface for executors, so it kind of straddles both

tmandry (Jan 07 2020 at 19:35, on Zulip):

but even if it has longer lead time, I think it's definitely worth putting some effort into this in 2020

tmandry (Jan 07 2020 at 19:36, on Zulip):

Performance

tmandry (Jan 07 2020 at 19:36, on Zulip):

we should focus on the lowest hanging fruit here first, of course

tmandry (Jan 07 2020 at 19:38, on Zulip):

in particular I'd really like to fix #62958 "Async fn doubles argument size"

tmandry (Jan 07 2020 at 19:38, on Zulip):

and I also think we need more benchmarks for async/await code, to catch compiler performance regressions

tmandry (Jan 07 2020 at 19:39, on Zulip):

those two are my top priorities here, I think

tmandry (Jan 07 2020 at 19:39, on Zulip):

beyond that, I think there's ample room to improve performance

tmandry (Jan 07 2020 at 19:41, on Zulip):

e.g. in the generator implementation, one idea is to replace the switch on the generator state with a PC to jump to directly

tmandry (Jan 07 2020 at 19:41, on Zulip):

it would be nice if we could do this in a way that requires only a single jump for a deeply nested state machine

tmandry (Jan 07 2020 at 19:41, on Zulip):

but I'm getting ahead of myself :)

tmandry (Jan 07 2020 at 19:42, on Zulip):

this isn't as important as anything I mentioned above

tmandry (Jan 07 2020 at 19:43, on Zulip):

Language features

tmandry (Jan 07 2020 at 19:43, on Zulip):

this one is a little hazier to me

tmandry (Jan 07 2020 at 19:44, on Zulip):

GATs interacts with the traits wg, and is probably more "their thing"

tmandry (Jan 07 2020 at 19:45, on Zulip):

my primary interest here is in enabling prototyping for the most important language features

tmandry (Jan 07 2020 at 19:45, on Zulip):

since those already have a longer lead time, we should think about anything we can do on the implementation side to reduce that

tmandry (Jan 07 2020 at 19:46, on Zulip):

--
okay.. I think I'm going to leave it there for now

tmandry (Jan 07 2020 at 19:47, on Zulip):

still need to talk about the lang/libs side, at some point

tmandry (Jan 07 2020 at 19:48, on Zulip):

cc @nikomatsakis, any thoughts to add?

tmandry (Jan 07 2020 at 19:50, on Zulip):

(rhetorical question.. I'm sure you do :smile:)

centril (Jan 07 2020 at 20:26, on Zulip):

Language features

I think we shouldn't be having new RFCs or even work on async closures until most of the existing work is finished, that is, the bugs

tmandry (Jan 07 2020 at 22:07, on Zulip):

yes, I forgot to include bug fixes as an explicit category

tmandry (Jan 07 2020 at 22:07, on Zulip):

but agreed that those should be the highest priority

nikomatsakis (Jan 08 2020 at 19:39, on Zulip):

A few thoughts

nikomatsakis (Jan 08 2020 at 19:40, on Zulip):

First of all, I think we should stabilize the Stream, AsyncRead, and AsyncWrite traits, perhaps in that order. I've been talking to various folks and I think there's a fairly clear picture forming.

nikomatsakis (Jan 08 2020 at 19:41, on Zulip):

I've also been forming a plan around GATs but I think that's more for #wg-traits, as you said.

nikomatsakis (Jan 08 2020 at 19:42, on Zulip):

I guess I agree with almost everything you wrote @tmandry -- diagnostics are definitely a huge point that I think comes up fairly regularly. I've not heard many complaints about performance.

nikomatsakis (Jan 08 2020 at 19:42, on Zulip):

I've also been forming a plan around GATs but I think that's more for #wg-traits, as you said.

I think another lang feature that could tangentially be quite helpful, but which doesn't likely belong in "this group", is stabilizing and improving more parts of the impl Trait story

tmandry (Jan 08 2020 at 19:44, on Zulip):

First of all, I think we should stabilize the Stream, AsyncRead, and AsyncWrite traits, perhaps in that order. I've been talking to various folks and I think there's a fairly clear picture forming.

Do you have a plan to stabilize Stream without some form of GATs, or is it blocked on that?

Steven Fackler (Jan 08 2020 at 19:53, on Zulip):

IMO Stream would just be the async equivalent of Iterator, and GATs would allow the introduction of new StreamingIterator/StreamingStream in the future.

nikomatsakis (Jan 08 2020 at 21:24, on Zulip):

What @Steven Fackler said, basically

centril (Jan 08 2020 at 21:25, on Zulip):

I think another lang feature that could tangentially be quite helpful, but which doesn't likely belong in "this group", is stabilizing and improving more parts of the impl Trait story

(I agree, but this is blocked on fixing a lot of bugs and fully implementing the feature however. ^^)

nikomatsakis (Jan 08 2020 at 21:25, on Zulip):

( also cc @boats on this topic )

nikomatsakis (Jan 08 2020 at 21:26, on Zulip):

IMO Stream would just be the async equivalent of Iterator, and GATs would allow the introduction of new StreamingIterator/StreamingStream in the future.

to elaborate on this, I think a guiding principle should be that the sync/async traits basically mirror one another, and that fits well in both of these cases

centril (Jan 08 2020 at 21:27, on Zulip):

Well... the std::io::Readtrait is problematic in some respects, so I'm not fully sure that they must match (but that's a separate topic)

boats (Jan 08 2020 at 21:50, on Zulip):

I would also add block_on to the libs changes

boats (Jan 08 2020 at 21:51, on Zulip):

And IMO there are a few very small new language features that are worth doing short term (mainly async drop)

Steven Fackler (Jan 09 2020 at 00:45, on Zulip):

I would be interested in some work on task locals. I imagine they could be implemented via a field in Context

nikomatsakis (Jan 09 2020 at 21:03, on Zulip):

And IMO there are a few very small new language features that are worth doing short term (mainly async drop)

I was going to ask about async drop

tmandry (Jan 14 2020 at 03:16, on Zulip):

I put out a call for feedback from Fuchsia devs today. Here are the things that were echoed multiple times:

Some of these are known, but some were new to me.

Other things that were mentioned:

tmandry (Jan 14 2020 at 03:17, on Zulip):

Also, thanks for all the feedback

tmandry (Jan 14 2020 at 03:18, on Zulip):

We probably need a way to track all of these and assign priorities

tmandry (Jan 14 2020 at 03:18, on Zulip):

And produce a sort of "async roadmap" with the guiding themes, perhaps?

Giles Cope (Jan 14 2020 at 18:00, on Zulip):

My pipe dream for async/await is a Stream created from an async fn that has some sugar that yields.
Short term I suspect as everyone spinal tap's async/await and turns it up to 11, we will see calls to minimise any memory size overheads.

nikomatsakis (Jan 14 2020 at 18:17, on Zulip):

@tmandry that's quite interesting -- particularly the "capture list" part, I had not heard that

nikomatsakis (Jan 14 2020 at 18:17, on Zulip):

might be nice to have an example

nikomatsakis (Jan 14 2020 at 18:17, on Zulip):

I'm reminded that I want to create a wg-async-foundations repository

nikomatsakis (Jan 14 2020 at 18:17, on Zulip):

and start to create pages that talk about these sorts of things to help catalog requirements and constraints

tmandry (Jan 14 2020 at 20:04, on Zulip):

I'm reminded that I want to create a wg-async-foundations repository

yeah, I was thinking the same

tmandry (Jan 14 2020 at 20:09, on Zulip):

might be nice to have an example

the example of something that comes up a lot was

let item = Arc::...;
let item2 = item.clone();
call_fn(async move || { item2... });
item...
tmandry (Jan 14 2020 at 20:11, on Zulip):

(except we don't allow async closures in our tree, but you get the idea)

tmandry (Jan 14 2020 at 20:12, on Zulip):

I've also seen cases where some vars wanted to be captured by [mutable] reference and some by value

tmandry (Jan 14 2020 at 20:17, on Zulip):

but I'm not sure how common those are

tmandry (Jan 14 2020 at 20:20, on Zulip):

sometimes you can do this implicitly, but it can be hard to follow what's going on

tmandry (Jan 14 2020 at 20:23, on Zulip):

so I guess there's (1) removing clone boilerplate and (2) making capture semantics more explicit, easier to follow/control

tmandry (Jan 14 2020 at 20:23, on Zulip):

the person who brought up (2) was new to Rust and async/await. it might be a learning curve thing and figuring out the right idioms

tmandry (Jan 14 2020 at 20:24, on Zulip):

but personally, there is a level of implicitness in the capture semantics that sometimes makes me uncomfortable. :)

Matthias247 (Jan 15 2020 at 03:33, on Zulip):

Thanks for doing the research and asking for feedback @tmandry !

nikomatsakis (Jan 21 2020 at 18:38, on Zulip):

The pattern I generally use for capture clauses is to replace a closure expression with

{
    let x = x.clone(); // one line per variable I want to "declare"
    let y = &y; // borrow y by shared ref
    let z = z; // take ownership of `z`
    move || {...}
}

but while this sometimes strikes me as "elegant", it seems clear that most people don't think of it (or perhaps don't care for it), and that it might be nice to have some explicit syntax for declaring what you will capture (plus nothing guarantees that you only capture the variables listed there, which is maybe suboptimal.

nikomatsakis (Jan 21 2020 at 18:45, on Zulip):

Anyway, zooming out, did anybody here create a big list of thoughts? One list I made was the one I used for [the "async interviews script"](https://gist.github.com/nikomatsakis/ae2ede32c4c7d49cbda088a1539724d9, though it's a bit incomplete now

tmandry (Jan 21 2020 at 18:46, on Zulip):

I did not

nikomatsakis (Jan 21 2020 at 18:46, on Zulip):

I think that from my POV the things I would put atop the list would be

nikomatsakis (Jan 21 2020 at 18:48, on Zulip):

Why those things? Well, the first ones because they seem to be pretty major candidates for enabling more interop, and because I think the discussions at this point are pretty far along.

nikomatsakis (Jan 21 2020 at 18:49, on Zulip):

The second one because it's the most common complaint :) though it'd be good to maybe drill in more on just what it means

centril (Jan 21 2020 at 18:50, on Zulip):

not sure async-drop is small btw

nikomatsakis (Jan 21 2020 at 18:50, on Zulip):

I'm not sure about the final line, I guess it depends how much energy goes into it, but it seems like it closes some known shortcomings and I wouldn't expect a lot of controversy there

nikomatsakis (Jan 21 2020 at 18:51, on Zulip):

Agreed, I'm not entirely clear about async-drop's size. e.g., there is the idea of generalizing a bit to #wg-async-foundations > Async Lifecycles, though I've not yet read most of the comments in that topic :)

centril (Jan 21 2020 at 18:51, on Zulip):

IntoFuture was legitimately classified as small cause the actual code changes were trivial and the open questions basically none (except bikeshed on type Output but that was resolved quickly thankfully)

tmandry (Jan 21 2020 at 18:53, on Zulip):

Agreed that we should be prioritizing things that improve interop, especially the easy ones :)

tmandry (Jan 21 2020 at 18:54, on Zulip):

And I think that diagnostics/ease of use are really important

tmandry (Jan 21 2020 at 18:54, on Zulip):

I think it's unclear to me how much effort needs to go into documentation / async book, though

tmandry (Jan 21 2020 at 18:54, on Zulip):

it's at least "some"

tmandry (Jan 21 2020 at 18:54, on Zulip):

but I don't think we have a good way of tracking work like that

nikomatsakis (Jan 21 2020 at 18:54, on Zulip):

I think it's unclear to me how much effort needs to go into documentation / async book, though

Yes, I think this is a good question

tmandry (Jan 21 2020 at 18:55, on Zulip):

(which reminds me, we should get a github repo set up for the wg)

nikomatsakis (Jan 21 2020 at 18:55, on Zulip):

One question is what our "goal" should be there, to some extent

centril (Jan 21 2020 at 18:56, on Zulip):

I actually don't think we should be prioritizing interop right now, while bugs still exist

centril (Jan 21 2020 at 18:56, on Zulip):

we essentially stabilized with a bunch of bugs open, which have to be paid off

tmandry (Jan 21 2020 at 18:57, on Zulip):

agreed that fixing bugs is higher priority, in general

centril (Jan 21 2020 at 18:57, on Zulip):

(basically, going forward, I think our policy should be that a feature has zero bugs before it can be stabilized)

nikomatsakis (Jan 21 2020 at 18:58, on Zulip):

I guess it all depends on what one defines as a bug

nikomatsakis (Jan 21 2020 at 18:58, on Zulip):

but I don't think that's very practical nor especially desirable

centril (Jan 21 2020 at 18:58, on Zulip):

well ICEs are included for sure

centril (Jan 21 2020 at 18:58, on Zulip):

crashes also

nikomatsakis (Jan 21 2020 at 18:58, on Zulip):

I guess I'm curious which open bugs you think we should be emphasizing, @centril?

centril (Jan 21 2020 at 18:58, on Zulip):

and soundness holes

nikomatsakis (Jan 21 2020 at 19:00, on Zulip):

That is, I think most of the cases we're concerned about at this point are either diagnostic failures or cases where we are more conservative than we would like. I do think we should work to fix them, but they don't strike me as things that automatically take priority over concerns around fostering a healthy ecosystem. In any case i'm not sure how much of an either-or proposition it is, though I think it may be at least somewhat. =)

tmandry (Jan 21 2020 at 19:01, on Zulip):

Yeah, it's useful to draw a distinction around the overly conservative parts for sure

tmandry (Jan 21 2020 at 19:01, on Zulip):

I put those in basically the same category as diagnostics, because they make the feature harder to use

nikomatsakis (Jan 21 2020 at 19:02, on Zulip):

"Ergonomics", to some extent

centril (Jan 21 2020 at 19:02, on Zulip):

There are some non-diagnostic ICEs remaining, and hacks we added around e.g. Self

nikomatsakis (Jan 21 2020 at 19:02, on Zulip):

I don't remember, are those ICEs now?

nikomatsakis (Jan 21 2020 at 19:02, on Zulip):

( I thought they were controlled errors )

centril (Jan 21 2020 at 19:04, on Zulip):

the issue tracker suggests there are non-diagnostic ICEs at least

centril (Jan 21 2020 at 19:04, on Zulip):

going on labels

nikomatsakis (Jan 21 2020 at 19:05, on Zulip):

Oh, I see, I misinterpreted your comment as suggesting that the "hacks we added" and "non-diagnostic ICEs" were the same thing

nikomatsakis (Jan 21 2020 at 19:07, on Zulip):

I am pondering :) I do think it's important that we continue polish work -- I am bridling somewhat at the thought of putting further progress on Stream/Async* on hold -- but I'm wondering if I am being unwise.

nikomatsakis (Jan 21 2020 at 19:07, on Zulip):

I guess in general I think we should do some of both

centril (Jan 21 2020 at 19:07, on Zulip):

to be clear, I'm mostly thinking of compiler/lang things here

nikomatsakis (Jan 21 2020 at 19:07, on Zulip):

That is, continue making progress on things that the ecosystem needs to expand, while polishing what we have. But do we have the bandwidth to pull them both off? That is a key question

nikomatsakis (Jan 21 2020 at 19:07, on Zulip):

I would be inclined to take, however, modest steps

nikomatsakis (Jan 21 2020 at 19:07, on Zulip):

Which is why I've not mentioned things like generator syntax

centril (Jan 21 2020 at 19:08, on Zulip):

like if there are pure libs improvements that improve ergonomics then why not do it in parallel

nikomatsakis (Jan 21 2020 at 19:08, on Zulip):

And also why I suggested the 3 traits I did, as I think that a lot of the questions there are fairly well understood at this point

nikomatsakis (Jan 21 2020 at 19:08, on Zulip):

to be clear, I'm mostly thinking of compiler/lang things here

I see

nikomatsakis (Jan 21 2020 at 19:08, on Zulip):

wel, indeed, those things are purely libs :)

tmandry (Jan 21 2020 at 19:09, on Zulip):

not sure about bandwidth, to some extent I think we can parallelize (e.g. not all people are involved in both)

nikomatsakis (Jan 21 2020 at 19:09, on Zulip):

(and, further, on my list has been to talk to the libs team more about those next steps, since I think I would want to do it in concert with them)

centril (Jan 21 2020 at 19:09, on Zulip):

Although there might be libs things that want to wait on lang things, but well, the things they want to wait on will not be done tomorrow ^^

tmandry (Jan 21 2020 at 19:09, on Zulip):

I'm also inclined to do both btw

tmandry (Jan 21 2020 at 19:09, on Zulip):

but we should figure out what the bottlenecks are going to be

nikomatsakis (Jan 21 2020 at 19:09, on Zulip):

I think we should be able to parallelize, yes... as I said, I was thinking of that when I drew up that list

tmandry (Jan 21 2020 at 19:09, on Zulip):

(or try?)

nikomatsakis (Jan 21 2020 at 19:10, on Zulip):

but it's also true that it's not entirely clear to me who will be doing what -- it feels like we have to grow the "bench" somewhat

tmandry (Jan 21 2020 at 19:11, on Zulip):

yeah, I was trying to find a list of people on the wg, and failing :)

centril (Jan 21 2020 at 19:11, on Zulip):

And also why I suggested the 3 traits I did, as I think that a lot of the questions there are fairly well understood at this point

Have we figured out what to do with the fact that &mut [u8] provided an uninitialized slice is UB? (https://github.com/rust-lang/unsafe-code-guidelines/issues/77)

tmandry (Jan 21 2020 at 19:11, on Zulip):

even though I know who's been involved lately

nikomatsakis (Jan 21 2020 at 19:13, on Zulip):

Have we figured out what to do with the fact that &mut [u8] provided an uninitialized slice is UB?

depends on who you ask :) but I think we've worked out most of the tradeoffs, and I also think that the problem is one that is best solved in concert with the work on sync Read trait; @Steven Fackler is working on a proposal, you can read about it in #t-libs > Read + uninit memory I think

nikomatsakis (Jan 21 2020 at 19:13, on Zulip):

yeah, I was trying to find a list of people on the wg, and failing :)

I've been trying to get more formal about these sorts of things, I'll ping you, let's fix up the teams repo

tmandry (Jan 21 2020 at 19:14, on Zulip):

One question is what our "goal" should be there, to some extent

I guess the ideal case would be a natural addendum to the Rust book

centril (Jan 21 2020 at 19:17, on Zulip):

Is the separate book strategy not working?

tmandry (Jan 21 2020 at 19:18, on Zulip):

not actually being added, but the standards of quality it would imply

centril (Jan 21 2020 at 19:18, on Zulip):

oh

nikomatsakis (Jan 21 2020 at 19:18, on Zulip):

well

tmandry (Jan 21 2020 at 19:18, on Zulip):

(sorry, unclear)

tmandry (Jan 21 2020 at 19:18, on Zulip):

but maybe that's just not feasible

tmandry (Jan 21 2020 at 19:18, on Zulip):

given limited resources :)

centril (Jan 21 2020 at 19:18, on Zulip):

I think it's a matter of time

centril (Jan 21 2020 at 19:18, on Zulip):

the book didn't get polished over night

nikomatsakis (Jan 21 2020 at 19:18, on Zulip):

ps one other question is maintinance and strategy around futures-rs, I'm not really sure who the maintainers there are besides @Taylor Cramer, though I tknow there are folks

nikomatsakis (Jan 21 2020 at 19:20, on Zulip):

re: the book, I think the level of quality is not the concern so much as the "table of contents" -- like, what is the focus going to be, etc, but I think that's a process that is not going to get solved in this meeting at this second.

nikomatsakis (Jan 21 2020 at 19:20, on Zulip):

still, I think it should go on a list of "things to work out"

nikomatsakis (Jan 21 2020 at 19:21, on Zulip):

I think also a good question is "what is the role of doc from frameworks like tokio, async-std, bastion etc" -- i.e., maybe our goal should be to help people get started, and direct to other frameworks for the detailed questions that go beyond libstd

tmandry (Jan 21 2020 at 19:21, on Zulip):

ah okay, I was thinking more of polish / making it more accessible, and adding any obvious missing pieces

nikomatsakis (Jan 21 2020 at 19:22, on Zulip):

but I do think the existing material is very good -- i.e., covering how the model works etc

nikomatsakis (Jan 21 2020 at 19:23, on Zulip):

ah okay, I was thinking more of polish / making it more accessible, and adding any obvious missing pieces

I'm not sure if this is different than what I said :) maybe I'm just reflecting my own uncertainty a bit

tmandry (Jan 21 2020 at 19:23, on Zulip):

I like the idea of offloading non-std stuff to frameworks :)

nikomatsakis (Jan 21 2020 at 19:24, on Zulip):

one other thing btw that was not on my list but which may fall in the "small, actionable improvements" is things like extending libstd to include an async mutex and other small utilities

nikomatsakis (Jan 21 2020 at 19:25, on Zulip):

these are all libs-oriented changes, though

Lucio Franco (Jan 21 2020 at 21:17, on Zulip):

I may have missed this and sorry for being late to this convo, but is there mention of type_alias_impl_trait as being grouped in a thing that might want to be prioritized along with GAT/wg-traits stuff? I know this would be incredibly useful for tower.

centril (Jan 21 2020 at 22:01, on Zulip):

I think type_alias_impl_trait is an important feature to work on, but it's also full of bugs. It will take much work to fix it, but @Aaron Hill has been doing some of that

Aaron Hill (Jan 21 2020 at 22:05, on Zulip):

I think there's still some design work that needs to be done as well. The current 'must be a fully generic use in defining scope' limitation isn't great

Aaron Hill (Jan 21 2020 at 22:05, on Zulip):

I'm not sure what the best solution is, though

centril (Jan 21 2020 at 22:05, on Zulip):

@Aaron Hill that's only about allowing more code?

Aaron Hill (Jan 21 2020 at 22:06, on Zulip):

yeah - I meant in terms of it being ready for stabilization

Last update: Jan 28 2020 at 01:50UTC