i appreciate the feedback, and you could be right; do you have an example of how you can coordinate state using await?
i don't agree with your implication that data races are a low-level thing. they can be, but the canonical example of a data race is a lost write to a bank account, which is not just layer 7 (the application layer) or layer 8 (the user) but layer 9 (the economic production system that employs the user)
> JavaScript promises are continuation/callback based; Rust's are poll-based
this is obviously important for the implementation of a so-called async runtime such as tokio, but as i see it, from the point of view of most of the user code, this is an implementation detail. i was talking about the semantics promises provide to things like an http client, not how those semantics are implemented
> the future API lets its caller decide how to block
it's not clear whether in this phrase you are referring to the real future api or to what rust confusingly calls 'futures'. in case you mean the former, i want to clarify that, in the futures interface defined in 'multilisp: a language for concurrent symbolic computation', (halstead, 01985, https://dl.acm.org/doi/pdf/10.1145/4472.4478), you cannot distinguish a future from the value that it eventually produces, and therefore the caller cannot decide how to block; it doesn't even know it's blocking. as halstead explains:
> An operation (such as addition) that needs to know the value of an
undetermined future will be suspended until the future becomes determined, but
many operations, such as assignment and parameter passing, do not need to
know anything about the values of their operands and may be performed quite
comfortably on undetermined futures. The use of futures often exposes surprisingly large amounts of parallelism [now conventionally called 'concurrency'] in a program, as illustrated by a Quicksort program given in Figure 1. (...)
> These “futures” greatly resemble the “eventual values” of Hibbard’s Algol 68 [39]. The principal difference is that eventual values are declared as a separate data type, distinct from the type of the value they take on, whereas futures cannot be distinguished from the type of the value they take on. This difference reflects the contrast between Algol’s philosophy of type checking at compile time and the Lisp philosophy of run-time tagging of data.
i would claim that, since halstead's paper has been cited 1658 times in google scholar, including 25 times in the last year, his definition of 'future' is very much in current use, and so it is sort of an act of intellectual vandalism to promote a conflicting but confusingly similar definition