6 ms·

[flagged]

ethegwo 2y ago
> Rust does not assume that state changes only when polled. I will replace to more exact description about this, thanks.
ajross 2y ago
What you're describing is a synchronous process, though! ("When a message is put..."). That's the disconnect in the linked article. Two different concepts of asynchrony: one has to do with multiple contexts changing state without warning, the other (what you describe) is about suspending threads contexts "until" something happens.
- withoutboats3 2y ago
  [flagged]
  - biorach 2y ago
    > Again you are wrong. A forum full of people who just like to hear themselves talk. I guess it makes you feel good in some way? I think you're being unduly harsh here. There are a variety of voices here, of various levels of expertise. If someone says something you think is incorrect but it seems that they are speaking in good faith then the best way to handle the situation is to politely provide a correct explanation. If you really think they are in bad faith then calmly call them out on it and leave the conversation.
    - nemothekid 2y ago
      I've been following withoutboats for ~6 years and it really feels like his patience has completely evaporated. I get it though, he has been really in the weeds of Rust's async implementation and has argued endlessly with those who don't like the tradeoffs but only have a surface level understanding of the problem. I think I've read this exact convo maybe 20+ times among HN, Reddit, Github Issues and Twitter among various topics including but not limited to, async i/o, Pin, and cancellation.
      - withoutboats3 2y ago
        I freely admit I’m frustrated by the discourse around async Rust! I’m also very frustrated because I feel I was iced out of the project for petty reasons to do with whom I’m friends with and the people who were supposed to take over my work have done a very poor job, hence the failure to ship much of value to users. What we shipped in 2019 was an MVP that was intended to be followed by several improvements in quick succession, which the Rust project is only now moving toward delivering. I’ve written about this extensively. My opinion is that async Rust is an incredible achievement, primarily not mine (among the people who deserve more credit than me are Alex Crichton, Carl Lerche, and Aaron Turon). My only really significant contributions were making it safe to use references in an async function and documenting how to interface with completion based APIs like io-uring correctly. So it is very frustrating to see the discourse focused on inaccurate statements about async Rust which I believe is the best system for async IO in any language and which just needs to be finished.
        biorach 2y ago
        > So it is very frustrating to see the discourse focused on inaccurate statements about async Rust > No, ajross is very confidently making false descriptions of how async Rust and io-using operate. This website favors people who sound right whether or not they are, because most readers are not well informed but have a ridiculous confidence that they can infer what is true based on the tone and language used by a commenter. I find this deplorable and think this website is a big part of why discourse around computer science is so ignorant, and I respond accordingly when someone confronts me with comments like this. They had an inaccurate (from your point of view) understanding. That's all. If they were wrong that's not a reason to attack them. If you think they were over-confident (personally I don't) that's still not a reason to attack them. Again, I think ajross set out their understanding in a clear and polite manner. You should correct them in a similar manner.
      - biorach 2y ago
        > has argued endlessly with those who don't like the tradeoffs but only have a surface level understanding of the problem But that's really not what's going on here. ajross has an understanding of the fundamentals of async that is different to withoutboats'. ajross is setting this out in a clear and polite way that seems to be totally in good faith. withoutboats is responding in an extremely rude and insulting manner. Regardless of whether they are right or not (and given their background they probably are), they are absolutely in the wrong to adopt this tone.
  - ajross 2y ago
    > If that task has cancelled its interest in this syscall, they should instead clean up the resources owned by that CQE. So, first: how is that not consistent with the contention that the bug is due to a collision in the meaning of "asynchronous"? You're describing, once more, a synchronous operation ("when ... cancel") on a data structure that doesn't support that ("the kernel writes ..." on its own schedule). And second: the English language text of your solution has race conditions. How do you prevent reading from the buffer after the beginning of "cancel" and before the "dispatch"? You need some locking in there, which you don't in general async code. Ergo it's a paradigm clash. Developers, you among them it seems, don't really understand the requirements of a truly async process and get confused trying to shoehorn it into a "callbacks with context switch" framework like rust async.
    - withoutboats3 2y ago
      [flagged]
      - ajross 2y ago
        [flagged]
        withoutboats3 2y ago
        [flagged]
        blinzy 2y ago
        Unbelievable! how bloody rude can you be? To the moderators (dang), do people get to keep their account here just because they're a "famous" poster despite writing the way they're doing all over this post? I'm assuming other posters have been banned for substantially less aggressive behaviour...
    - skavi 2y ago
      > Developers, you among them it seems, don't really understand the requirements of a truly async process and get confused trying to shoehorn it into a "callbacks with context switch" framework like rust async. This is an odd thing to say about someone who has written a correct solution to the problem which triggered this discussion. Also, you really need to define what truly async means. Many layers of computing are async or not async depending on how you look at them.
  - throw10920 2y ago
    > Again you are wrong. A forum full of people who just like to hear themselves talk. I guess it makes you feel good in some way? This is why people don't like the Rust community.

[flagged]

> Rust does not assume that state changes only when polled. I will replace to more exact description about this, thanks.

ajross 2y ago

What you're describing is a synchronous process, though! ("When a message is put..."). That's the disconnect in the linked article. Two different concepts of asynchrony: one has to do with multiple contexts changing state without warning, the other (what you describe) is about suspending threads contexts "until" something happens.

withoutboats3 2y ago
[flagged]
- biorach 2y ago
  > Again you are wrong. A forum full of people who just like to hear themselves talk. I guess it makes you feel good in some way? I think you're being unduly harsh here. There are a variety of voices here, of various levels of expertise. If someone says something you think is incorrect but it seems that they are speaking in good faith then the best way to handle the situation is to politely provide a correct explanation. If you really think they are in bad faith then calmly call them out on it and leave the conversation.
  - nemothekid 2y ago
    I've been following withoutboats for ~6 years and it really feels like his patience has completely evaporated. I get it though, he has been really in the weeds of Rust's async implementation and has argued endlessly with those who don't like the tradeoffs but only have a surface level understanding of the problem. I think I've read this exact convo maybe 20+ times among HN, Reddit, Github Issues and Twitter among various topics including but not limited to, async i/o, Pin, and cancellation.
    - withoutboats3 2y ago
      I freely admit I’m frustrated by the discourse around async Rust! I’m also very frustrated because I feel I was iced out of the project for petty reasons to do with whom I’m friends with and the people who were supposed to take over my work have done a very poor job, hence the failure to ship much of value to users. What we shipped in 2019 was an MVP that was intended to be followed by several improvements in quick succession, which the Rust project is only now moving toward delivering. I’ve written about this extensively. My opinion is that async Rust is an incredible achievement, primarily not mine (among the people who deserve more credit than me are Alex Crichton, Carl Lerche, and Aaron Turon). My only really significant contributions were making it safe to use references in an async function and documenting how to interface with completion based APIs like io-uring correctly. So it is very frustrating to see the discourse focused on inaccurate statements about async Rust which I believe is the best system for async IO in any language and which just needs to be finished.
      - biorach 2y ago
        > So it is very frustrating to see the discourse focused on inaccurate statements about async Rust > No, ajross is very confidently making false descriptions of how async Rust and io-using operate. This website favors people who sound right whether or not they are, because most readers are not well informed but have a ridiculous confidence that they can infer what is true based on the tone and language used by a commenter. I find this deplorable and think this website is a big part of why discourse around computer science is so ignorant, and I respond accordingly when someone confronts me with comments like this. They had an inaccurate (from your point of view) understanding. That's all. If they were wrong that's not a reason to attack them. If you think they were over-confident (personally I don't) that's still not a reason to attack them. Again, I think ajross set out their understanding in a clear and polite manner. You should correct them in a similar manner.
    - biorach 2y ago
      > has argued endlessly with those who don't like the tradeoffs but only have a surface level understanding of the problem But that's really not what's going on here. ajross has an understanding of the fundamentals of async that is different to withoutboats'. ajross is setting this out in a clear and polite way that seems to be totally in good faith. withoutboats is responding in an extremely rude and insulting manner. Regardless of whether they are right or not (and given their background they probably are), they are absolutely in the wrong to adopt this tone.
- ajross 2y ago
  > If that task has cancelled its interest in this syscall, they should instead clean up the resources owned by that CQE. So, first: how is that not consistent with the contention that the bug is due to a collision in the meaning of "asynchronous"? You're describing, once more, a synchronous operation ("when ... cancel") on a data structure that doesn't support that ("the kernel writes ..." on its own schedule). And second: the English language text of your solution has race conditions. How do you prevent reading from the buffer after the beginning of "cancel" and before the "dispatch"? You need some locking in there, which you don't in general async code. Ergo it's a paradigm clash. Developers, you among them it seems, don't really understand the requirements of a truly async process and get confused trying to shoehorn it into a "callbacks with context switch" framework like rust async.
  - withoutboats3 2y ago
    [flagged]
    - ajross 2y ago
      [flagged]
      - withoutboats3 2y ago
        [flagged]
        blinzy 2y ago
        Unbelievable! how bloody rude can you be? To the moderators (dang), do people get to keep their account here just because they're a "famous" poster despite writing the way they're doing all over this post? I'm assuming other posters have been banned for substantially less aggressive behaviour...
  - skavi 2y ago
    > Developers, you among them it seems, don't really understand the requirements of a truly async process and get confused trying to shoehorn it into a "callbacks with context switch" framework like rust async. This is an odd thing to say about someone who has written a correct solution to the problem which triggered this discussion. Also, you really need to define what truly async means. Many layers of computing are async or not async depending on how you look at them.
- throw10920 2y ago
  > Again you are wrong. A forum full of people who just like to hear themselves talk. I guess it makes you feel good in some way? This is why people don't like the Rust community.