3 ms·

> Well, that's just because Node async style is amateur hour BS, like trying to do closures in C or logic programming in PHP. Doable, but not supported by the l

by davedx 14y ago

> Well, that's just because Node async style is amateur hour BS, like trying to do closures in C or logic programming in PHP. Doable, but not supported by the language. Use Go or Dart or Haskell or C# or Scala or Tornado etc for your async needs. If async programming in JavaScript "isn't supported by the language": what good is it, then?

pretoriusB 14y ago
Who said Javascript is good for async programming? It was designed to be easy to use with callbacks for website UI style events (which is not quite the same as async programming). The Node async is just a half-thought implementation of async on top of a VM that doesn't really support it. The thing it has going for it is traction (and some people new to async are amused by the callback style and find it "challenging", whatever). Scala/Dart/Go/Rust/Haskell/etc have a better async story. ES6 will add some promising stuff in the future (no pun intended).
ufo 14y ago
The basic idea of having a framework full of nonblocking async calls for stuff and using simple cooperative threading is a reasonable design decision depending on what you want to do. The problem is that Node forces you to write code in continuation passing style and that is a very "low level" way to write things, missing many of the niceties languages tend to have right now. * If you want an async value you need to give it a name and put it in a callback argument. Instead of `f() + g()` you end up doing `f(function(a){ g(function(b){ ballback(a+b) } ) })` * You need to explicitly tell the order of execution of everything (as shown in the previous example) * It can very laborious to refactor a non-CPS subroutine if part of it needs to become async, specially if you have many loops or call other subroutines. Ideally you shouldn't have to do large "boilerplate" rewrites of your code just because of a small local change. If you are curious what the better alternative for to CPS style is, my opinion is that the way to have the language do the work of breaking the code into the callbacks for you, either via dialects that compile to JS or via features such as generators. While you can get away with many of the very nice async programming libraries out there, they still can't solve all the problems with CPS style (specially the refactoring one)

by davedx 14y ago

pretoriusB 14y ago

Who said Javascript is good for async programming? It was designed to be easy to use with callbacks for website UI style events (which is not quite the same as async programming). The Node async is just a half-thought implementation of async on top of a VM that doesn't really support it. The thing it has going for it is traction (and some people new to async are amused by the callback style and find it "challenging", whatever). Scala/Dart/Go/Rust/Haskell/etc have a better async story. ES6 will add some promising stuff in the future (no pun intended).

ufo 14y ago

The basic idea of having a framework full of nonblocking async calls for stuff and using simple cooperative threading is a reasonable design decision depending on what you want to do. The problem is that Node forces you to write code in continuation passing style and that is a very "low level" way to write things, missing many of the niceties languages tend to have right now. * If you want an async value you need to give it a name and put it in a callback argument. Instead of `f() + g()` you end up doing `f(function(a){ g(function(b){ ballback(a+b) } ) })` * You need to explicitly tell the order of execution of everything (as shown in the previous example) * It can very laborious to refactor a non-CPS subroutine if part of it needs to become async, specially if you have many loops or call other subroutines. Ideally you shouldn't have to do large "boilerplate" rewrites of your code just because of a small local change. If you are curious what the better alternative for to CPS style is, my opinion is that the way to have the language do the work of breaking the code into the callbacks for you, either via dialects that compile to JS or via features such as generators. While you can get away with many of the very nice async programming libraries out there, they still can't solve all the problems with CPS style (specially the refactoring one)