4 ms·

> We could achieve similar things in Node with generators, but in my opinion generators will only ever get us half way there I wish more people realized this.

> We could achieve similar things in Node with generators, but in my opinion generators will only ever get us half way there I wish more people realized this. Generators seem to be billed (ironically by TJ amongst others with his Koa project) as the solution to callback hell but, having tried Go, I got the same felling that actors are much easier to reason about and debug (although concurrency is still hard). On the client side, web workers allow parallelism but the API is inconvenient to use: you need to have a file for each web worker whereas Go's `go` routines are akin to a function call. In addition to this standardized conundrum, you have browsers discrepancies with the APIs available inside a worker varying between vendors [1]. On node, you have the cluster API, which allows managing several processes so it's even further from light threads. On the bright side, most (all?) APIs have both a sync and async version. As a result, there's nothing you can use for multithreading in a module without coordinating with the whole project. I think JavaScript needs language support for light threads, not APIs for multiprocessing. [1]: https://developer.mozilla.org/en-US/docs/Web/API/Worker/Functions_and_classes_available_to_workers https://developer.mozilla.org/en-US/docs/Web/API/Worker/Func...

iambase 12y ago
Rather than cluster API, I guess you meant child process API but otherwise I agree 100%.
aikah 12y ago
Nodejs could have workers,it's not really a javascript.Node maintainers just didnt implement that stuff. I personnally dont like generators for concurrency.It's the wrong solution to the problem.For now I stick with promises,and I hope JS gets async/await keywords quickly.
- throwaway41597 12y ago
  > Nodejs could have workers Agreed, but what I meant is that the API (running a file in a worker) is inconvenient, first because there is no closure. Go allows the go routine to read variables in scope and has a race detector to tell you when your accesses are unsafe. There's also the issue of managing workers: is a web worker an OS thread or a light thread [1]? how many can you spawn? which worker should you send work to? These problems are solved by Go. I think it would be very hard to obtain the same reliably and performance with today's web workers. Other languages solve this with a language construct, not an API to run another file. > I hope JS gets async/await keywords quickly It would be a step up. But most of the time you want to express a linear list of tasks. Javascript should support this by having a synchronous variant of its APIs and having light threads. My hope is more that some language having such features will compile to asm.js [1]: it's either a thread, a process or an "equivalent construct" http://dev.w3.org/html5/workers/#processing-model http://dev.w3.org/html5/workers/#processing-model

iambase 12y ago

Rather than cluster API, I guess you meant child process API but otherwise I agree 100%.

aikah 12y ago

Nodejs could have workers,it's not really a javascript.Node maintainers just didnt implement that stuff. I personnally dont like generators for concurrency.It's the wrong solution to the problem.For now I stick with promises,and I hope JS gets async/await keywords quickly.

throwaway41597 12y ago
> Nodejs could have workers Agreed, but what I meant is that the API (running a file in a worker) is inconvenient, first because there is no closure. Go allows the go routine to read variables in scope and has a race detector to tell you when your accesses are unsafe. There's also the issue of managing workers: is a web worker an OS thread or a light thread [1]? how many can you spawn? which worker should you send work to? These problems are solved by Go. I think it would be very hard to obtain the same reliably and performance with today's web workers. Other languages solve this with a language construct, not an API to run another file. > I hope JS gets async/await keywords quickly It would be a step up. But most of the time you want to express a linear list of tasks. Javascript should support this by having a synchronous variant of its APIs and having light threads. My hope is more that some language having such features will compile to asm.js [1]: it's either a thread, a process or an "equivalent construct" http://dev.w3.org/html5/workers/#processing-model http://dev.w3.org/html5/workers/#processing-model