It's hard to make a great analysis because there's no hard data on the memory used, the code creating that memory use or their infrastructure. But if I may, due

It's hard to make a great analysis because there's no hard data on the memory used, the code creating that memory use or their infrastructure. But if I may, due to them being less than forthcoming, I'd like to speculate. Anger many, please a few. If they needed something better than Node they may simply be doing it wrong and I'd lean that way first before subscribing to Go being the solution. Which has me thinking it's the most convenient band-aid nearby. There are alternatives to the language/platform hopping. My case would be a decent example. Most of my stuff is in Python2. I have a newer Django project that I'm vetting CPython3 with, but will remain writing long running CPU intensive services in Python2 on PyPy. I see CPython + PyPy as a pretty reasonable approach and have been able to scale quite well for most situations which don't involve battling millions of concurrent users and petabytes of real-time data analysis. There's also the advantage of a single language backend and developer productivity. Node.js callbacks never matched gevent or Python3's async I/O and Go is adding yet another language to the stack where PyPy (or Node in their case) would likely handle it. Difficult to say without looking at how they've implemented everything but I have doubts whatever they're doing couldn't be done with resourceful coding. Most likely, these are people who want an excuse to try something else and they're just excited. Given the self-professed extremity of their case, Node, Python, Go, et al would not resolve something so seriously memory-bound well enough that it wouldn't be worth calling out to a non-GC'd library. I would steer away from GC-anything and drive a stake through the heart. Writing a small limited-scope Rust extension to do what they needed and called that from Node.