4 ms·

That Rust needed async/await to be palatable to JS devs would only be a problem if we think async/await is not needed in Rust, because it is only useful to work

That Rust needed async/await to be palatable to JS devs would only be a problem if we think async/await is not needed in Rust, because it is only useful to work around limitations of JS (single-threaded execution, in this case). If instead async/await is a good feature in its own right (even if not critical), then JS forcing Rust's hand would be at best an annoyance. And the idea that async/await was only added to JS to work around its limitations is simply wrong. So the OP is overall wrong: async/await is not an example of someone taking something that only makes sense in one language and using it another language for familiarity.

lelanthran 3y ago
> So the OP is overall wrong: async/await is not an example of someone taking something that only makes sense in one language and using it another language for familiarity. I don't really understand the counter argument here. My reading of the argument[1] is that "Popularity amongst developers forced Rust devs hands in adding async". If this is the argument, then a counter argument of "It never (or only) made sense in the popular language (either)" is a non-sequitor. IOW, if it wasn't added due to technical reasons (which is the original argument, IIRC), then explaining technical reasons for/against isn't a counter argument. [1] i.e. Maybe I am reading it wrong?
- bsder 3y ago
  You are not reading it wrong, and your statements are accurate. My broader point is that the possibility of there being a "technically better" construct was simply not in scope for Rust. In order for Rust to capture Javascript programmers, async/await was the only construct that could possibly be considered. And, to be fair, it worked. Rust's growth has been almost completely on the back of network services programming.
  - withoutboats3 3y ago
    This comment is a lie.
- withoutboats3 3y ago
  You are not reading the claim wrong, but the claim is a lie. We did not add async/await to Rust because it was popular but because it was the right solution for Rust. If you actually read my post that this liar linked to, you will find a detailed explanation of the technical history behind the decision.

lelanthran 3y ago

> So the OP is overall wrong: async/await is not an example of someone taking something that only makes sense in one language and using it another language for familiarity. I don't really understand the counter argument here. My reading of the argument[1] is that "Popularity amongst developers forced Rust devs hands in adding async". If this is the argument, then a counter argument of "It never (or only) made sense in the popular language (either)" is a non-sequitor. IOW, if it wasn't added due to technical reasons (which is the original argument, IIRC), then explaining technical reasons for/against isn't a counter argument. [1] i.e. Maybe I am reading it wrong?

bsder 3y ago
You are not reading it wrong, and your statements are accurate. My broader point is that the possibility of there being a "technically better" construct was simply not in scope for Rust. In order for Rust to capture Javascript programmers, async/await was the only construct that could possibly be considered. And, to be fair, it worked. Rust's growth has been almost completely on the back of network services programming.
- withoutboats3 3y ago
  This comment is a lie.
withoutboats3 3y ago
You are not reading the claim wrong, but the claim is a lie. We did not add async/await to Rust because it was popular but because it was the right solution for Rust. If you actually read my post that this liar linked to, you will find a detailed explanation of the technical history behind the decision.