
From Node.js To Go, Why One Startup Made The Switch - koolhead17
http://thenewstack.io/from-node-js-to-go-why-one-startup-made-the-switch/
======
rdtsc
> 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.

------
djur
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.

------
StandardFuture
Google Cache:
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://thenewstack.io/from-
node-js-to-go-why-one-startup-made-the-switch/)

Edit: I was having trouble reaching the page.

------
notduncansmith
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.

~~~
Oculus
Rather then _" the founder made a poor technical choice"_, I think she made
the best possible decision at the time (fastest to market). The change over to
Go gave the company an excuse to rewrite their codebase which always gives
great improvements relative to hacked together code.

~~~
notduncansmith
There usually is something to be gained from rewriting something from scratch
(wouldn't say _always_ ): better understanding of the problem domain, what
works and what doesn't, etc. I can't help but think though, that if they had
made a better choice in the beginning, they wouldn't have had to resort to
that.

Beyond that, "fastest to market" doesn't appear to be the case for this
particular company. They do surveys and social media analytics. Both of which
have been done (many, many times) before. I don't mean to disparage the team
or the product when I say this by the way, nothing wrong with trying to build
a better mousetrap. It just doesn't appear (on the surface) to be particularly
disruptive or groundbreaking.

------
ilaksh
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.

~~~
andybak
Nimrod looks quite interesting but the tutorial has a disturbing penchant for
ugly variable names and dune horrific use of Hungarian notation.

If it's hoping to lure in Pythonistas then there are a few strange aesthetic
choices in there.

------
randunel
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.

------
zik
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.

------
mathetic
TL;DR we switched from one buzzword to another.

