|
|
|
|
|
|
by jonpress
4166 days ago
|
|
|
Gophers love to quote TJ Holowaychuk to justify choosing Go over Node.js. In my eyes, TJ is a traitor - If he preferred Go, that's fine - He could just go ahead and use it as he likes, but he wrote a post completely debasing Node.js without pointing to any real, concrete issue. I bet he is still using Node.js from time to time - The 'Goodbye' article is obviously just a stunt. He probably cashed out! I read somewhere that he got a decent sum for his Express framework. I would be interested to know who else is behind this. |
|
|
If I'm building a strictly server-side app using Express, it's a joy to use Node.js (especially for a prototype) - everything more or less works, and the NPM ecosystem is rich and broad. Very easy way of getting a RESTful JSON API up-and-running from FooDB.
If I'm building a client (web scraper, getting stuff out of an API to load into R, etc.) then I really quickly run into "Too Much Concurrency" TM with Node. I quickly find myself building something with Go (or Ruby) to do the following:
- Limited Number of workers
- Automatically re-try request N number of times if fails, depending on response code
- Log all successes/failures
- Throttle total # of requests/second based on site-specific rate limiting
To make the above work in Node, I have to use caolan's async + Q promises + other libraries (or write in Icedcoffeescript, which I like but is very weakly typed and has inferior tooling) and find myself refactoring most of the small script just to fit into the async libraries. With Go, I can use mutexes or simple channels to control throttling, and do whatever I want with errors. There's a lot of boilerplate to get the above up-and-running robustly for Node, or at least that's been my impression the last few times that I've used it. Node has solutions for advanced concurrency (Generators, promises, CSP libraries), but why reinvent the wheel when Go has that out of the box?