Hacker News Reader

Comment by thrush | Hacker News Reader

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

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.

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.

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)

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.

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.

Reply on news.ycombinator.com