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.
Re:Why choose async/await over threads?
by withoutboats3 on Tuesday March 26, 2024 @08:47AM
(#39827166)
This comment is a lie.
Re:Why choose async/await over threads?
by withoutboats3 on Tuesday March 26, 2024 @08:48AM
(#39827184)
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.
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?