The Way of the Gopher: Making the Switch from Node.js to Golang

m3.medium only has 1 core.

Long live Node.js!

As everyone has mentioned this seems to be a simple case where the rewrite is a completely different architecture, which could have been done in Node.js.

I'm interested in why this continues to happen.

Seems like Node.js is a victim of its own simplicity. The baked-in non-blocking concepts of Node.js makes everyone feel like single-threaded is the only way to go, and think that Node.js is inherently flawed when it comes to parallelization.

Because Go doesn't give you a simple and relatively scalable solution without even thinking about it like Node.js does, instead you have to choose what to parallelize and think about the problem more. With PM2 scaling Node.js over CPUs becomes incredibly trivial.

Also, I think programmers naturally like rewrites/starting from scratch, and a new programming language provides an opportunity to rewrite everything (which the OP from this article and every other "switcher" article seem to do).

Recently I rewrote a medium sized Websocket app from Node to Go. Hoping for better performance and having heard a lot of good about Go.

Since the application relies heavily on sharing resources between sockets I found out the hard way that concurrent programming in Go is not much easier than in Java. Sure, it has a better syntax and channels but compared to Node where you never have to think about things like these the complexity is way higher.

Long live Node.js!

Meanwhile Facebook is enjoying working with a large PHP code base. When asked they say they can write code that takes time to compile that runs fast in C++ or write code fast in PHP that runs slower. Writing features faster gives them they edge. They have an engineering team that does nothing but optimize PHP. For them an optimization is an acre of servers saved. They if something needs to run blazing fast can write code in assembly language.

What I'm told about Node is the JavaScript is running in a single thread but all I/O is being passed to native code which is written in C++ and running on multiple threads. It does use all the CPUs.

> Node.js on the other hand doesn't need any marketing/propaganda; it just sells itself.

If Node.js used language X,Y,Z instead of Javascript, it would certainly not have been the success it was. "Javascript on the server" was the marketing/propaganda . Nodejs came at the right moment, Js was exploding, websockets were exploding, coffeescript and co were exploding in popularity.

What Go does better than Nodejs is a better standard library, true concurrency, static typing. With Go it doesn't matter if an operation is blocking or non blocking, that fact can totally be abstracted from the client code. Writing callbacks is tedious, promises are tedious, co routines with yield need plumbing and async isn't in the spec.

> you're probably not qualified to manage this project at scale - Because scaling across multiple CPU cores is kids' play compared to scaling across multiple machines

With Node.js any heavy computation needs to be launched in a separate process, which is not the case with Go. sure you can have one/2/4/8 process dedicated to heavy computation, but it will still be the bottle neck. In the end you'll have to use a different language in order to solve the single threaded problem.

Finally there is no mystery as to why some businesses are moving from Node.js to Go: They didn't need anything Node.js provides at first place. They didn't need to use javascript, they didn't need to write "universal" applications with the same logic running in the client and in the server, they didn't need single threaded async programming.

Go is not a silver-bullet, but I was a bit sick of having to write a callback every time I wanted to make an http request, just to prototype something.