3 ms·
That's interesting. I am going to reason about this. It's me thinking aloud here. I already know that JS callbacks and promises are somewhat equivalent to con
by _nalply 6y ago
That's interesting.
I am going to reason about this. It's me thinking aloud here.
I already know that JS callbacks and promises are somewhat equivalent to continuations. A continuation is something which is to be done later and which is passed as a value to functions which then directly or indirectly invoke the continuation or not if it is decided not to do the thing encapsulated in the continuation (for example if something failed and the algorithm is trying to bail out such that it doesn't make sense to continue with the continuation).
I also know that JS async/await is equivalent to generators. Koa version 1 used generators and Koa 2 switched to async/await.
I also know that Rust futures are or were based on generators. Rust generators are not stable and the last time I looked they were a bit left behind by futures. For me it seems that futures rely on some compiler magic such that they work even if generators are not stable.
Therefore Rust futures are somewhat equivalent to continuations.
There's a difference as far as I know, however. Continuations seem to be strictly more powerful than generators. In other words, you can implement generators by continuations but not the other way around.
- aidenn0 6y agoSorry, I made an ambiguous comment. I meant continuation as in "continuation passing style" not as in "first class continuation" It looks like the proactive IO in Bastion is using Rust's async/await, which I know nothing about, but in most languages async/await exists as sugar to make CPS look like linear flow.