Async-await experience reports

Interesting. It doesn’t seem that inconsistent, though… Imagine if you were doing this using threads instead of async. Then next_frame() would return a Condvar or similar type, and the syntax would be something like next_frame().wait(), which is the same order as .await.

(In reality it would be a bit more complicated because condvars need an associated mutex and can have spurious wakeups; a better fit would be an “event” type, but Rust’s standard library doesn’t have one of those. I guess you could use a mpsc::Receiver<()>…)

3 Likes

How long have you been using the .await syntax?

About a week.

What code are you working on?

udoprog/setmod, work being done in a separate branch (async-await) but the port now runs which was my initial goal.

Right now it has 122 uses of .await. Project is 17k LOC.

What environment are you editing the code in?

VS Code, no syntax highlighting for .await.

Summarize what happened

The .await postfix syntax had almost no impact in terms of weirdness for me. Interactions with it felt very intuitive after a short period of time (a couple of hours). I was initially in the await!(...) macro camp but this is experience has taught me how nice .await is. The biggest win for me is that there’s no need to break up existing code when you introduce new async functions in a call chain which leads to cleaner patches.

The biggest issue is that async blocks and functions suffer from rather scary diagnostics when something goes wrong. I faced lifetime issues from forgetting to move things appropriately into the block or function. This is the patch that fixes it in my project.

Futures not being Send due to something !Send leaking across awaits is another thing that has unhelpful diagnostics. This is the patch that fixes it in my project.

How to work with 0.1 <-> 0.3 compatibility needs more examples and should be visible on docs.rs. For reference, this is available on the privately hosted documentation.

Background information

Rust user for 3 years. I do a programming stream and users on stream didn’t express confusion with the syntax once explained.

14 Likes

How long have you been using the .await syntax?

On and off playing with it since it became available in nightly, only one real but tiny project.

What code are you working on? How many lines of code? How complex? How old is the codebase?

A small service used in house not facing the internet for some UDP packet processing. Currently only 2100 lines of code. I previously wrote it using “stable” future syntax, now converted to .await

Otherwise just experimenting and for personal stuff.

What environment are you editing the code in? Do you have .await syntax highlighting?

Vim, no highlighting yet, maybe it’s already available, I didn’t bother yet to search.

Summarize what happened, both the good and the bad.

I’m really pleasantly surprised! The code using the .await syntax feels more easy to read and understand, even without syntax highlighting. I added a blank line here and there to catch the attention, but I expect that with highlighting the await points will be quick to spot in any way.

I feel that I very quickly got accustomed to await being a new keyword, and the .await syntax feels all fine, I never stumbled upon a thought like “oh wait, this looks like a field, but is it really?”

Guessing from how quickly I got accustomed with .await I strongly feel that it is the way to go!

Compiler error messages can improve, as always. I can’t say whether the error messages were more or less helpful compared to current “stable-style” futures.

I really enjoy using .await

18 Likes

How long have you been using the .await syntax?

A couple of days ago I converted two of my crates from await!() to .await.

What code are you working on?

webdav-handler and webdav-server

What environment are you editing the code in?

vim

How the new syntax feels over time.

Before I used it I thought that suffix dot-await was a brilliant idea. However it only really shines when chaining. In other places it feels kind of weird.

For example:

-    match await!(dav_if_match(req, fs, ls, path)) {
+    match dav_if_match(req, fs, ls, path).await {

Here, visually, I’d prefer

match await dav_if_match(req, fs, ls, path) {

Similar for while let Some(value) = await stream.next() etc

I will probably get used to it.

15 Likes
1 Like

I noticed that this thread became quiet about 25 days ago. There has been a single report in the last 14 days. Until that point, the reports were from people who had used the new syntax for “about a week” or “a few days”.

Coupled with the post about testing needed for async/await, it sounds to me like the feature should bake for a few releases — enough time so that people can really try it out in practice.

“Bake for a few releases” could be made more concrete by finding one or more big projects that currently use await!(), and then wait until they’ve updated their code to use .await. If they don’t see the claimed benefits of chaining .awaits, well then perhaps the syntax isn’t actually doing what people hoped it would do.

3 Likes