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

61–70 of 199 posts

Re: Update on await syntax in Rust

#61

Post by tracker1 »

kbsletten wrote: post #26
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.

In C#/ASP.Net use Context.Items or otherwise create your own context to track what you need.

Re: Update on await syntax in Rust

#62

Post by tracker1 »

BozeWolf wrote: post #3

Nice! That was quicker then I Expected. How far are they with the implementation? Not using rust, but following progress because it is on hackernews so much. Why does it take so long for swift to have this? Swift + iOS developers really really benefit from it. And there are loads of ios developers compared to rust developers.

There seems to have been a lot of groundwork for the Futures specification as well as implementations of underlying features for a while.

Not too dissimilar for JavaScript's async/await syntax which needed support for Promises and Generators as progress points.

Re: Update on await syntax in Rust

#63

Post by childintime »

All control flow mechanisms except await have their own statement: if, for, while, match. Howcome await is different?

The dot await syntax might hide an await within an expression, as "just another method". You'll need to hunt it down.

I feel await has costs and consequences that need to be explicit. The dot syntax does the opposite, and therefore I feel Rust might be making a mistake of a lifetime (pun intended) on this one.

Re: Update on await syntax in Rust

#64

Post by staticassertion »

jerf wrote: post #60
staticassertion wrote: post #55

Earlier quoted context omitted.

> Lazy vs strict semantics are completely orthogonal to the syntax [0] Alternatively, the syntax in Haskell just lends itself to lazy evaluation, and requires explicit annotation syntax to be strict. Contrasted with Python, which has a syntax that makes strict evaluation an easier default to express. If all languages can express, with some effort, the same exact semantics as any other language, then the only differen…

I'd submit the key difference in Haskell syntax is actually currying, not laziness. Haskell syntax privileges currying, and an executed function is just a curried function that has all of its parameters. By contrast, currying in languages with Algol-descended syntax always requires more rigamarole. It's possible, of course, in a lot of them, but it's harder than just a function call missing some of its arguments.

My point is that the "it's harder" is why syntax is the differentiator.

The idea that syntax isn't a huge differentiator for languages is insane to me. Yes, small syntactic changes like "fun" vs "fn" may not matter overall, but obviously people choose languages based on what they can easily express by typing sourcecode.

Arguably, the difference between await syntaxes is closer to "fn vs fun" than "lazy vs strict", but I think that there's a lot of context that pushes it closer to the latter (we're talking about how a fundamental control flow primitive is implemented, and this will impact future control flow primitives).

Re: Update on await syntax in Rust

#65

Post by tracker1 »

_v7gu wrote: post #52
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…

I think you can skip the empty () in D. The syntax becomes much more readable when you don't have to return to upper levels of functions. Thankfully pipes exist in functional languages, which makes it feel just right half_square = a |> square |> divide(_, 2)

Was going to mention pipes... which imho is about the nicest syntax imho in terms of being able to follow workflow.

Re: Update on await syntax in Rust

#67

Post by kllrnohj »

ridiculous_fish wrote: post #33
sagichmal wrote: post #22

Earlier quoted context omitted.

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

UI programming is one domain where it's important to know this.

Same with graphics/game programming, particularly as some APIs (looking at you, OpenGL) are entirely built on thread-local state.

Re: Update on await syntax in Rust

#69

Post by anchpop »

_v7gu wrote: post #52
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…

I think you can skip the empty () in D. The syntax becomes much more readable when you don't have to return to upper levels of functions. Thankfully pipes exist in functional languages, which makes it feel just right half_square = a |> square |> divide(_, 2)

I left the `()` because in some imperative languages there's a difference between `() -> a` and `a`, which makes `a.b` and `a.b()` different. In Haskell there's `>>>` and `&` in base, which I use all the time for this sort of workflow:

    find_half_square = square >>> (flip divide) 2
This creates a function which takes a value, performs `square`, then performs `(flip divide) 2`. It's written in pointfree style, which means the function's input is never written in the definition of the function, which I find to be extremely aesthetically pleasing (as it allows me to focus on the composition of functions, without thinking about passing arguments around). This is one situation where changes in syntax allow you to reason about programs quite differently.
Post reply on HN