There's a little too much self-congratulatory prose in here. And poor advice (Use NodeJS because its fast).
But there is one take-away at least... design your application around your data and how your users will interact with it and performance will generally fall out of that. And it doesn't take much to start that way rather than leaving it as an after-thought.
People might break out the (oft-misquoted) "premature-optimization" horse for a little beating, but performance does matter. At least the bounds matter for most applications. You might not need to eek out every cache line but you can set targets up-front to say, "We cannot tolerate more than Xms req-to-res time" and bake that into your design.
It's funny you mention node as poor advice... and while I think it would need be replaced at scale, I tend to reach for node first, if only because it's easy enough to prototype something that can scale out, and gets decent per-instance performance. In this case, I'd probably have started with go for the core chat engine, combined with a plan to shard/distribute chat channels, however you want to break them up.
As for pre-mature optimization, for something like this, they should have had a plan to grow, and enough base to be able to handle some early growth. I think falling over once you hit a million or more simultaneous users can happen in a lot of ways. Especially if growth happens faster than you can provision servers/funds.
You can write a fast server in Python 3 that can benchmark well against Node [0].
The author tried to sell us on the idea that Python is slow because Django is slow and you shouldn't use Ruby because Rails is slow. You should just use Node because its fast.
Well I don't know about you but I've seen slow Node applications too.
It all comes down to data. If you really want to maintain your performance goals you have to include them in your design. You have to design for your data. Show me your data and I can write the program. Design it well and you can scale up when the time comes with minimal effort.
Besides there are other factors to consider such as familiarity with the tools, correctness of the implementation, etc. Javascript is great and all but it is incredibly easy to make errors that will go unnoticed until it hits production. The law of large numbers won't protect you if you're used to the blanket of obscurity. And so I find you need many more layers of tooling and choose your subset of the language carefully to maximize its use... something that you don't have to do as much with OCaml or Haskell for instance.
Hence, "just use Node because its fast," is misguided at best. (And I'm not even a Node hater.. I maintain a number of Node applications presently).
Agreed, the reasoning isn't sound... I was just meaning that node is a perfectly serviceable platform, and better than most by design. I've also seen some hideous node apps... generally because people don't really get how it works, and try to do heavy math in the main process.
But there is one take-away at least... design your application around your data and how your users will interact with it and performance will generally fall out of that. And it doesn't take much to start that way rather than leaving it as an after-thought.
People might break out the (oft-misquoted) "premature-optimization" horse for a little beating, but performance does matter. At least the bounds matter for most applications. You might not need to eek out every cache line but you can set targets up-front to say, "We cannot tolerate more than Xms req-to-res time" and bake that into your design.