A final proposal for Rust await syntax • Hacker News Board

Re: A final proposal for Rust await syntax

#61

Post by ljm » Mon, May 06, 2019, 4:49 PM UTC

foota wrote: post #45

wtetzner wrote: post #36

Earlier quoted context omitted.

> 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.

If it's an effective solution it will only seem weird until it's proven to be more useful than the status quo approach.

I read this post and thought 'async as a prefix is intuitive!', but that's only because I saw it first in C#.

Rust already has an immense learning curve despite its ergonomics, I say it should continue to experiment. Same way Haskell does.

I do wonder if `.await` could have a sigil equivalent the same way `try!` did with `?`. `…` could work if it's not already used as spread args.

Re: A final proposal for Rust await syntax

#62

Post by arcticbull » Mon, May 06, 2019, 4:50 PM UTC

Serious suggestion, and I assume you have -- have you considered ".await?" as an alternative? It won't conflict with field names and cribs on the fact that "?" changes control flow.

Re: A final proposal for Rust await syntax

#63

Post by steveklabnik » Mon, May 06, 2019, 4:51 PM UTC

arcticbull wrote: post #62

Serious suggestion, and I assume you have -- have you considered ".await?" as an alternative? It won't conflict with field names and cribs on the fact that "?" changes control flow.

Yes, it was.

Re: A final proposal for Rust await syntax

#64

Post by michaelmior » Mon, May 06, 2019, 4:55 PM UTC

jwr wrote: post #55

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 Every time I see a statement like this, I remember a (paraphrased) statement from Rich Hickey: "[musical] instruments are made for people who can play them!". I think unless you are specifically designing a beginner language (like Scratch), you should not take into consideration "ease of use" or "familiarity" arguments.

I see "ease of use" and "familiarity" as two different concerns. I think I would agree with you on familiarity, but even if I'm advanced user of the language, I want it to be easy to use wherever that doesn't conflict with other more important goals. (And I think some things are less important than ease of use.).

Re: A final proposal for Rust await syntax

#65

Post by jononor » Mon, May 06, 2019, 4:56 PM UTC

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…

New users expect things to be a bit different by assuming there are good reasons for change of convention.

EDIT: this might very well be the case here though, especially future extension for similar operators and chain-ability.

Re: A final proposal for Rust await syntax

#66

Post by majewsky » Mon, May 06, 2019, 4:58 PM UTC

lukeqsee wrote: post #3

I'm anxiously awaiting this. I just finished overhauling a rather involved Tokio/Future based project, and having await/async in the language spec will be a big step forward (and I'm hoping the compiler errors improve as well). As always, kudos to the Rust team for making decisions that are well-reasoned and documented and in a way that looks to the future of the language (and not just meeting a feature deadline)!

> I'm anxiously awaiting this.

Pun intended?

Re: A final proposal for Rust await syntax

#67

Post by tav » Mon, May 06, 2019, 5:00 PM UTC

In the off chance that some Rust developers are looking at this thread, I'd like to put forward a counter-proposal:

1. Use a postfix ?! instead of .await

2. Use a postfix ?? instead of .await?

3. Use the await keyword only in the "for await" construct

Then the common case becomes:

    let resp = http::get(url)??.to_string()

Which, imo, is a bit easier to parse than:

    let resp = http::get(url).await?.to_string()

This would make it easier to follow the core logic in async code, the same way that ? made error handling so much cleaner in Rust.

Re: A final proposal for Rust await syntax

#68

Post by hexane360 » Mon, May 06, 2019, 5:00 PM UTC

giornogiovanna wrote: post #47

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 l…

My personal preference is for a happy medium between "f await" and "f.await", which is some other character that indicates "special postfix". Sort of like how func() is clearly different from macro!(), we can have "expr->keyword" or "expr.keyword!" to differentiate from "expr.property"

Re: A final proposal for Rust await syntax

#69

Post by majewsky » Mon, May 06, 2019, 5:00 PM UTC

zzzcpan wrote: post #37

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…

It's just means there is lack of trust to core designers. They haven't proven themselves to users, that they are capable of addressing their problems and align with their interests. Obviously core devs of Google backed language cannot do better. They can only gain that trust from users within Google, not outside of Google. Not sure about Rust though.

> Obviously core devs of Google backed language cannot do better. They can only gain that trust from users within Google, not outside of Google.

That's a non sequitur. Trust is not mandated by company boundaries. I for one trust in the competence of the Go maintainers, while at the same time having absolutely zero trust in Google as a company.

Re: A final proposal for Rust await syntax

#70

Post by majewsky » Mon, May 06, 2019, 5:01 PM UTC

zzzcpan wrote: post #42

jerf wrote: post #30

Earlier quoted context omitted.

"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.

So the Linux desktop will only become fragmented after the mythical "year of Linux on the desktop"?