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

51–60 of 265 posts

Re: A final proposal for Rust await syntax

#51

Post by holy_city »

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 document:

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

I was definitely in the prefix camp before I read that document.

Re: A final proposal for Rust await syntax

#52

Post by eslaught »

blattimwind wrote: post #41
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

Did you see the previous post on this topic? They discussed this extensively:

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

Re: A final proposal for Rust await syntax

#53

Post by nixpulvis »

albru123 wrote: post #50
Twisol wrote: post #38

Earlier quoted context omitted.

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?

Pattern matching syntax across many languages is very similar, most notably inspired by ML I'd say.

Re: A final proposal for Rust await syntax

#54

Post by cyphar »

blattimwind wrote: post #41
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

I don't think "expr await" would be a good choice but that isn't the decision that was made, and I wasn't arguing for it in the first place. TFA says that using alternative punctuation was decided against because it would lead to line-noise and I don't think there's much more to discuss -- I understand that position and respect it.

My main issue with .await is that it does look method-y rather than keyword-y. But while I like Python's "await expr" syntax in Python the existence of ? and chaining of methods in Rust justifies having a different syntax for it.

Re: A final proposal for Rust await syntax

#55

Post by jwr »

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.

Re: A final proposal for Rust await syntax

#56

Post by anp »

albru123 wrote: post #50
Twisol wrote: post #38

Earlier quoted context omitted.

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?

Pattern matching as is in Rust has many notable precedents that IIRC the C# folks considered as prior art, not least of which being F#.

Re: A final proposal for Rust await syntax

#58

Post by steveklabnik »

nchie wrote: post #22
Arnavion wrote: post #20

Earlier quoted context omitted.

What good will postponing do? The blog post implies that it's already been debated for a long time and all the arguments seem to have already been brought forth. You can't just keep punting it forever; it has to get stabilized at some point.

It's been debated, but there's hardly any code using it. After seeing how it's being used by most people, it'd be easier to make a choice.

Because it’s been clear that what exists is not stable, many people are waiting until it’s stable to try.

There were a number of people who converted code to the various proposals, so that helped.

Re: A final proposal for Rust await syntax

#59

Post by joshuamorton »

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.

Counterpoint: APL and perl vs. python. Python did take usability into account and familiarity. UX is important. Developers are users. As a language (or in general tool) designer you have a responsibility to make that tool easy to use, and difficult to misuse.

Familiarity is a big part of that, although ease of use is bigger (which is probably why python got the traction it did despite being unfamiliar to people who came from braces-land).

Re: A final proposal for Rust await syntax

#60

Post by steveklabnik »

erikpukinskis wrote: post #31

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

If every choice was obvious, there would be no need for a designer in the first place.
Post reply on HN