Stream: wg-async-foundations

Topic: website


Florian Gilcher (Nov 05 2019 at 10:44, on Zulip):

Hi, I'd like to update the async examples on the website around the release. I would like to rely only on code supplied by the rust project. will we ship some kind of demo executor or will futures-executor continue to exist?

simulacrum (Nov 05 2019 at 12:58, on Zulip):

to my knowledge we are not currently planning on shipping a demo executor -- there is an open PR on rust-lang/rust to add an unstable one, but it doesn't look like it's going to land at least from my perspective

Florian Gilcher (Nov 05 2019 at 13:15, on Zulip):

Hm. Okay. I'll see how to deal with that.

Florian Gilcher (Nov 05 2019 at 15:35, on Zulip):

Ah, and to be clear, it doesn't need to be in rust libstd.

simulacrum (Nov 05 2019 at 15:54, on Zulip):

(everything not in libstd is sort of unofficial, right?)

simulacrum (Nov 05 2019 at 15:54, on Zulip):

I guess a dummy executor could be built but it'd just loop through all the futures and poll them... pretty simple, but super inefficient and I wouldn't point to it

simulacrum (Nov 05 2019 at 15:55, on Zulip):

maybe something like what runtime was meant to be could work here? or use tokio and async-std side by side? (There are other executors too though :/)

nikomatsakis (Nov 05 2019 at 18:44, on Zulip):

@Florian Gilcher there has been some discussion of including a simple block_on in libstd -- it was discussed here

nikomatsakis (Nov 05 2019 at 18:45, on Zulip):

The need to create standalone examples might be sufficient motivation indeed

Matthias247 (Nov 06 2019 at 07:10, on Zulip):

@nikomatsakis Yes, that thread was for the PR https://github.com/rust-lang/rust/pull/65875 that @simulacrum mentioned

Matthias247 (Nov 06 2019 at 07:16, on Zulip):

@simulacrum

I guess a dummy executor could be built but it'd just loop through all the futures and poll them... pretty simple, but super inefficient and I wouldn't point to it

I would not recommend that. I think it might lead to a few non ideal reactions:
- It gives the impression that async/await is unfinished
- It focusses too much on how Futures work under the hood, and not on what people can do with async/await
- It encourages people to write their own executors. And while that's an interesting thing for learning purposes - it's actually not something we should recommend people to spend their time on. There are already enough simple executors out there.

In doubt I would just use block_on from futures-rs for demo purposes

simulacrum (Nov 06 2019 at 11:39, on Zulip):

Does futures-rs have an executor then? I was under the impression that wasn't the case.

Nemo157 (Nov 06 2019 at 13:26, on Zulip):

Yes, it contains 3 different executors

Nemo157 (Nov 06 2019 at 13:27, on Zulip):

A multi-threaded pool, a single-threaded “pool” and a trivial single-future executor for block_on

simulacrum (Nov 06 2019 at 14:03, on Zulip):

interesting

simulacrum (Nov 06 2019 at 14:03, on Zulip):

that is... surprising to me

boats (Nov 06 2019 at 16:30, on Zulip):

right now examples should use futures::block_on. someday hopefully we'll have a way to block a thread on a future in std, but (in my opinion) we need to gather a bit more feedback around the design of that first.

Florian Gilcher (Nov 06 2019 at 17:26, on Zulip):

K, okay, given the current discussions, I will no accept a code example that uses _any_ ecosystem library on the website.

Last update: Nov 18 2019 at 00:40UTC