A final proposal for Rust await syntax • Hacker News Board

Re: A final proposal for Rust await syntax

#31

Post by erikpukinskis » Mon, May 06, 2019, 4:16 PM UTC

Reading this feels like a person with no good choices trying to convince themselves there's no other way than their best bad one.

"This is the best proposal, except the syntax doesn't make sense, we don't know if we can implement it, and conversation has broken down to the point where we are running in circles and we don't expect to have any more ideas."

I am curious what the current way to do non-blocking code in Rust is and why it's so bad that they'd introduce this much confusion to the language design to fix it.

Re: A final proposal for Rust await syntax

#32

Post by foota » Mon, May 06, 2019, 4:17 PM UTC

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 considering postfix vs prefix. Their main concern seemed to have been the extra syntax required to make prefix work with . And ? (i.e., (await foo).bar() ), but while avoiding this makes for a more optimized language I'm concerned they've missed the impact this will have on new people.

Or maybe I'm just a Luddite :)

Re: A final proposal for Rust await syntax

#33

Post by IngoBlechschmid » Mon, May 06, 2019, 4:18 PM UTC

wbl wrote: post #29

apk-d wrote: post #23

Earlier quoted context omitted.

Having done most of my work in C# and TypeScript the Rust syntax felt weird when I read about it, but on the other hand, I always felt bad being unable to readably chain awaits, least they become var result = (await (await obj.DoSomething()).SomeOperation()).SomeValue; In the end, all syntax is magic that you need to get used to, I guess.

Do notation solves that problem!

Came here to say that. I think do notation (and applicative idioms) are easily one of the most-underappreciated features outside the Haskell community.

Re: A final proposal for Rust await syntax

#34

Post by wtetzner » Mon, May 06, 2019, 4:19 PM UTC

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.

Wasn't there a bunch of disagreement about R6RS?

Re: A final proposal for Rust await syntax

#35

Post by Sharlin » Mon, May 06, 2019, 4:20 PM UTC

nixpulvis wrote: post #19

> Its very easy to build a mental model of the period operator as simply the introduction of all of these various postfix syntaxes: field accesses, methods, and certain keyword operators like the await operation. (In this model, even the ? operator can be thought of as a modification on the period construct.) I like this explanation. But this whole post could really use some more concrete examples of the at the very…

My dislike for the ”dot keyword” syntax has been strong, but if it is selected, hopefully it’s at least generalized to other keywords in the future, so that `.await` doesn’t stay a lone awkward exception to what dot notation means. In particular, I wouldn’t mind if in the future `expr?` could be spelled `expr.try` for consistency (even at the expense of introducing redundancy).

Re: A final proposal for Rust await syntax

#36

Post by wtetzner » Mon, May 06, 2019, 4:22 PM UTC

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 very long time once it's been written, so making the right choice in terms of readability/maintainability seems like the right move.

Re: A final proposal for Rust await syntax

#37

Post by zzzcpan » Mon, May 06, 2019, 4:26 PM UTC

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.

Re: A final proposal for Rust await syntax

#38

Post by Twisol » Mon, May 06, 2019, 4:26 PM UTC

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.

Re: A final proposal for Rust await syntax

#39

Post by saghm » Mon, May 06, 2019, 4:26 PM UTC

Sharlin wrote: post #35

nixpulvis wrote: post #19

> Its very easy to build a mental model of the period operator as simply the introduction of all of these various postfix syntaxes: field accesses, methods, and certain keyword operators like the await operation. (In this model, even the ? operator can be thought of as a modification on the period construct.) I like this explanation. But this whole post could really use some more concrete examples of the at the very…

My dislike for the ”dot keyword” syntax has been strong, but if it is selected, hopefully it’s at least generalized to other keywords in the future, so that `.await` doesn’t stay a lone awkward exception to what dot notation means. In particular, I wouldn’t mind if in the future `expr?` could be spelled `expr.try` for consistency (even at the expense of introducing redundancy).

I like that idea for try! Near the bottom of the blog post, they mention that `match` could become a "dot keyword" expression, giving the following example:

  foo.bar(..).baz(..).match {
      Variant1 => { ... }
      Variant2(quux) => { ... }
  }

Re: A final proposal for Rust await syntax

#40

Post by astrodust » Mon, May 06, 2019, 4:28 PM UTC

kibwen wrote: post #27

astrodust wrote: post #9

Earlier quoted context omitted.

If the way async/await has fundamentally changed how you write JavaScript code is any example, this will be a tectonic shift, especially for event-driven code like you use with Tokio.

I agree that it's an important addition to the language, but I think it will be less impactful for Rust than for JavaScript because server-side JS is almost always in a domain that benefits from async IO, whereas Rust exists in many domains where async IO isn't a performance priority.

It's an important concurrency model. Perhaps Rust doesn't have a lot of async code because it's been really annoying to do it. This could change that dramatically.