5 ms·

Whole standard api is still using callbacks so you would need to write your wrappers around it to not use callbacks.. And async/await is not solving anything be

by lossolo 10y ago

Whole standard api is still using callbacks so you would need to write your wrappers around it to not use callbacks.. And async/await is not solving anything because your definitions of fuctions will still need callbacks/promises under the hood anyway (unless you use libraries that do it for you). I like how Go solves that, gorutines and you write your code as it would be normal sync code.

pitaj 10y ago
There is a V8 API to expose Promises directly from native modules, and that can eventually be used to make async functions first-class citizens. async functions using promises and generators under the hood is a good thing because it allows easy usage between the two forms.
- lossolo 10y ago
  This still doesn't solve what I wrote about api, libuv (event loop + IO) that node.js use is also based on callbacks in C, last time i checked discussion about it, there was no plans to change that.
  - Matthias247 10y ago
    That simply won't change, because that's what node.js (and Javascript) is fundamentally about: An EventLoop, with callbacks that are used to handle events. All the promises and async/await are only sugar around callbacks, so they don't change the fundamental model. A Go like model, with lightweight or real threads and no need for callbacks or promises will also need new synchronization mechnanisms in order to handle preemption and waiting which are currently not in scope of javascript, e.g. mutexes, condition variables, etc.
_puk 10y ago
I imagine the likes of Babel currently hide all of this in the Node context, but is there a move to either change the standard API to async/await, or provide a standard mirror API? Either option sounds full of compatibility / maintainability headaches, so how does Node get from its current state of callback hell out the box to async / await? goroutines aren't magically turning async calls into sync, just hiding them deeper "under the hood"; there must be hope for Node.
- lossolo 10y ago
  > is there a move to either change the standard API to async/await From what I remember there was no plans to change that (based on discussion from couple of months ago by node members on github). > Either option sounds full of compatibility / maintainability headaches It is. > goroutines aren't magically turning async calls into sync, just hiding them deeper "under the hood"; there must be hope for Node. Of course it's not about turning code into sync one, it's about coding style to look like it would be a sync one. But in case of Go it was created with this as main language concept, everything was designed around it, scheduling, user space lightweight stacks for gorutines etc.
always_good 10y ago
> And async/await is not solving anything because > your definitions of fuctions will still need > callbacks/promises under the hood anyway The point is that you can write your complex business logic with async/await which is easier to follow and get right. I mainly use it in my routers and database modules. It doesn't need to factor out every .then() or callback from your codebase to be incredibly useful or to fulfill its purpose.
sixbrx 10y ago
For the few std lib calls that I make in web apps, I just use Bluebird to promisify() node style callbacks into promise style code, always worked fine for me.

by lossolo 10y ago

pitaj 10y ago

There is a V8 API to expose Promises directly from native modules, and that can eventually be used to make async functions first-class citizens. async functions using promises and generators under the hood is a good thing because it allows easy usage between the two forms.

lossolo 10y ago
This still doesn't solve what I wrote about api, libuv (event loop + IO) that node.js use is also based on callbacks in C, last time i checked discussion about it, there was no plans to change that.
- Matthias247 10y ago
  That simply won't change, because that's what node.js (and Javascript) is fundamentally about: An EventLoop, with callbacks that are used to handle events. All the promises and async/await are only sugar around callbacks, so they don't change the fundamental model. A Go like model, with lightweight or real threads and no need for callbacks or promises will also need new synchronization mechnanisms in order to handle preemption and waiting which are currently not in scope of javascript, e.g. mutexes, condition variables, etc.

_puk 10y ago

I imagine the likes of Babel currently hide all of this in the Node context, but is there a move to either change the standard API to async/await, or provide a standard mirror API? Either option sounds full of compatibility / maintainability headaches, so how does Node get from its current state of callback hell out the box to async / await? goroutines aren't magically turning async calls into sync, just hiding them deeper "under the hood"; there must be hope for Node.

lossolo 10y ago
> is there a move to either change the standard API to async/await From what I remember there was no plans to change that (based on discussion from couple of months ago by node members on github). > Either option sounds full of compatibility / maintainability headaches It is. > goroutines aren't magically turning async calls into sync, just hiding them deeper "under the hood"; there must be hope for Node. Of course it's not about turning code into sync one, it's about coding style to look like it would be a sync one. But in case of Go it was created with this as main language concept, everything was designed around it, scheduling, user space lightweight stacks for gorutines etc.

always_good 10y ago

> And async/await is not solving anything because > your definitions of fuctions will still need > callbacks/promises under the hood anyway The point is that you can write your complex business logic with async/await which is easier to follow and get right. I mainly use it in my routers and database modules. It doesn't need to factor out every .then() or callback from your codebase to be incredibly useful or to fulfill its purpose.

sixbrx 10y ago

For the few std lib calls that I make in web apps, I just use Bluebird to promisify() node style callbacks into promise style code, always worked fine for me.