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

101–110 of 265 posts

Re: A final proposal for Rust await syntax

#101

Post by agency »

holy_city wrote: post #51
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 Some folks came up with the idea of a "weirdness" budget - arguing that Rust had come close to using it all up. >I feel like the committee has worried about the wrong things There is no "committee" really, and all the worries have been expressed and weighed. The debate over this syntax has been going on for months and had huge community involvement. It's all been summed up in this d…

Thanks for the link. As an outsider I also thought it seemed weird given so many other languages use prefix, but it makes sense with this framing that the main concern is the interaction with the ? operator.

Re: A final proposal for Rust await syntax

#102

Post by Rusky »

eridius wrote: post #97
Rusky wrote: post #96

Earlier quoted context omitted.

In Kotlin this is not an issue, because you simply can't call an async function at all until you've added the async keyword (actually `suspend` in Kotlin). If you want to call an async function from a sync context, you just wrap it in an async block.

What does an async block evaluate to? Does that wrap up the contents in Kotlin's equivalent of a Future? In any case, I'm a big fan of the idea that async/await is just syntax around something that can be done without the syntax (i.e. wrapping Futures that can otherwise be manipulated without the syntax).

Yes, an async block (or `suspend` closure in Kotlin) just wraps up its contents in a future, applying the same state machine transform as would be applied to a top-level async function.

Re: A final proposal for Rust await syntax

#103

Post by ajross »

pcwalton wrote: post #89
ajross wrote: post #74

Earlier quoted context omitted.

> If it's an effective solution it will only seem weird until it's proven to be more useful than the status quo approach. Perl was a very effective solution. Still lost. And I say that as a long time perl5 nut. Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). And it's getting rapidly worse.

> Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). Can you elaborate?

Not even if you paid me to have that fight, no.

Edit: OK, one tiny crumb: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html -- Read through that thinking about how other languages express the same fundamentally simple concepts, and consider how Rust invents new syntax for basically everything, and then sticks it all together by re-using syntax from other areas. Why does a parametrized enumerant look like a function call and not a struct? Why is "127.0.0.1" not a String? Why do parametrized enumerants look in rvalues like C++ constructor arguments, which you promised earlier Rust didn't have?

Don't tell me the answers to those questions. I know the answers. Just recognize that those are questions that every new reader to that very early page in your docs is going to have. And... did they even need to be questions in the first place?

Re: A final proposal for Rust await syntax

#104

Post by Rusky »

eridius wrote: post #99
Rusky wrote: post #95

Earlier quoted context omitted.

That was discussed in a previous post, but yes that's why. And in Rust, the biggest postfix expression is the extremely common `?` operator, expected to be used with most futures.

I haven't really been following along very much. I take it from your comment that await in Rust will not automatically propagate errors upwards like it does in JavaScript? So you have to use `foo.await?` in the normal case if you only want to handle successful results?

That's correct. In a sense Javascript await isn't the thing that propagates errors, that's just the language's usual exception behavior plumbed through the Promise.

Re: A final proposal for Rust await syntax

#105

Post by Rusky »

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!

Do notation does not solve that problem. It solves the problem of chaining `.and_then` calls, but this is one layer up- do notation would still require each of those awaits to be a separate `a <- b` "statement," which couldn't even be chained in the first place!

Re: A final proposal for Rust await syntax

#106

Post by foota »

pcwalton wrote: post #89
ajross wrote: post #74

Earlier quoted context omitted.

> If it's an effective solution it will only seem weird until it's proven to be more useful than the status quo approach. Perl was a very effective solution. Still lost. And I say that as a long time perl5 nut. Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). And it's getting rapidly worse.

> Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). Can you elaborate?

I'll bite. For context, I'm very much a rust beginner with probably a couple dozen hours at most. I find that anything having to do with lifetime parameters is hard. I think this is even worse than C++ templating in some sense since it behaves differently than type templating.

Otherwise, I think the syntax is fairly reasonable.

Re: A final proposal for Rust await syntax

#107

Post by simias »

ajross wrote: post #74
ljm wrote: post #61

Earlier quoted context omitted.

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

> If it's an effective solution it will only seem weird until it's proven to be more useful than the status quo approach. Perl was a very effective solution. Still lost. And I say that as a long time perl5 nut. Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). And it's getting rapidly worse.

I've used perl5 for a long time (although these days I've replaced it with python in my toolchain, although I have my fair share of complaints about python as well) and I think your comparison is unfair.

Rust's sometimes complicated syntax is made necessary by the very concept of the language. You need to be able to express lifetimes, you need to be able to express generics, you need to be able to strongly type lambdas etc... Of course the syntax is going to be a bit more complicated than, say, Common Lisp where everything is dynamic and garbage collected and you can let the runtime figure things out.

Perl 5 was syntactically insane because that's how the authors decided to do it. Effectively it didn't let you express things that were impossible in Lisp, Python, Ruby or JS. It's just a design choice to lean heavily on sigils and magic variables to favor short code even if it can be cryptic to people not intimately familiar with the language. I doubt anybody who hasn't used perl before will be able to figure out exactly what this does (and I'd argue that it's a fairly simple and idiomatic script, not some heinously cryptic code golf):

    while () { chomp(); s/f.o/bar/; print; }
Rust is noisy because it has to represent concepts that simply don't exist in other programming languages.

I'd go even further: Rust does a better job than most languages at letting you only explicitly mention things that need to be explicitly mentioned. Thanks to the very powerful type inference you can write very tidy code, IMO much more so than in C where I have to explicitly type every intermediary variable that I would use for instance.

Re: A final proposal for Rust await syntax

#108

Post by zzzcpan »

pcwalton wrote: post #89
ajross wrote: post #74

Earlier quoted context omitted.

> If it's an effective solution it will only seem weird until it's proven to be more useful than the status quo approach. Perl was a very effective solution. Still lost. And I say that as a long time perl5 nut. Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). And it's getting rapidly worse.

> Rust is, indeed, just syntactically insane to a new learner (honestly, worse than perl ever was). Can you elaborate?

Perl was designed to be familiar to C programmers.

Re: A final proposal for Rust await syntax

#109

Post by 13415 »

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 wouldn't use a programming language whose designer had this attitude.

Re: A final proposal for Rust await syntax

#110

Post by M2Ys4U »

jkarneges wrote: post #75

I figure the reason the proposed syntax looks gross is because other languages have been using a prefixed await for many years. The Rust decision seems well thought out though, enough to make me wonder if perhaps other languages have been doing it wrong. My first experience with futures was in the form of QFuture ( https://doc.qt.io/qt-5/qfuture.html ), and there you call .result() to block and wait for the result. T…

At first I was firmly in the prefix camp, until I read one of the (massive!) GitHub issues on the subject and came around to postfix.

I'd _much_ rather use something like `?` than `.await`, though. Using a keyword just feels wrong in a few different ways.

Post reply on HN