11–18 of 18 posts
This looks promising. The syntax is a bit clunky, however. How would this look with Java8 and lambdas?
Earlier quoted context omitted.
Nice write-up. I'm surprised people don't mind chaining together the information flow like this; it feels more like the runtime should do this sort of leg work. I understand why you'd do this on servers, but not as much on clients. Why not tie up a worker thread waiting for these things?
I agree, you're unlikely to feel the need for this when threads are cheap and blocking is OK. (For some client environments, like JavaScript, that's not the case: which is why you see so many similar things in that space, like promises and bacon.js.) Though in some languages the syntax is light enough that it's actually more convenient to do in in the nonblocking style; Scala has a good story here, and C#'s async/awa…
Async/await is beautiful: compiler produces CPS, but logical control flow remains exactly as you'd expect. One slight reservation: the async specifier seems to pollute the entire call tree of otherwise un-related code.
... or just use NodeJS instead.
... or just use NodeJS instead.
I'm curious — how does this deal with errors in async calls? RxJava has error handling built in with `onError` functions.