Hacker News Reader

Comment by anonymoushn | Hacker News Reader

What are you going to do in Javascript, though, if the I/O takes some time to happen? In golang or lua or whatever I can say "this execution context should block on the I/O for x seconds, then give up and return an error." (the other tens of thousands of execution contexts can keep going)

In Javascript I would probably do... the same thing? But I would do it using promises?

View on HN

You can do something like this (using Bluebird's Promise.delay for convenience):

    // using Promise.race so whoever finishes first wins
    var fetchingWithTimeout = Promise.race([
      
      // first promise: actually try to perform the computation
      fetching,
      
      // second promise: wait x seconds, then reject
      Promise.delay(x*1000).then(Promise.reject('Timed out')),
      
    ]);

You can apply the timeout wherever you want (or apply different timeouts in different corners of the app) without throwing out the raw promise to perform the computation no matter the time cost.

Yeah, that would work. My question is really whether I should prefer this over a sequential API that does the same thing, and why. "Does the same thing" here includes the property of "not blocking an OS-level thread".

Some Promise library add support for things like `.timeout` so you can force a promise to reject if the promise takes too long to resolve.

In cases like a node.js server, Promises allow a single node instance to handle thousands of concurrent requests because the event loop isn't blocking waiting for a single IO request to complete, the process can happily do lots of other things while Promises are pending.

Yes, I expect Promise libraries to support timeouts.

So it's right that promises allow me to do the same thing I would do with sequential code in other languages? If I had the option of using coroutines when would I choose to use promises?

Edit: I'm asking because the context of this thread is that one person said that sequential APIs for asynchronous operations, such as open(2), are pretty nice, and someone else said no they're not pretty nice and we should explicitly deal with the asynchronous nature of operations like open(2) by NOT writing sequential code there.

If you have promises OR you have coroutines, your life is good. Either way, you don't have to choose between writing fragile sequential code and writing error-prone synchronization logic.

If you don't have either, then you'll probably end up re-implementing one or the other eventually anyway.

Reply on news.ycombinator.com