4 ms·

does this mean anything for NodeJS programmers that rely on an existing promise library (eg Q)?

• PhrosTT 13y ago
  Well presumably this makes it's way into V8 and therefore node. I'd assume the performance is better than Q. The biggest issue for me is Q's habit of hiding errors despite me defining a Q.onerror handler. Hopefully a native implementation would fail a little louder.
  • iamwil 13y ago
    I've had this issue with Q and when. Sometimes, things would fail inside a then chain, and then I can't figure out where exactly it failed, because though it fell through a couple thens, I'm not sure exactly where it came from, or how it got that way.
    • stu_k 13y ago
      Have you tried setting Q.longStackSupport = true ? This is invaluable for debugging (although it does slow things down a lot, so don't use it in production)
      • spion 13y ago
        Yep, and this is exactly why its so nice to have promises built into the language. That way, the implementing engine could provide long stack traces for them as well as extra inspection and tooling of all currently pending async operations - and it could do that at the lowest possible performance cost.
• zoips 13y ago
  Q contains some helper functions for creating generators, tying them to a promise, and automatically starting the generator, eg Q.async(). I've found that I'd rather continue using Q and use Q.async()/Q.spawn() rather than dealing directly with the generators and managing them.