4 ms·

Yet another example of async Rust being a source of unexpected ways to shoot yourself in the foot... Async advocates can argue as long as they want about "you'r

Yet another example of async Rust being a source of unexpected ways to shoot yourself in the foot... Async advocates can argue as long as they want about "you're holding it wrong", but to me it sounds like people arguing that you can safely use C/C++ just by being "careful".

speed_spread 2y ago
Async has its uses, but there should also be a way to ensure that a Rust stack does not use async at all, like there is for unsafe. Most codebases could do without the added complexity. There will be better ways to do concurrency in the future (hehe)
- dboreham 2y ago
  Agree. If people want to delude themselves that async is useful, that's fine. But don't inflict it on the rest of us by viral propagation throughout the dependency ecosystem.
  - vacuity 2y ago
    I claim that async/await is far more basic (/fundamental/simple, not necessarily easy) than most acknowledge, but it should indeed be more composable with sync code. It is a means of interacting with asynchronous phenomena, which underlie the OS-hardware connection. The composability is necessary because no one is going to write a massive state machine for their entire program.
    - int_19h 2y ago
      Part the problem is ABI. Fibers are a more sensible approach to async, but as soon as you introduce them, FFI becomes a massive pain (see e.g. Go) in any environment which doesn't have fibers as a first-class primitive that everybody supports. Promise-based async has the advantage that you can desugar it down to C-compatible ABI.
      - vacuity 2y ago
        I think the promise-based model is the ideal model. After reading [1], I'm convinced that it's very close to realizing the underlying state machine ([2]) of the program, and I find that valuable. I agree that fibers are easier to use, but not simpler. I understand that my hard-line approach is not practical everywhere, but at least the async model used by Rust is not just a concession to the C ABI and whatnot, but an important model in its own right. So I think that it is quite sensible, if not practical for most programmers to make sense of :). Add fiber abstractions on top if appropriate, of course. [1] https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html [2] https://lamport.azurewebsites.net/pubs/state-machine.pdf https://lamport.azurewebsites.net/pubs/state-machine.pdf (read the introduction)

speed_spread 2y ago

Async has its uses, but there should also be a way to ensure that a Rust stack does not use async at all, like there is for unsafe. Most codebases could do without the added complexity. There will be better ways to do concurrency in the future (hehe)

dboreham 2y ago
Agree. If people want to delude themselves that async is useful, that's fine. But don't inflict it on the rest of us by viral propagation throughout the dependency ecosystem.
- vacuity 2y ago
  I claim that async/await is far more basic (/fundamental/simple, not necessarily easy) than most acknowledge, but it should indeed be more composable with sync code. It is a means of interacting with asynchronous phenomena, which underlie the OS-hardware connection. The composability is necessary because no one is going to write a massive state machine for their entire program.
  - int_19h 2y ago
    Part the problem is ABI. Fibers are a more sensible approach to async, but as soon as you introduce them, FFI becomes a massive pain (see e.g. Go) in any environment which doesn't have fibers as a first-class primitive that everybody supports. Promise-based async has the advantage that you can desugar it down to C-compatible ABI.
    - vacuity 2y ago
      I think the promise-based model is the ideal model. After reading [1], I'm convinced that it's very close to realizing the underlying state machine ([2]) of the program, and I find that valuable. I agree that fibers are easier to use, but not simpler. I understand that my hard-line approach is not practical everywhere, but at least the async model used by Rust is not just a concession to the C ABI and whatnot, but an important model in its own right. So I think that it is quite sensible, if not practical for most programmers to make sense of :). Add fiber abstractions on top if appropriate, of course. [1] https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html [2] https://lamport.azurewebsites.net/pubs/state-machine.pdf https://lamport.azurewebsites.net/pubs/state-machine.pdf (read the introduction)