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

Update on await syntax in Rust

boats.gitlab.io

Post reply on HN
Print view View original

11–20 of 199 posts

Re: Update on await syntax in Rust

#11

Post by cle »

Analemma_ wrote: post #4

The fact that discussions over syntax generate pages and pages of furious bickering, while discussions over semantics (which is what actually matters) get a shrug, is the ultimate example of bikeshedding in PL design. Honestly, syntax just doesn't matter . Yes, particular poor choices can impede usability, but that's not applicable here, and ultimately after two minutes or so of learning the new syntax there's no dif…

They both matter. Confusing syntax can lead to just as many bugs as confusing semantics.

(I'm not arguing that they weren't bikeshedding...)

Re: Update on await syntax in Rust

#12

Post by yingw787 »

I'm not familiar around the syntax, but I'm interested to know how much of this was a religious battle and how much of it results in meaningful complications for user code down the line. I've heard really good things about the Rust community (like nothing bad at all), until maybe two weeks ago when somebody mentioned this stuff. I'm a really big fan of not having religious battles.

Is this syntax for native coroutines? Can it be combined with existing user and stdlib syntax? What pathways for syntax development does this decision cut off entirely, and pathways does it leave open? What did the Rust community / maintainers learn from this debate, and how can the Rust community avoid such battles in the future?

Re: Update on await syntax in Rust

#13

Post by Retra »

anchpop wrote: post #9
Analemma_ wrote: post #4

The fact that discussions over syntax generate pages and pages of furious bickering, while discussions over semantics (which is what actually matters) get a shrug, is the ultimate example of bikeshedding in PL design. Honestly, syntax just doesn't matter . Yes, particular poor choices can impede usability, but that's not applicable here, and ultimately after two minutes or so of learning the new syntax there's no dif…

Syntax may be irrelevant at the end of the day, but nice syntax can make a big difference in usability imo. I'm not following the Rust example, but discussions of it remind me about discussions about UFCS (Universal Function Call Syntax). That's where `foo(a, b)` can be rewritten as `a.foo(b)`. That may seem minor, but look at this code: half_square = divide(square(a), 2) In comparison to: half_square = a.square().di…

What's a big difference for you got to do with the design of a language used by many others? What makes your experience more important than the experiences of someone with different qualifications?

Why is optimizing for your tastes the correct thing to optimize for?

Re: Update on await syntax in Rust

#14

Post by byproxy »

anchpop wrote: post #9
Analemma_ wrote: post #4

The fact that discussions over syntax generate pages and pages of furious bickering, while discussions over semantics (which is what actually matters) get a shrug, is the ultimate example of bikeshedding in PL design. Honestly, syntax just doesn't matter . Yes, particular poor choices can impede usability, but that's not applicable here, and ultimately after two minutes or so of learning the new syntax there's no dif…

Syntax may be irrelevant at the end of the day, but nice syntax can make a big difference in usability imo. I'm not following the Rust example, but discussions of it remind me about discussions about UFCS (Universal Function Call Syntax). That's where `foo(a, b)` can be rewritten as `a.foo(b)`. That may seem minor, but look at this code: half_square = divide(square(a), 2) In comparison to: half_square = a.square().di…

Interesting example...I find the first much easier to read and reason about. ¯\_(ツ)_/¯

Re: Update on await syntax in Rust

#15

Post by [deleted] »

Analemma_ wrote: post #4

The fact that discussions over syntax generate pages and pages of furious bickering, while discussions over semantics (which is what actually matters) get a shrug, is the ultimate example of bikeshedding in PL design. Honestly, syntax just doesn't matter . Yes, particular poor choices can impede usability, but that's not applicable here, and ultimately after two minutes or so of learning the new syntax there's no dif…

[deleted]

Re: Update on await syntax in Rust

#16

Post by seanalltogether »

Question for people more familiar with async/await semantics, how do you typically control what thread the async procedure runs on? Having spent a lot of time now in rxJava and really getting into the power of stream processing and composition, it feels like async/await is almost too simplistic.

Re: Update on await syntax in Rust

#17

Post by sagichmal »

anchpop wrote: post #9
Analemma_ wrote: post #4

The fact that discussions over syntax generate pages and pages of furious bickering, while discussions over semantics (which is what actually matters) get a shrug, is the ultimate example of bikeshedding in PL design. Honestly, syntax just doesn't matter . Yes, particular poor choices can impede usability, but that's not applicable here, and ultimately after two minutes or so of learning the new syntax there's no dif…

Syntax may be irrelevant at the end of the day, but nice syntax can make a big difference in usability imo. I'm not following the Rust example, but discussions of it remind me about discussions about UFCS (Universal Function Call Syntax). That's where `foo(a, b)` can be rewritten as `a.foo(b)`. That may seem minor, but look at this code: half_square = divide(square(a), 2) In comparison to: half_square = a.square().di…

Whatever pleasantness may come from that or any other specific example is totally outweighed by the constant overhead of having to remember that there are N ways to do 1 thing. As a primary rule: the best programming grammar has the fewest such ambiguities, ideally zero.

Re: Update on await syntax in Rust

#18

Post by kbenson »

CJefferson wrote: post #2

I'm nit going to stop using rust, but I find this very disappointing. One thing I strongly disagree with - - this article said other notations would require Rust users having to learn more notation. This still requires learning more notation, just it's easy to not even be aware it exists and think a struct had a member called await instead...

My understanding of the issue (which is shallow at best) is that it's a battle between a prefixing keyword or sigil which has the problem of causing the reader to scan back and forth in the statement when chaining multiple items, which sucks), or a postfixing keyword or sigil, with dot notation for a keyword to help parsing (and everyone seems to dislike the overloading of the dot notation for this). Ignoring sigils, I think the chosen solution is the lesser of two evils.

That said, I think a postfixing sigil would have been much better. It seems an important enough thing to denote that a bit of special syntax is called for, and the more unique the better.

Re: Update on await syntax in Rust

#19

Post by kbenson »

Pahr3yah wrote: post #10
CJefferson wrote: post #2

I'm nit going to stop using rust, but I find this very disappointing. One thing I strongly disagree with - - this article said other notations would require Rust users having to learn more notation. This still requires learning more notation, just it's easy to not even be aware it exists and think a struct had a member called await instead...

Await is a keyword, syntax highlighters will most likely paint it differently.

I find the syntax highlighting argument odd. It's like arguing a road surface is acceptable because the dangerous conditions it causes are mitigated by traction control.

Re: Update on await syntax in Rust

#20

Post by anchpop »

Retra wrote: post #13
anchpop wrote: post #9

Earlier quoted context omitted.

Syntax may be irrelevant at the end of the day, but nice syntax can make a big difference in usability imo. I'm not following the Rust example, but discussions of it remind me about discussions about UFCS (Universal Function Call Syntax). That's where `foo(a, b)` can be rewritten as `a.foo(b)`. That may seem minor, but look at this code: half_square = divide(square(a), 2) In comparison to: half_square = a.square().di…

What's a big difference for you got to do with the design of a language used by many others? What makes your experience more important than the experiences of someone with different qualifications? Why is optimizing for your tastes the correct thing to optimize for?

If it's a big difference to me, it would be surprising if it was not a big difference to some portion of people (in either direction, I wouldn't be surprised if most people hate it). Since it makes a big difference to some portion of people, it is worth discussing. My intention with my comment was to make the argument that spending a long time discussing syntax can be a useful and productive thing for language designers to do.
Post reply on HN