4 ms·
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
by mattgreenrocks 13y ago
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?
- bkirwi 13y agoI 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/await seems perhaps even cleaner.
- mattgreenrocks 13y agoThat's what pains me about JS: there's this meme of being unable to use threads, but it's OK, because threads are bad and scary. Thus, promises must be good. 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.