Inside Rust's Async Transform • Hacker News Board

Re: Inside Rust's Async Transform

#81

Post by oconnor663 » Wed, Dec 12, 2018, 1:09 AM UTC

steveklabnik wrote: post #35

ben0x539 wrote: post #33

Earlier quoted context omitted.

I think the JS world might be particularly excited about async/await because other people just escape to threads when they don't want to block the whole thing on IO. Both in JS or Rust, you don't gain anything just by declaring your thing to be async, or awaitable. Your function needs to be built around some kind of "primitive" that explicitly supports the "do something else in the meantime" mechanism. Using "await"…

The latest tokio has a work-stealing threadpools, so you don’t need to explicitly do this anymore, IIRC.

Neat! Do you know if there's anything in there resembling the rayon::join API? I didn't see anything on a cursory look.

Re: Inside Rust's Async Transform

#82

Post by steveklabnik » Wed, Dec 12, 2018, 10:06 PM UTC

oconnor663 wrote: post #81

steveklabnik wrote: post #35

Earlier quoted context omitted.

The latest tokio has a work-stealing threadpools, so you don’t need to explicitly do this anymore, IIRC.

Neat! Do you know if there's anything in there resembling the rayon::join API? I didn't see anything on a cursory look.

I am not sure, to be honest. I've been waiting until everything settles down to really dig in.

Re: Inside Rust's Async Transform

#83

Post by ZeikJT » Thu, Dec 13, 2018, 9:10 PM UTC

ben0x539 wrote: post #33

2bitencryption wrote: post #27

Async/await pattern always confuses me, someone please let me know if I get this right: First, async/await does NOT mean "threading" or "multiprocessing" or "concurrency". It simply means "using a state machine to alternate between tasks, which may or may not be concurrent." Right? Further, in Javascript, futures and async are utilized heavily because we so frequently need to wait for IO events (i.e.: network events)…

I think the JS world might be particularly excited about async/await because other people just escape to threads when they don't want to block the whole thing on IO. Both in JS or Rust, you don't gain anything just by declaring your thing to be async, or awaitable. Your function needs to be built around some kind of "primitive" that explicitly supports the "do something else in the meantime" mechanism. Using "await"…

> Both in JS or Rust, you don't gain anything just by declaring your thing to be async, or awaitable.

I'm not familiar with Rust but in JS you do gain something. Just the fact that the function is async means that it now explicitly returns a promise, which means that anything awaiting that promise will be in a new execution context and will definitely not run synchronously.

Re: Inside Rust's Async Transform

#84

Post by ZeikJT » Fri, Dec 14, 2018, 12:19 AM UTC

sophiebits wrote: post #10

steveklabnik wrote: post #8

Earlier quoted context omitted.

One difference that may exist is that in Rust, async fns don’t immediately execute, they simply create one of these values. I forget if JS and C# do something different, that is, the execute up until the first suspend point. This was one of the major design decisions we’ve made that’s different than other languages.

JS starts immediately but even if the function's return value is "ready" synchronously, you can't get its value back synchronously.

I've never thought about the execution order before but that makes a lot of sense. Thinking about it now, an async function is just sugar for wrapping the return in a Promise (besides the async/await restructuring). And constructing new Promises works that way exactly.