Why I’m staying with Node
First and foremost, a big hat-tip to T.J. for announcing his ground-breaking news and farewell to Node.js in favor of using Go. When someone fights with something long enough, they will move on, and in his situation, use the “right tool for the job”
That’s cool. And you can’t not respect that. Duder is awesome and smart.
As for me, I’m staying with Node.js. We still have a rough future ahead of us. But I bet on JavaScript a long time ago, and alas, like English — it’s everywhere.
The problems that T.J. points out with Node.js are very similar to the problems we have in English, metaphorically speaking of course. Error handling is natively error prone, callbacks are harder than regular synchronous transactions, errors, errors, errors. We make grammar mistakes all the time in English, but for the most part, we all understand each other, and have known solutions to fix those mistakes.
Just for fun-sake, if JavaScript is English, then Go would be Hawaiian. Simple, small, effective, less error-prone, less well known, and on its own island. And for that matter, I guess that makes Java, German. I’ll stop.
Anyway, metaphors aside, and rather than tit for tat comparing the nooks and crannies of Go vs. Node — there are several other good reasons to continue using Node.js
Web Applications
With Node you can literally share your code between the front and back of a system. Website’s I’ve worked on such as Change.org, OpenLikes, even the one you’re reading this article on share utilities, models, views, testing libraries, even routing logic because of Node. This of course leads to more DRY applications, a principle of programming that is highly desired for maintainable applications.
Recruiting
Due to the mass popularity of JavaScript, everyone knows it — at least a little. Hiring for Go — I wouldn’t even know where to start. And as an aside, this is a personal problem, but nevertheless, a problem I can avoid by simply sticking with Node. Node and Go are roughly the same age, but JavaScript is 19 and moved out of the house. Programmers who have known JavaScript for years with zero Node experience can quickly get acclimated without hassle
Right tool for the job
Like all things, it depends. If it’s a complex intelligence algorithm that requires high concurrency — sure, something besides Node can be fine… as a service… that I can call from Node. As far as measuring concurrency and speed between Go and Node, it would the equivalent of comparing whether a for loop performs better going backwards or forward. These kind of microbenchmarks don’t appeal to me. When choosing a programming language or framework or library, always consider the ROI for your product and how effective you’ll be between your users, your team, and yourself.
The Moral
I don’t want this to be a very long retrospective — So, similar to TJ’s advice — there are lots of awesome solutions out there; pick one you will do well in and will ultimately make your users, company, and yourself happy.
