3 ms·
I can't help but feel like Google gently encouraged him to promote Go over Node. Or that being told by coworkers (goworkers?) for years-on-end that Go is better
by rmrfrmrf 9y ago
I can't help but feel like Google gently encouraged him to promote Go over Node. Or that being told by coworkers (goworkers?) for years-on-end that Go is better than Node has had an effect. Especially considering he talks about green threads like he's not quite sure what he's talking about. At any rate, there are many innovations where the creators weren't fully aware of their impact and eventually come to hate their own designs, so no love lost there.
- tgtweak 9y agoNode lets you do single thread non blocking. Go lets you do multi threaded non blocking. That's a pretty substantial delta in the server world where you can easily have 24+ cores available. Memory and cpu footprint of go is also drastically lower to node as it is a compiled language. That makes a difference when you are running in a cloud paying per GB of memory and per core. I say this while actively developing in node.
- rmrfrmrf 9y agoThe thing is, in real-world scenarios with databases, http, and regexs, golang and node.js have very similar performance with node beating golang in some cases. Furthermore, not everyone is developing cloud-based apps and trying to optimize for metered cost structures. If you need raw, parallelized, computational power, then I will without-a-doubt agree that Go is a better choice. However, to say that one would always use Go for any server (even webapps? come on...) truly doesn't make any sense. The only other benefit-of-the-doubt explanation I could come up with for such an explanation is that it seems like the creator has spent more time in academia than in "the real world" of development, and perhaps the persuit of "the ultimate async system" is more important to him than practicality.