Update on await syntax in Rust • Hacker News Board

Re: Update on await syntax in Rust

#71

Post by Nican » Tue, May 28, 2019, 5:18 PM UTC

kbenson wrote: post #18

CJefferson wrote: post #2

I'm nit going to stop using rust, but I find this very disappointing. One thing I strongly disagree with - - this article said other notations would require Rust users having to learn more notation. This still requires learning more notation, just it's easy to not even be aware it exists and think a struct had a member called await instead...

My understanding of the issue (which is shallow at best) is that it's a battle between a prefixing keyword or sigil which has the problem of causing the reader to scan back and forth in the statement when chaining multiple items, which sucks), or a postfixing keyword or sigil, with dot notation for a keyword to help parsing (and everyone seems to dislike the overloading of the dot notation for this). Ignoring sigils,…

For example, on C#, I sometimes have to do:

  var value = (await (await startRequest()).GetBody()).Root;

While the Rust syntax would make this a little more clear, I do not think it is a dealbreaker.

Re: Update on await syntax in Rust

#72

Post by deskamess » Tue, May 28, 2019, 5:18 PM UTC

kbsletten wrote: post #26

seanalltogether wrote: post #16

Question for people more familiar with async/await semantics, how do you typically control what thread the async procedure runs on? Having spent a lot of time now in rxJava and really getting into the power of stream processing and composition, it feels like async/await is almost too simplistic.

In C#, your tasks are submitted to the ambient task scheduler. In ASP.NET, this is (I believe) the main thread pool that handles requests. The only time I've ever had to care where something was running is when adding response headers because that's available as a thread local API that can't happen on another thread, but it's generally ended up as a "it hurts when I do this " kind of situation.

ConfigureAwait(false) may help if you want it to run "not in the current context". Has UI/library use cases [1].

https://medium.com/bynder-tech/c-why-you-should-use-configur...

Re: Update on await syntax in Rust

#73

Post by burke » Tue, May 28, 2019, 5:23 PM UTC

CJefferson wrote: post #2

I'm nit going to stop using rust, but I find this very disappointing. One thing I strongly disagree with - - this article said other notations would require Rust users having to learn more notation. This still requires learning more notation, just it's easy to not even be aware it exists and think a struct had a member called await instead...

Yeah this argument doesn't hold water for me either. Learning new notation versus learning a special-cased exception to the normal semantics of an existing piece of notation feel like really comparable levels of cognitive overhead to me.

I don't think this is necessarily a bad choice overall but I find this particular line of reasoning a bit specious.

Re: Update on await syntax in Rust

#74

Post by eximius » Tue, May 28, 2019, 5:25 PM UTC

Thaxll wrote: post #68

I'm not familiar with Rust, someone can explains why they went with .await? Is await a field / method on a class / struct?

None of the above. It's compiler magic. It's a keyword that says 'await on this awaitable object' (currently only a Future can be await-ed).

You can read the OP which contains links to more blog posts on the reasoning. I think this is a bad decision precisely because of the questions you're asking. At least making it a 'magic method' (i.e., Future::await(...) or future.await()) with no implementation would have been better in basically every way. A 'dot' operator already exists and this just makes it confusing.

Re: Update on await syntax in Rust

#75

Post by jcelerier » Tue, May 28, 2019, 5:25 PM UTC

Nican wrote: post #71

kbenson wrote: post #18

Earlier quoted context omitted.

My understanding of the issue (which is shallow at best) is that it's a battle between a prefixing keyword or sigil which has the problem of causing the reader to scan back and forth in the statement when chaining multiple items, which sucks), or a postfixing keyword or sigil, with dot notation for a keyword to help parsing (and everyone seems to dislike the overloading of the dot notation for this). Ignoring sigils,…

For example, on C#, I sometimes have to do: var value = (await (await startRequest()).GetBody()).Root; While the Rust syntax would make this a little more clear, I do not think it is a dealbreaker.

this makes my eyes bleed

