4 ms·

Many people are complaining that the standard library still uses callbacks and so even though you have async/await, you can't use it with the standard library.

by norswap 10y ago

Many people are complaining that the standard library still uses callbacks and so even though you have async/await, you can't use it with the standard library. I wholeheartedly agree. I don't understand why someone hasn't build a compat library that simply promisifies all the standard library (it isn't that big), taking the edge cases into account.

rco8786 10y ago
There are like 10 of those, fwiw.
spion 10y ago
Because the standard library doesn't really have that many callback based functions. The more important issue here is that Promises are seen as fundamentally incompatible with post-mortem debugging due to their empty-the-stack requirement: https://promisesaplus.com/#point-34 https://promisesaplus.com/#point-34 If the stack is emptied when handling an exception, the context in which that exception happened is completely lost, so its not clear how to get the process to dump a core that contains meaningful information regarding the problem. This is whats currently blocking node from fully switching to promises. Apparently many companies that have influence in node core rely heavily on post-mortem debugging and don't find the situation acceptable.
- jcheng 10y ago
  Both Q and bluebird promises optionally support long stack traces, albeit at a performance hit. And in practice even old style callbacks often (usually?) empty the stack.
  - spion 10y ago
    No, old style callbacks don't empty the stack on thrown errors - they crash. Long stack traces are fine, but post-mortem debugging means analyzing the entire program's core dump. That includes everything that was in the heap at the time, and not just the names of the functions on the stack but also their arguments (which often point to stuff in the heap). It can be used to reproduce most of the program state at the time of the crash. The real problem is that at some point node decided that throw = programmer errors = core dump. This is wrong and misguided, but thats another story...
Hurtak 10y ago
From my experience majority of async functions that I used are from the fs package and for that, there is nice wrapper called fs-promise (1) which converts all the functions from callbacks to promises. For other stuff, I just create my own promise wrapper (if I feel like that promise interface would be better), which is like 5 lines of code. [1] https://www.npmjs.com/package/fs-promise https://www.npmjs.com/package/fs-promise
alleycat 10y ago
Promises are coming: https://github.com/nodejs/node/pull/5020 https://github.com/nodejs/node/pull/5020
ilaksh 10y ago
There are multiple that do that. `mz` is the most popular I know of.

by norswap 10y ago

rco8786 10y ago

There are like 10 of those, fwiw.

spion 10y ago

Because the standard library doesn't really have that many callback based functions. The more important issue here is that Promises are seen as fundamentally incompatible with post-mortem debugging due to their empty-the-stack requirement: https://promisesaplus.com/#point-34 https://promisesaplus.com/#point-34 If the stack is emptied when handling an exception, the context in which that exception happened is completely lost, so its not clear how to get the process to dump a core that contains meaningful information regarding the problem. This is whats currently blocking node from fully switching to promises. Apparently many companies that have influence in node core rely heavily on post-mortem debugging and don't find the situation acceptable.

jcheng 10y ago
Both Q and bluebird promises optionally support long stack traces, albeit at a performance hit. And in practice even old style callbacks often (usually?) empty the stack.
- spion 10y ago
  No, old style callbacks don't empty the stack on thrown errors - they crash. Long stack traces are fine, but post-mortem debugging means analyzing the entire program's core dump. That includes everything that was in the heap at the time, and not just the names of the functions on the stack but also their arguments (which often point to stuff in the heap). It can be used to reproduce most of the program state at the time of the crash. The real problem is that at some point node decided that throw = programmer errors = core dump. This is wrong and misguided, but thats another story...

Hurtak 10y ago

From my experience majority of async functions that I used are from the fs package and for that, there is nice wrapper called fs-promise (1) which converts all the functions from callbacks to promises. For other stuff, I just create my own promise wrapper (if I feel like that promise interface would be better), which is like 5 lines of code. [1] https://www.npmjs.com/package/fs-promise https://www.npmjs.com/package/fs-promise

alleycat 10y ago

Promises are coming: https://github.com/nodejs/node/pull/5020 https://github.com/nodejs/node/pull/5020

ilaksh 10y ago

There are multiple that do that. `mz` is the most popular I know of.