4 ms·

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

by 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/
  - kragen 3y ago
    i'm not underestimating efficiency; i'm well aware that in many situations it's more important than correctness. but i think it's important to distinguish between decisions made for the sake of efficiency and decisions that tend to make your code more modular, flexible, comprehensible, verifiable, or maintainable. promises originated as a way to make highly concurrent code more modular, flexible, comprehensible, verifiable, and maintainable. halstead's futures did, too. so did rust itself async in rust is the opposite, and to me it looks like such an expensive way to get that efficiency that it strongly undermines the reasons for adopting rust

by Rusky 3y ago

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/
- kragen 3y ago
  i'm not underestimating efficiency; i'm well aware that in many situations it's more important than correctness. but i think it's important to distinguish between decisions made for the sake of efficiency and decisions that tend to make your code more modular, flexible, comprehensible, verifiable, or maintainable. promises originated as a way to make highly concurrent code more modular, flexible, comprehensible, verifiable, and maintainable. halstead's futures did, too. so did rust itself async in rust is the opposite, and to me it looks like such an expensive way to get that efficiency that it strongly undermines the reasons for adopting rust