Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A final proposal for Rust await syntax

boats.gitlab.io

Post reply on HN
Print view View original

41–50 of 265 posts

Re: A final proposal for Rust await syntax

#41

Post by blattimwind »

cyphar wrote: post #16

Super excited to see async/await finally get close to MVP and landing. I am not a huge fan of ".await", but there isn't much more to be said -- my personal preference of "#await" or "@await" does look like line-noise and I think there's no perfect answer to this one (await{} was too messy and no better than prefix-await, and (await foo))? had too many brackets). I also appreciate that this proposal was insanely bike-…

Wouldn't "await expr" or "await@expr" (if you hate whitespace) make more sense compared to "expr await"?

    let db_conn = await pool.connect()
(Which is what e.g. Python uses, with the downside that you tend to need to parenthize more because await has very low precedence).

vs

    let db_conn = pool.connect() await
.await is not soo bad, kinda method-y

    let db_conn = pool.connect().await

Re: A final proposal for Rust await syntax

#42

Post by zzzcpan »

jerf wrote: post #30
wbl wrote: post #28

Earlier quoted context omitted.

From what I've seen of Scheme they dont have this problem. Everyone implemented the feature they want or forks an implementation. And no one argues about syntax.

"And no one argues about syntax." No one argues about the syntax, because everybody "wins" and gets their own syntax as a result, which is often held up as a key part of the explanation for why the Lisp family languages are wonderful and fun and mind-expanding and just awesome in every way... yet rarely escape from "niche" status and are yet to even threaten to break into the really top-tier languages. Because langua…

Fragmentation cannot really be an issue for adoption, as it happens after adoption.

Re: A final proposal for Rust await syntax

#43

Post by neilv »

wbl wrote: post #28
jerf wrote: post #25

"It has also devolved into a situation in which many commenters propose to reverse previous decisions about the design of async/await on which we have already established firm consensus, or otherwise introduced possibilities we have considered and ruled out of scope for now. This has been a major learning experience for us: one of the major goals of the “meta” working group will be to improve the way groups working o…

From what I've seen of Scheme they dont have this problem. Everyone implemented the feature they want or forks an implementation. And no one argues about syntax.

There is some hearty discussion in the Scheme community about syntax, but less than in some other communities. Part of the reason might be that most new syntax looks like this, with no changes to the language grammar:

    (my-new-syntax-name arbitrary other stuff goes here)
Related to this, some things that would have to be primitives in many other languages can be implemented nicely by anyone as ordinary libraries in Scheme.

Re: A final proposal for Rust await syntax

#45

Post by foota »

wtetzner wrote: post #36
foota wrote: post #32

It seems they've settled on using a postfix approach. I can't help but feel this is a mistake. Rust is already a weird language to come to from the likes of python, Java, or Javascript, and it feels to me like this relatively unknown approach of putting the operator at the end is a mistake that will add another confusing aspect of the language. I feel like the committee has worried about the wrong things when conside…

> Rust is already a weird language to come to from the likes of python, Java, or Javascript I think that's a great reason to evaluate new syntax/features on how they will be used, as opposed to how they will attract (or not) new users. New users are already going to be expecting things to be different, and so making this one thing more familiar probably won't make much difference. On the other hand, code lives for a…

While that's true on an individual basis you can't use that continually to introduce differences, because at some point if someone comes to rust and sees a heap of weirdness they're going to be less likely to adopt the language. I'm mostly a bystander since I've written some rust but not very much, but I think rust is neat and I don't want it to become an esoteric language.

Re: A final proposal for Rust await syntax

#46

Post by syn_rst »

james-mcelwain wrote: post #6

Really don't like the magic field access syntax.

I don't really like it either, but the "future use for expression-oriented operators" aspect makes it easier to swallow. I'd rather deal with some slightly odd notation that accurately represents what's going on than have a bunch of different syntactic constructs for different postfix operations.

Re: A final proposal for Rust await syntax

#47

Post by giornogiovanna »

foota wrote: post #32

It seems they've settled on using a postfix approach. I can't help but feel this is a mistake. Rust is already a weird language to come to from the likes of python, Java, or Javascript, and it feels to me like this relatively unknown approach of putting the operator at the end is a mistake that will add another confusing aspect of the language. I feel like the committee has worried about the wrong things when conside…

Literally everyone else uses prefix await, so this will be a problem. But,

- this is a lot easier to chain, which is very useful, and

- the "future expansion" might bring a prefix await anyway (although introducing two syntaxes for the same thing might be even worse).

I'd prefer "f await" to "f.await" because it feels a lot less magical and lets me stick to my intuition that "." is just for stuff implemented by the library, but maybe that's just me.

Re: A final proposal for Rust await syntax

#48

Post by mklein994 »

The syntax feels a bit Ruby-ish, doesn't it? Here's an example from the article of how they could expand the syntax in the future:

  foo.bar(..).baz(..).match {
    Variant1 => { ... }
    Variant2(quux) => { ... }
  }
Compared to some Ruby:

  5.times {
    puts "Hello world!"
  }
Note I'm by no means an expert in Ruby or Rust, this is just what I thought of when I saw the syntax.

Re: A final proposal for Rust await syntax

#49

Post by saghm »

jules wrote: post #13

The designers of Kotlin also had an interesting point: await (synchronous call) should be the default, non-awaited (asynchronous) code should have a keyword indicating that it is async.

It's worth pointing out that `await` is only needed in functions explicitly marked as async; `await` is the default for non-async functions (which is the default mode for a function to operate). I think the rationale behind this is that it's fairly common to need to group a bunch of async operations together, and this is easier to do if you can mark an entire function as async rather than needing to mark individual statements.

Re: A final proposal for Rust await syntax

#50

Post by albru123 »

Twisol wrote: post #38
foota wrote: post #32

It seems they've settled on using a postfix approach. I can't help but feel this is a mistake. Rust is already a weird language to come to from the likes of python, Java, or Javascript, and it feels to me like this relatively unknown approach of putting the operator at the end is a mistake that will add another confusing aspect of the language. I feel like the committee has worried about the wrong things when conside…

For what it's worth, it seems that Rust isn't alone here. C# 8.0 introduced postfix `switch` expressions ( https://devblogs.microsoft.com/dotnet/do-more-with-patterns-... ), which are along the same lines of what's suggested for `match` in Rust further along in the OP. I agree that it looks strange at first. But I think I'll get used to it.

Thanks for pointing this out, I had no idea they implemented this for C# 8.0

Also is it just me or the switch pattern really is inspired by Rust match?

Post reply on HN