3 ms·
You forgot one point: After you used all cores on one machine with Go you have to use the another machine with another cores: how do you scale then? You have t
by tferris 14y ago
You forgot one point:
After you used all cores on one machine with Go you have to use the another machine with another cores: how do you scale then? You have to build a cluster similar to Node in Go and at the end you have to manage co-routines + the cluster => Node is easier to scale because you just focus on clustering and not on both threading and clustering.
- bitcartel 14y agoAuthor here. Go is easier. As demonstrated, a single Go process can take advantage of multiple cores on a single machine. With Node you launch multiple Node processes, one for each core, and manage them with the Cluster package. To take advantage of multiple machines, it's pretty much the same for any language or platform, as the cluster of machines will need to be managed by yourself or a third party like Heroku. Except with Node, you not only have to manage a cluster of machines, you also have to manage a cluster of processes on every one of those machines!
- tferris 14y ago> you also have to manage a cluster of processes on every one of those machines! you just set a number of cluster/processes per machine, that's it. there is no dedicated management for clusters on multiple cores. That's the benefit of clustering as scaling method with Node: one method scales on multiple cores and/or multiple machines. Not go-routines and clustering like Go—the application design will be much more coherent instead of using go-routines AND cluster where a reference implementation is missing (but I am repeating myself). > as the cluster of machines will need to be managed by yourself or a third party like Heroku. Rather you should write your own cluster management in Node. You could take some kind of a web server or Heroku that starts all the app server processe per connection but that's old-school.