4 ms·

Unfortunately, due to JavaScript's single-threaded nature, you don't get what I consider to be the most useful part of Futures on other languages: ability to bl

by nimbix 14y ago

Unfortunately, due to JavaScript's single-threaded nature, you don't get what I consider to be the most useful part of Futures on other languages: ability to block on async calls while work happens in a different thread. In JS, if an async operation rears its ugly head into your synchronous code, you're still in for some rewriting.

domenicd 14y ago
I'm not sure the two are related. The reason you need to rewrite your code in JS is because it lacks coroutines of any sort. That's not related to blocking using threads. As a concrete demonstrate, in ECMAScript 6, which has generators (= shallow coroutines), you'll be to do transforms like this: function logUserName() { var user = getUserSync(); console.log(user.name); } // oh no, getting a user became async! var logUserName = Q.async(function *() { var user = yield getUserAsync(); console.log(user.name); }); Note that the language is still single-threaded, and `getUserAsync()` doesn't block execution. A vivid example of this is at http://taskjs.org/ http://taskjs.org/.
- munificent 14y ago
  Generators haven't bought you much here. This example isn't realistic because logUserName() is screwing over its caller. It has no way to report errors, nor can the caller tell when the operation has completed. It's just fire and forget (and hope it was successful). A better logUserName() would let the caller handle that either by taking a callback or returning a promise. But now you've passed the buck to the caller. And now it has to be async too, all the way up the callstack. This is the worst thing about async code regardless of whether its callbacks or promises: going to sync to async requires you to transform all code all the way up the callstack.
  - domenicd 14y ago
    The second `logUserName` does return a promise. And yes, you always have to keep inserting `yield` all the way up the stack; you can't "hide" the asynchronicity. I think this is good. It's important to explicitly call out the asynchronous points of execution in your code. But at the same time, the only transformation you end up needing to do is inserting `yield`.
CoolGuySteve 14y ago
YES. Can we just give these poor js programmers threads and queues and concurrency and be done with it. Not for their sake, but so that I can finally stop reading strange rants about strange semantics every time a new half-feature makes it into webkit/firefox. Also, fix the semicolons. Apparently that's a thing.

by nimbix 14y ago

domenicd 14y ago

I'm not sure the two are related. The reason you need to rewrite your code in JS is because it lacks coroutines of any sort. That's not related to blocking using threads. As a concrete demonstrate, in ECMAScript 6, which has generators (= shallow coroutines), you'll be to do transforms like this: function logUserName() { var user = getUserSync(); console.log(user.name); } // oh no, getting a user became async! var logUserName = Q.async(function *() { var user = yield getUserAsync(); console.log(user.name); }); Note that the language is still single-threaded, and `getUserAsync()` doesn't block execution. A vivid example of this is at http://taskjs.org/ http://taskjs.org/.

munificent 14y ago
Generators haven't bought you much here. This example isn't realistic because logUserName() is screwing over its caller. It has no way to report errors, nor can the caller tell when the operation has completed. It's just fire and forget (and hope it was successful). A better logUserName() would let the caller handle that either by taking a callback or returning a promise. But now you've passed the buck to the caller. And now it has to be async too, all the way up the callstack. This is the worst thing about async code regardless of whether its callbacks or promises: going to sync to async requires you to transform all code all the way up the callstack.
- domenicd 14y ago
  The second `logUserName` does return a promise. And yes, you always have to keep inserting `yield` all the way up the stack; you can't "hide" the asynchronicity. I think this is good. It's important to explicitly call out the asynchronous points of execution in your code. But at the same time, the only transformation you end up needing to do is inserting `yield`.

CoolGuySteve 14y ago

YES. Can we just give these poor js programmers threads and queues and concurrency and be done with it. Not for their sake, but so that I can finally stop reading strange rants about strange semantics every time a new half-feature makes it into webkit/firefox. Also, fix the semicolons. Apparently that's a thing.