2 ms·

I'm very curious about this statement, does anyone know more detail > Futures combinators are not used because the combinator model suffered some specific prob

• withoutboats3 4y ago
  It's exactly the problem that led us to Pin in designing async/await. Futures need to own all of their state. If you want to use that state across multiple combinators (in async/await terms, "across an await point"), given that rust doesn't have GC, you have to somehow make it available to both closures. This meant Arc<Mutex<_>> around things even though they were being used in sequence, because both closures needed to own the state and the compiler doesn't know the closures will only be called in sequence. It was a mess, and was a big hurdle for adoption of futures before async/await was added.
  • tel 4y ago
    That makes sense, thank you. I had been a little confused as I'd seen the combinators available in the futures crate (along with Stream) and it's a little tricky to figure out the status and review of techniques that are implemented there but not standardized.
  • atq2119 4y ago
    All those effects have the same issue, don't they? I've definitely run into situations where I moved from a combinational approach to a control flow based one for iteration because the combinational approach required multiple closures to borrow the same state mutably. It's almost like there's also still some gap in the borrow checking, but it's not obvious to me how to address that.