3 ms·

"errbacks" definitely have benefits since having the error parameter forces you to think "where should I handle this error". With exceptions, people often get s

"errbacks" definitely have benefits since having the error parameter forces you to think "where should I handle this error". With exceptions, people often get sloppy and let them be thrown and handled wherever, often at the wrong place. Now it does make code more verbose since 90% of the time, the answer to "where should I handle this error" is "not right here" and with go/errbacks, you have to be explicit in that case while it is the default for exceptions. For Javascript, I recently wrote a module that allows you to jump between styles very easily: https://github.com/bessiambre/casync#readme https://github.com/bessiambre/casync#readme

phpnode 6y ago
The benchmarks in that library are misleading - by wrapping the resolve in the promise example in a process.nextTick you're actually making the engine enqueue 2 microtasks, as promises are always guaranteed to be async. If you remove the process.nextTick the results are reversed, I get: - 63ms (async) - 100ms (casync) so it's almost twice as slow as native async await in this example.
- BenoitEssiambre 6y ago
  The main reason for this library has to do with simplification more than performance but just for the sake of argument, in my little benchmark, the point was to make the asynchronous operation identical in both tests. You can use promises without any asynchronous operation inside but what's the point? That's not how they're used most of the time. And sure promises may add a second microtask around the asynchronous code (casync does too in some cases) but that is to their detriment performance wise (and do promises really add a second microtask when the code inside is already asynchronous?). Also note that async has the benefit of language level integration and optimization. It gets to use v8 c++ functions like "EnqueueMicrotask" instead of process.nextTick. If casync had access to all this, it would likely run even faster.

phpnode 6y ago

The benchmarks in that library are misleading - by wrapping the resolve in the promise example in a process.nextTick you're actually making the engine enqueue 2 microtasks, as promises are always guaranteed to be async. If you remove the process.nextTick the results are reversed, I get: - 63ms (async) - 100ms (casync) so it's almost twice as slow as native async await in this example.

BenoitEssiambre 6y ago
The main reason for this library has to do with simplification more than performance but just for the sake of argument, in my little benchmark, the point was to make the asynchronous operation identical in both tests. You can use promises without any asynchronous operation inside but what's the point? That's not how they're used most of the time. And sure promises may add a second microtask around the asynchronous code (casync does too in some cases) but that is to their detriment performance wise (and do promises really add a second microtask when the code inside is already asynchronous?). Also note that async has the benefit of language level integration and optimization. It gets to use v8 c++ functions like "EnqueueMicrotask" instead of process.nextTick. If casync had access to all this, it would likely run even faster.