Re: Update on await syntax in Rust

#76

Post by Macha » Tue, May 28, 2019, 5:25 PM UTC

Thaxll wrote: post #68

I'm not familiar with Rust, someone can explains why they went with .await? Is await a field / method on a class / struct?

Why not JS/C#/Python style `await foo()` is discussed here:

https://paper.dropbox.com/doc/Await-Syntax-Write-Up-t9NlOSeI...

Main points against:

1. Interacts poorly with the ? operator for propagating errors. You'd need to do (await foo())?

2. Chains poorly. `await foo().bar().baz()`

- a. What are you awaiting? foo() or foo().bar().baz()

- b. What if you wanted to await foo().bar()? (await foo().bar()).baz() is messy.

- c. What if you wanted to chain promises? Like httpRequest.send().body() . In many libraries such as Python's requests, the first returns a future for a response with headers and only a later call waits until the body is returned. `await (await httpRequest.send()).body()`

Why not .await() or .await!():

https://boats.gitlab.io/blog/post/await-decision/

Re: Update on await syntax in Rust

#77

Post by eximius » Tue, May 28, 2019, 5:26 PM UTC

ridiculous_fish wrote: post #33

sagichmal wrote: post #22

Earlier quoted context omitted.

You typically don't, as knowing which physical thread you're running in is (thankfully) becoming a relic of the past.

UI programming is one domain where it's important to know this.

Even there, you only care that you aren't running on a particular thread, just NOT on one particular thread. You still pass it to an executor that has it's own thread pool and shouldn't be terribly concerned with the particular thread.

Re: Update on await syntax in Rust

#78

Post by kibwen » Tue, May 28, 2019, 5:26 PM UTC

childintime wrote: post #63

All control flow mechanisms except await have their own statement: if, for, while, match. Howcome await is different? The dot await syntax might hide an await within an expression, as "just another method". You'll need to hunt it down. I feel await has costs and consequences that need to be explicit. The dot syntax does the opposite, and therefore I feel Rust might be making a mistake of a lifetime (pun intended) on…

> All control flow mechanisms except await have their own statement: if, for, while, match. Howcome await is different? The dot await syntax might hide an await within an expression, as "just another method". You'll need to hunt it down.

Not quite; Rust is an expression-favoring language, so `if`, `match`, and even the `loop` keyword can all appear deep within expressions (the first two do so somewhat commonly; the latter is comparatively rare). In addition, the error-handling operator `?` is also used within expressions. (And while we're on the topic, let's remember that even C, a statement-heavy language, also has `?` as a control-flow operator that is not in statement position.)

Re: Update on await syntax in Rust

#79

Post by jcelerier » Tue, May 28, 2019, 5:27 PM UTC

byproxy wrote: post #14

anchpop wrote: post #9

Earlier quoted context omitted.

Syntax may be irrelevant at the end of the day, but nice syntax can make a big difference in usability imo. I'm not following the Rust example, but discussions of it remind me about discussions about UFCS (Universal Function Call Syntax). That's where `foo(a, b)` can be rewritten as `a.foo(b)`. That may seem minor, but look at this code: half_square = divide(square(a), 2) In comparison to: half_square = a.square().di…

Interesting example...I find the first much easier to read and reason about. ¯\_(ツ)_/¯

It would be nice for both of us to get a brain scan while reading that kind of code, because I find the second immensely more intuitive to parse

Re: Update on await syntax in Rust

#80

Post by Touche » Tue, May 28, 2019, 5:28 PM UTC

JoshTriplett wrote: post #29

Pahr3yah wrote: post #10

Earlier quoted context omitted.

Await is a keyword, syntax highlighters will most likely paint it differently.

Speaking as a member of the Rust language team: we specifically evaluated all syntax proposals on the assumption that many people may end up reading them without syntax highlighting. People read code in many places outside of a programmer's text editor or a code-highlighting web page, including logs, diffs, and emails.

Hopefully you didn't make a decision based on some exception use case.