4 ms·

Any plans for “stack full” co-routine(go style). IMHO the current “Futures” monad style solution makes the code look a bit confusing.

deleted 8y ago
[deleted]
steveklabnik 8y ago
So, yes and no. Let me lay out the bits for you. The language currently knows nothing of coroutines. So, as you say, you chain Futures together, which is basically a monad. You submit that futures chain to an executor, like Tokio, and it basically moves the chain's stack to the heap, and then executes it. So, in some sense, Tokio is a stack-ful co-routine. It just so happens we know the stack's exact size at compile time, which has some nice properties compared to other stack-ful implementations. Additionally, we have, in nightly, "generators." These are stack-less coroutines. On top of that, we have accepted (and there's a PR open in the compiler to implement) async/await. Async/await de-sugars to the whole Futures-chain shenanigans, but does it via generators. You then take that chain, and submit it to something like Tokio, making it stack-ful. Writing code with async/await is significantly more ergonomic than chaining futures together by hand, and feels more like goroutines, though suspension points are explicit rather than implicit. Generators are likely to eventually be stable as well, so you can also write your own stack-less stuff if you want. But for now, they're an implementation detail of async/await, which has much less of a design surface area, and is what most people will want to do with this stuff, and so has priority. Make sense?
woah 8y ago
I disagree. For the use case of single thread concurrency, async/await is easier to reason about, since you don't have the added abstraction of a separate execution thread (that isn't even actually a different thread). With coroutines comes the added work of deciding when to "fork", and the added work of stringing everything together with channels and mutuxes. I myself learned to program on node.js 6 years ago, when everything required piles of callbacks (the least ergonomic form of async/await style concurrency). It's strange to see a bunch of experienced programmers saying that nobody could possibly use this style, as it is too hard, while millions of beginning programmers master it easily. In fact I remember that the people who usually had a problem with callbacks were those who had prior experience with synchronous languages. Async/await reveals the beauty of this pattern of async, by getting rid of the syntactical cruft of promises and callbacks. It's already awesome in C# and JS, and will be landing in Rust this year. IMO using "thread" patterns should only be done when you actually have something to gain, with real multi core parallelism. The big advantage of coroutines is that they scale seamlessly across cores. By putting the bad ergonomics of threads everywhere, you make your code ready to scale onto actual threads.
- steveklabnik 8y ago
  I don't read your parent as saying that async/await is bad compared to futures, but that futures code right now is tough to write. This is why so many people are psyched about async/await in Rust! One area in which async/await significantly improves over manual futures is borrows between individual futures in the chain. In languages with a GC, this isn't an issue, but it comes up in Rust a bunch. See this for a great explanation: http://aturon.github.io/2018/04/24/async-borrowing/ http://aturon.github.io/2018/04/24/async-borrowing/
  - tatterdemalion 8y ago
    The user specifically asked about stackfull coroutines, which is not the direction we're going. But I think the pain point the user talked about (futures right now are difficult to deal with) will be resolved by our stackless coroutine approach, and more in line with Rust's values around "zero cost abstractions."
    - steveklabnik 8y ago
      That's fair. This space is quite complex, with so so many options. I guess we'll know if and when the OP elaborates with more :) I very well could be wrong.
      - zxcvhjkl 8y ago
        You are both right. I was specifically asking about "stackfull coroutines" as tatterdemalion says, but I stackless coroutines with await/async would be as good for code readability. Thanks for your work btw.
        steveklabnik 8y ago
        No problem! To be clear, my work here is explaining it only; the implementation is entirely other people’s hard work :)

deleted 8y ago

[deleted]

steveklabnik 8y ago

So, yes and no. Let me lay out the bits for you. The language currently knows nothing of coroutines. So, as you say, you chain Futures together, which is basically a monad. You submit that futures chain to an executor, like Tokio, and it basically moves the chain's stack to the heap, and then executes it. So, in some sense, Tokio is a stack-ful co-routine. It just so happens we know the stack's exact size at compile time, which has some nice properties compared to other stack-ful implementations. Additionally, we have, in nightly, "generators." These are stack-less coroutines. On top of that, we have accepted (and there's a PR open in the compiler to implement) async/await. Async/await de-sugars to the whole Futures-chain shenanigans, but does it via generators. You then take that chain, and submit it to something like Tokio, making it stack-ful. Writing code with async/await is significantly more ergonomic than chaining futures together by hand, and feels more like goroutines, though suspension points are explicit rather than implicit. Generators are likely to eventually be stable as well, so you can also write your own stack-less stuff if you want. But for now, they're an implementation detail of async/await, which has much less of a design surface area, and is what most people will want to do with this stuff, and so has priority. Make sense?

woah 8y ago

I disagree. For the use case of single thread concurrency, async/await is easier to reason about, since you don't have the added abstraction of a separate execution thread (that isn't even actually a different thread). With coroutines comes the added work of deciding when to "fork", and the added work of stringing everything together with channels and mutuxes. I myself learned to program on node.js 6 years ago, when everything required piles of callbacks (the least ergonomic form of async/await style concurrency). It's strange to see a bunch of experienced programmers saying that nobody could possibly use this style, as it is too hard, while millions of beginning programmers master it easily. In fact I remember that the people who usually had a problem with callbacks were those who had prior experience with synchronous languages. Async/await reveals the beauty of this pattern of async, by getting rid of the syntactical cruft of promises and callbacks. It's already awesome in C# and JS, and will be landing in Rust this year. IMO using "thread" patterns should only be done when you actually have something to gain, with real multi core parallelism. The big advantage of coroutines is that they scale seamlessly across cores. By putting the bad ergonomics of threads everywhere, you make your code ready to scale onto actual threads.

steveklabnik 8y ago
I don't read your parent as saying that async/await is bad compared to futures, but that futures code right now is tough to write. This is why so many people are psyched about async/await in Rust! One area in which async/await significantly improves over manual futures is borrows between individual futures in the chain. In languages with a GC, this isn't an issue, but it comes up in Rust a bunch. See this for a great explanation: http://aturon.github.io/2018/04/24/async-borrowing/ http://aturon.github.io/2018/04/24/async-borrowing/
- tatterdemalion 8y ago
  The user specifically asked about stackfull coroutines, which is not the direction we're going. But I think the pain point the user talked about (futures right now are difficult to deal with) will be resolved by our stackless coroutine approach, and more in line with Rust's values around "zero cost abstractions."
  - steveklabnik 8y ago
    That's fair. This space is quite complex, with so so many options. I guess we'll know if and when the OP elaborates with more :) I very well could be wrong.
    - zxcvhjkl 8y ago
      You are both right. I was specifically asking about "stackfull coroutines" as tatterdemalion says, but I stackless coroutines with await/async would be as good for code readability. Thanks for your work btw.
      - steveklabnik 8y ago
        No problem! To be clear, my work here is explaining it only; the implementation is entirely other people’s hard work :)