From Node.js To Go, Why One Startup Made The Switch

> Falter said she knew how to write JavaScript and thought she could use that background to learn Node.

Knowing some Javascript, I would run away as fast as possible from the prospect of using it on a server (especially if it comes to using the callback pattern to represent concurrency).

> It was also free [...]

Aren't most development languages for general back-end work? Maybe .net isn't...? I haven't checked. But it seems a bit like they just wanted to add another item to the list.

Most of these "we switched from X to Y" stories seem to boil down to Brooks' "plan to throw one away" dictum. In year zero, the technical team of a startup is never going to really understand the requirements and constraints they'll be facing in year three (or even year one). The best you can hope for is to be flexible enough to tear out and replace pieces as you go, and to not have an ego about your original design.

It seems to rarely be the case that it would have been a better idea to build with Y in the first place. In any case, even if you had a crystal ball and could predict your year-four, millions-of-users design in year zero, it'd probably be a mistake to try to build it from the start. The needs of a product (and team) in its infancy are a lot different from those of a mature one.

Google Cache: http://webcache.googleusercontent.com/search?q=cache:http://...

Edit: I was having trouble reaching the page.

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.

If you are looking for an alternative to Node check out Nimrod. If you just don't like nested callbacks in Node then check out ToffeeScript.

FYI Node is actually compiled so it might perform better than you think. Also it has threads with the module webworker-threads. Node is kind of memory hungry.

Nimrod lets you write clean Pythonish code that is as fast as C and even can interface extremely easily with C libraries if necessary.

I wonder what the outcome would have been, if their engineer had spent the weekend rewriting the backend in Node, instead of Go. We all know that the codebase tends to grow ugly when multiple developers keep adding in code and hacks. A complete rewrite might have surprising results, just like it had with their Go rewrite experience.

While I'm a little unclear on some of her reasoning, Go does excel at these kinds of web backends. I'm using it for my startup and have found it very productive to code in, efficient in computing resources and ridiculously easy to deploy and manage.

TL;DR we switched from one buzzword to another.