The article was really short and light on details, but the TL;DR of the team's reasoning for switching away from Node.js were: 1. Multiple application layers c

The article was really short and light on details, but the TL;DR of the team's reasoning for switching away from Node.js were: 1. Multiple application layers could not be brought up in tandem. 2. The infrastructure had a single point of failure if the instances went down. 3. All functions of the service ran on a single process. 4. Latency became an issue due to high CPU and network load during peak usage. 5. There was an inability to scale horizontally. The TL;DR for why they shouldn't have used Node.js (IMO, not from the article): lack of experience. Node.js (or even Javascript) is not for beginners. It takes time to write good, solid, maintainable Node apps. Time that a startup doesn't have. It sounds like they just made a poor technology choice for their team. According to the article: > Falter said she knew how to write JavaScript and thought she could use that background to learn Node. I couldn't help but laugh at this part. There's a lot more to being effective with Node.js than knowing Javascript, just like there's a lot more to being effective with Rails than knowing Ruby. One thing (or rather, 5 things) that bothered me about this article were the team's cited reasons for leaving Node. I'd like to address those, in order: 1. I'm not even entirely sure what they mean by this, but if they're talking about operating a service-oriented architecture, then they're flat-out wrong. There's nothing inherent to Node that keeps you from deploying multiple instances doing different things. I've done this several times, in fact, with little hassle. 2. and 3. sound reasonable (ish), but are also problems with any Go architecture I've seen. Hell, most modern server-side tech has this issue, unless you architect around it specifically. Go doesn't appear to have any better answer for this than [Node|Ruby|Python|your_favorite_stack]. 4. Yes, Node is somewhat memory-hungry. However, unless you have a single, monolithic server, this is really a non-issue. 5. This cannot be attributed to anything but the team's effectiveness (or in this case, the lack thereof). Node scales as horizontally as any other technology. You can deploy it to Heroku, AWS, etc all day long. Run as many instances as you want: if they all have the same config, they're all the same app. > As the company scaled, the task of administration became increasingly complex, due to “call-back soup”, a common complaint with Node.js. I've said it a million times: "Promises, 'nuff said". That being said, promises can be difficult to grok on your own, and because they had 0 experience to draw from, this probably wasn't an option for them. No fault on that point, but there are libraries that make managing callbacks fairly easy (not promise easy, but easy). Overall, sounds like the founder made a poor technical choice, and the company suffered. Still, I really hope they have as much fun and success writing Go as I have over the past few weeks (that is to say, quite a bit). EDIT: One tidbit I missed the first time reading the article: > Text processing increased 64 percent just by moving from Node to Go. They could have easily gone with a hybrid structure here. Nothing was stopping them from hosting the text processing part in Go (as a service in their possibly-SOA) and then using Node for the rest. Or, better yet, have a C module that handles the text processing, and call out to that with Node.