Hacker News new | past | comments | ask | show | jobs | submit login

Coroutines really are powerful. Here's to hoping Rust stabilizes generators (full semicoroutines, not the enhanced iteration construct) sooner rather than later. It would give programmers greater control to express state machine logic without being boxed into async/await. I do wonder if the `Context` parameter used for async tasks is appropriate for arbitrary generators, so if someone could chime in on this I would be grateful.



Or provide continuations and use them to implement coroutines.


A couple of us have been experimenting with deliminited continuations and I think it’s gonna take off soon in TS

https://youtu.be/uRbqLGj_6mI?si=kgKKjpCnehJ9bpIG

https://github.com/neurosnap/starfx https://github.com/thefrontside/effection/tree/v3


To my understanding, delimited continuations and coroutines are equivalent in power. Out of curiosity, can delimited continuations be implemented as efficiently (in Rust or otherwise) as stackless coroutines?


These don’t look like continuations to me, just ways to use generators? Continuations would involve reifying the current control flow into a value, which these examples don’t seem to do and still rely on generators to yield control.


These libraries rely on deliminited continuations:

https://github.com/thefrontside/continuation

Because of this tiny implementation we are able to express any async flow construct with less code than relying on something like async/await or callbacks.


Single-shot continuations in the form of lexical effect handlers would be a good fit for a systems language nowadays. I feel it's a bit too late to staple that onto Rust though.


I've been using genawaiter[1] for writing generators in Rust. Are there things you can't build on top of async-await? Or is it just that it's simpler without that indirection?

[1]: https://crates.io/crates/genawaiter


I was thinking that the semantics around async/await (function coloring) would make some usages more frustrating. This crate probably sidesteps that, if it is a problem at all. I have a bad habit of not dabbling around when I lack understanding.


This feels circular, since async/await is futures which are generators


I don't think `Context` is appropriate for generic generators, since it has no way to get data in or out of the `async` block. The more general `generator` feature allows a custom context type though.


I must've looked at an outdated design or something. Thanks for the info.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: