5 ms·

> 1. rust eliminates data races through the type system, so the great benefit of promises doesn't exist in this context I don't know about this one. Programmer

by Rusky 3y ago

> 1. rust eliminates data races through the type system, so the great benefit of promises doesn't exist in this context I don't know about this one. Programmers who use async Rust often talk about how they appreciate that `await` is explicit because it lets them coordinate state using cooperative scheduling. This is maybe a bit higher-level than just data races, but it is about avoiding certain kinds of race conditions. > it explains why people have this bizarre misconception that promises are just an efficiency hack, because in rust that's all they are I'm not sure about this either. The post argues that they are more than an efficiency hack in Rust, too- that intra-task concurrency is a useful control flow structure and promises are what enable it. That intra-task concurrency happens to share a thread is a performance benefit but that's incidental to its flexibility benefits. > promises are what async rust implemented, just under the name of 'futures'. Well, it's not like Rust's promises are exactly like JavaScript's promises either. JavaScript promises are continuation/callback based; Rust's are poll-based. In a sense they're like your earlier definition of "futures," except that the future API lets its caller decide how to block when the result is not yet available.

kragen 3y ago
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 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
- Rusky 3y ago
  > i don't agree with your implication that data races are a low-level thing. I don't mean low level in that sense, just that they're a narrower concept than general race conditions. > it's not clear whether in this phrase you are referring to the real future api or to what rust confusingly calls 'futures'. I'm referring to Rust's API.
  - kragen 3y ago
    thank you very much for the clarifications! i'd still be delighted to see examples of how you can coordinate state changes with 'await'. git repositories containing purported examples would be fine, i'm not suggesting you write an entire async rust program in an hn comment from my point of view, at this point, rust async seems to be a terrible design blunder. rust's design for massive concurrency is statically proving race-freeness, and that's what makes rust such a promising development. async in rust seems like the kind of development that could destroy the community and render the language worthless, while simultaneously torpedoing public understanding of halstead's futures model (though i don't think it's very promising) and javascript's async approach to concurrency (which is), ruining their chances to succeed as well. so i'm highly motivated to investigate any evidence that i'm wrong
    - jkarneges 3y ago
      > rust async seems to be a terrible design blunder [...] that could destroy the community and render the language worthless What an extreme take! Async Rust as-it-is makes perfect sense for Rust's primary audience: folks who desire control/performance enough that they would otherwise be using C/C++. To call async an "efficiency hack" is to underestimate how important that efficiency is to Rust's existence. If async didn't work the way it does, it wouldn't have gained traction within the Rust community (folks would have just ignored it and kept writing state machines by hand) and it wouldn't have been able to act as a draw for C/C++ developers. It's a killer feature, and has enabled the language to thrive. Not only is it a killer feature, the way it is designed is the only way it could have been. See: https://without.boats/blog/why-async-rust/ https://without.boats/blog/why-async-rust/

by Rusky 3y ago

kragen 3y ago

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

Rusky 3y ago
> i don't agree with your implication that data races are a low-level thing. I don't mean low level in that sense, just that they're a narrower concept than general race conditions. > it's not clear whether in this phrase you are referring to the real future api or to what rust confusingly calls 'futures'. I'm referring to Rust's API.
- kragen 3y ago
  thank you very much for the clarifications! i'd still be delighted to see examples of how you can coordinate state changes with 'await'. git repositories containing purported examples would be fine, i'm not suggesting you write an entire async rust program in an hn comment from my point of view, at this point, rust async seems to be a terrible design blunder. rust's design for massive concurrency is statically proving race-freeness, and that's what makes rust such a promising development. async in rust seems like the kind of development that could destroy the community and render the language worthless, while simultaneously torpedoing public understanding of halstead's futures model (though i don't think it's very promising) and javascript's async approach to concurrency (which is), ruining their chances to succeed as well. so i'm highly motivated to investigate any evidence that i'm wrong
  - jkarneges 3y ago
    > rust async seems to be a terrible design blunder [...] that could destroy the community and render the language worthless What an extreme take! Async Rust as-it-is makes perfect sense for Rust's primary audience: folks who desire control/performance enough that they would otherwise be using C/C++. To call async an "efficiency hack" is to underestimate how important that efficiency is to Rust's existence. If async didn't work the way it does, it wouldn't have gained traction within the Rust community (folks would have just ignored it and kept writing state machines by hand) and it wouldn't have been able to act as a draw for C/C++ developers. It's a killer feature, and has enabled the language to thrive. Not only is it a killer feature, the way it is designed is the only way it could have been. See: https://without.boats/blog/why-async-rust/ https://without.boats/blog/why-async-rust/