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

21–30 of 199 posts

Re: Update on await syntax in Rust

#21

Post by joshuamorton »

sagichmal wrote: post #17
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…

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.

This is a strong assertion with basically no backing, and all modern languages have some level of what you call ambiguity, so this isn't true in practice either.

Re: Update on await syntax in Rust

#22

Post by sagichmal »

seanalltogether wrote: post #16

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.

You typically don't, as knowing which physical thread you're running in is (thankfully) becoming a relic of the past.

Re: Update on await syntax in Rust

#23

Post by aerovistae »

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…

I would say syntax is everything. What's the difference between python and Haskell without syntax?

Re: Update on await syntax in Rust

#24

Post by [deleted] »

seanalltogether wrote: post #16

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.

[deleted]

Re: Update on await syntax in Rust

#25

Post by steveklabnik »

seanalltogether wrote: post #16

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.

async/await produces a Future. In order for that Future to execute, you place it on an executor. It won't start executing until you do so. Which thread it runs on, and how, is all the executor's job. So the answer is basically "pick the executor which has the semantics you want".

Re: Update on await syntax in Rust

#26

Post by kbsletten »

seanalltogether wrote: post #16

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.

In C#, your tasks are submitted to the ambient task scheduler. In ASP.NET, this is (I believe) the main thread pool that handles requests. The only time I've ever had to care where something was running is when adding response headers because that's available as a thread local API that can't happen on another thread, but it's generally ended up as a "it hurts when I do this" kind of situation.

Re: Update on await syntax in Rust

#27

Post by steveklabnik »

yingw787 wrote: post #12

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

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

Due to the connotations of "religious battle", it's hard to get a good answer here. Nobody wants to be painted in this light.

> Is this syntax for native coroutines?

No.

> Can it be combined with existing user and stdlib syntax?

Yes.

> What pathways for syntax development does this decision cut off entirely, and pathways does it leave open?

Nothing outside of the async/await feature itself.

> What did the Rust community / maintainers learn from this debate, and how can the Rust community avoid such battles in the future?

This is too long for an HN comment :)

Re: Update on await syntax in Rust

#28

Post by axelf4 »

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…

While I do have an opinion on the syntax I could never amass the time necessary to weigh the positives/negatives of semantics issues. I reckon that's the reality for many.

Re: Update on await syntax in Rust

#29

Post by JoshTriplett »

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.

Speaking as a member of the Rust language team: we specifically evaluated all syntax proposals on the assumption that many people may end up reading them without syntax highlighting. People read code in many places outside of a programmer's text editor or a code-highlighting web page, including logs, diffs, and emails.

Re: Update on await syntax in Rust

#30

Post by swsieber »

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…

Oh. There was lots of discussion over semantics, with people who worked on implementing (e.g. language creators) await/async in other languages. The problem/solution space was a lot smaller though.

Also, there is a notable usability difference, wrt reading the flow of lines, chaining and parentheses. Learnabilty/wierdness was a syntax consideration, but not the only one.

Post reply on HN