ioredis just released stable v4. Unless you use the Bluebird Promise switch, you run into an ambiguous error:
TypeError: scripts.updateDelaySet(...).then(...).return is not a function
at node_modules/bull/lib/queue.js:374:18
at runCallback (timers.js:693:18)
at tryOnImmediate (timers.js:664:5)
at processImmediate (timers.js:646:5)
at process.topLevelDomainCallback (domain.js:121:23)
From previous event:
at Queue._initProcess (node_modules/bull/lib/queue.js:362:8)
Any of the examples with "ioredis": "^4.0.0".
3.4.6
I would be careful using ioredis 4.0 until it has been a bit more battletested, but I will leave this open for future reference.
I agree, however I think its also worth talking about how everyone is moving off of Bluebird, and instead making it a fallback (see the way ioredis did it)
As long as bluebird is faster than native promises we should be using it.
I don't think thats true anymore (use to be i know).
Plus there is the arguement of code bloat + versioning (multiple bluebird versions).
All in all, I'd say its best to default to native promises, and allow overriding with bluebird (as an optin like ioredis). That way if it is still more performant, the user's can decide to do so
@chaffeqa bluebird is still fastest, until proven otherwise these are the tests I will rely on http://bluebirdjs.com/docs/benchmarks.html, also we use some features not available in native promises.
These benchmarks suggest native Promises now outperform Bluebird promises and other JS implementations, in that specific performance test, in both speed and memory.
(Not suggesting that it's better in all cases, but I think it might make the speed reason for keeping Bluebird less strong) 馃槃
I made a few benchmarks using native promises in bull instead of Bluebird and it is indeed faster, at least with node 8.11.3. So I think I will replace it, however we still use bluebird for promisification and other small things so we will need to depend on it for some time.
By the time it takes to transfer to native promises, node 10.x will be in LTS :)
Just another datapoint for native promises: https://v8.dev/blog/fast-async
Looks like we will be benefiting a lot from going native by default
@manast Thanks for switching to native promises. However you closed the issue but it looks like you are still requiring [email protected]. Is there another issue to follow upgrade to [email protected]?
Most helpful comment
I don't think thats true anymore (use to be i know).
Plus there is the arguement of code bloat + versioning (multiple bluebird versions).
All in all, I'd say its best to default to native promises, and allow overriding with bluebird (as an optin like ioredis). That way if it is still more performant, the user's can decide to do so