good article! I agree with the last comment "node is great for javascript lovers", which I think says it all. Until now with node, how many js developers had to worry about concurrency or scalability? The fact is node allows the (originally js) developer to do everything he wants in one language, both on the server and browser side. And it works for most sites. If I get 1,000,000 visitors per month, and assume only 16 hrs a day of real activity, that gives me 1,000,000 / 30 / 16 / 60 / 60 = 0.58 request per second. Which is still easy enough for node to handle. I've been programming with Node a lot lately and find it easy since I can use my networking programming knowledge from C in another language I also know well i.e. javascript, but Go might be on the todo list of things to check out next.
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.
Author 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!
> 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.
What a stunningly pointless article. Author writes code to achieve non-useful-goal exactly the same way in 2 languages and discovers that one is faster than the other. Different languages have different methods of efficiently achieving a goal.
I did think about putting in some "useful" code, like encrypting data, but then people would be complaining about the implementation of the crypto libraries. The point was to demonstrate how easy it is to block the Node event loop, and the impact on concurrency.
6 comments
[ 2.6 ms ] story [ 27.0 ms ] threadAfter 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.
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!
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.