5 ms·

For the benefit of any who are not sure what you are talking about, could you please elaborate on what some of these "better ways to handle that" are? It would

by nocman 11y ago

For the benefit of any who are not sure what you are talking about, could you please elaborate on what some of these "better ways to handle that" are? It would make your comment much more helpful, IMHO.

spankalee 11y ago
Blocking threads. People associate threads with shared-memory concurrency, which can be really hard to deal with, but shared heaps are not the important part - blocking is. Blocking threads means that all your functions can call each other, all control flow constructs just work, and debugging is sane. With blocking threads functions don't need to belong to a special class of async functions that in general need to be called from other async functions. It would have been great if node invested in allowing many concurrent blocking JS threads. To see what that could have looked like, see Dart's Fletch project: https://github.com/dart-lang/fletch https://github.com/dart-lang/fletch
- spion 11y ago
  Now that we have ES6 generators, this is much less of an issue.
  - spankalee 11y ago
    Generators don't help with the sync/async split. Generators are just iterators, and are synchronous. The consumer asks for a value with next() and the value must be computable (even if that value is a Promise). If you have an async function (one that returns a Promise or in the future a Stream), and you need to call it from a sync function, and somehow incorporate the future value into the return value of the sync function, you're stuck. You have to async-ify your functions all the way up the call chain. With blocking this isn't a problem. We just need environments that make blocking cheap.
    - spion 11y ago
      In my experience in practice there is no big difference, really, its just a matter of a few keywords. As for "having to change an entire call stack", that just stopped happening after a while. The rule of thumb was that if the function is impure (e.g. relying on mutable state) then it will likely become async, too. That lets me plan ahead.
AdieuToLogic 11y ago
> For the benefit of any who are not sure what you are talking about, could you please elaborate on what some of these "better ways to handle that" are? While I am not certain what the GP specifically references, I can say that about 40 years ago the Actor model[1] was officially documented. The literature documenting benefits of an Actor model over a callback approach are easily found. For understanding the pain which callback-based systems often produce, a person can familiarize themselves with the Win32 API (disclaimer: this is a masochistic exercise not recommended for anyone). 1 - https://www.cypherpunks.to/erights/history/actors/AIM-410.pdf https://www.cypherpunks.to/erights/history/actors/AIM-410.pd...
- pdpi 11y ago
  Even if you don't go the actor route, if you're going to use continuation passing style as much as Node wants you to, having a language with better CPS support would be much nicer
coldtea 11y ago
Anything other: blocking in an Erlang like system, actors, CSP, real continuations, async/await, etc.
- sanderjd 11y ago
  What are the differences between what you reference as "actors" and "CSP"?

by nocman 11y ago

spankalee 11y ago

Blocking threads. People associate threads with shared-memory concurrency, which can be really hard to deal with, but shared heaps are not the important part - blocking is. Blocking threads means that all your functions can call each other, all control flow constructs just work, and debugging is sane. With blocking threads functions don't need to belong to a special class of async functions that in general need to be called from other async functions. It would have been great if node invested in allowing many concurrent blocking JS threads. To see what that could have looked like, see Dart's Fletch project: https://github.com/dart-lang/fletch https://github.com/dart-lang/fletch

spion 11y ago
Now that we have ES6 generators, this is much less of an issue.
- spankalee 11y ago
  Generators don't help with the sync/async split. Generators are just iterators, and are synchronous. The consumer asks for a value with next() and the value must be computable (even if that value is a Promise). If you have an async function (one that returns a Promise or in the future a Stream), and you need to call it from a sync function, and somehow incorporate the future value into the return value of the sync function, you're stuck. You have to async-ify your functions all the way up the call chain. With blocking this isn't a problem. We just need environments that make blocking cheap.
  - spion 11y ago
    In my experience in practice there is no big difference, really, its just a matter of a few keywords. As for "having to change an entire call stack", that just stopped happening after a while. The rule of thumb was that if the function is impure (e.g. relying on mutable state) then it will likely become async, too. That lets me plan ahead.

AdieuToLogic 11y ago

> For the benefit of any who are not sure what you are talking about, could you please elaborate on what some of these "better ways to handle that" are? While I am not certain what the GP specifically references, I can say that about 40 years ago the Actor model[1] was officially documented. The literature documenting benefits of an Actor model over a callback approach are easily found. For understanding the pain which callback-based systems often produce, a person can familiarize themselves with the Win32 API (disclaimer: this is a masochistic exercise not recommended for anyone). 1 - https://www.cypherpunks.to/erights/history/actors/AIM-410.pdf https://www.cypherpunks.to/erights/history/actors/AIM-410.pd...

pdpi 11y ago
Even if you don't go the actor route, if you're going to use continuation passing style as much as Node wants you to, having a language with better CPS support would be much nicer

coldtea 11y ago

Anything other: blocking in an Erlang like system, actors, CSP, real continuations, async/await, etc.

sanderjd 11y ago
What are the differences between what you reference as "actors" and "CSP"?