3 ms·

It seems to me that there are two huge (cosmetic? branding?) problems with async/await 1. The words are completely awful. There's nothing "not synchronous" a

It seems to me that there are two huge (cosmetic? branding?) problems with async/await 1. The words are completely awful. There's nothing "not synchronous" about an async function. Maybe at best "not synchronized". 2. The idea of pretending async functions are still "functions" is kinda terrible. This is really a huge problem in say python where the architecture (iirc) is via iterator/yield, so your function "actually" has multiple outputs. Maybe a radical idea in PL design would be to actually make "async functions" be some sort of other thing in the same sense that, for example, pascal had "procs" and "functions" You could easily solve the coloring problem by creating some sort of builtin that does an immediate, blocking execution of the function by compiling out all the suspend sites, or keeps them "in place" in the case where you want to keep things as if they are futures.

hn_throwaway_99 3y ago
> The idea of pretending async functions are still "functions" is kinda terrible This makes no sense to me. An async function is just syntactic sugar for a (normal in every way) function that returns a promise.
- zbentley 3y ago
  Not necessarily. That's (mostly) true in e.g. JavaScript, but is not true in Rust. My novice understanding of the Rust model is that an async function is compiled down to a state machine and a set of functions which execute parts of the async function's code and then manipulate the state machine. Those manipulations have two broad categories of side effects: they can wake up/be observed by pollers, and can change the state of later parts of the task corresponding to an invocation of the original async fn (e.g. by setting variables for subsequent functions in the set--code on the other side of an internal await point that uses the result of the await). In other words, async functions in some languages are more than just sugar for "delegate to event loop and return promise resolved by delegate completion".
  - withoutboats3 3y ago
    I don’t really understand what you mean about side effects but async functions do indeed just return futures just like JavaScript async functions return promises - rust futures just are compiled into state machines in a way JavaScript promises are not.

hn_throwaway_99 3y ago

> The idea of pretending async functions are still "functions" is kinda terrible This makes no sense to me. An async function is just syntactic sugar for a (normal in every way) function that returns a promise.

zbentley 3y ago
Not necessarily. That's (mostly) true in e.g. JavaScript, but is not true in Rust. My novice understanding of the Rust model is that an async function is compiled down to a state machine and a set of functions which execute parts of the async function's code and then manipulate the state machine. Those manipulations have two broad categories of side effects: they can wake up/be observed by pollers, and can change the state of later parts of the task corresponding to an invocation of the original async fn (e.g. by setting variables for subsequent functions in the set--code on the other side of an internal await point that uses the result of the await). In other words, async functions in some languages are more than just sugar for "delegate to event loop and return promise resolved by delegate completion".
- withoutboats3 3y ago
  I don’t really understand what you mean about side effects but async functions do indeed just return futures just like JavaScript async functions return promises - rust futures just are compiled into state machines in a way JavaScript promises are not.