6 ms·

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

29 points by koolhead17 12y ago

StandardFuture 12y ago
Google Cache: http://webcache.googleusercontent.com/search?q=cache:http://thenewstack.io/from-node-js-to-go-why-one-startup-made-the-switch/ http://webcache.googleusercontent.com/search?q=cache:http://... Edit: I was having trouble reaching the page.
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
ilaksh 12y ago
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.
- rohamg 12y ago
  Nimrod is not even at 1.0; not an option for a production scale application.
- andybak 12y ago
  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.
notduncansmith 12y ago
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.
rdtsc 12y ago
> 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 12y ago
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.
iterative 12y ago
Too bad they screwed up again. Maybe they'll eventually get it right and switch to Clojure.
zik 12y ago
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.
randunel 12y ago
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.
mathetic 12y ago
TL;DR we switched from one buzzword to another.

29 points by koolhead17 12y ago

Google Cache: http://webcache.googleusercontent.com/search?q=cache:http://thenewstack.io/from-node-js-to-go-why-one-startup-made-the-switch/ http://webcache.googleusercontent.com/search?q=cache:http://... Edit: I was having trouble reaching the page.

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

ilaksh 12y ago

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.

rohamg 12y ago
Nimrod is not even at 1.0; not an option for a production scale application.
andybak 12y ago
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.

notduncansmith 12y ago

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.

rdtsc 12y ago

> 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 12y ago

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.

iterative 12y ago

Too bad they screwed up again. Maybe they'll eventually get it right and switch to Clojure.

zik 12y ago

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.

randunel 12y ago

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.

mathetic 12y ago

TL;DR we switched from one buzzword to another.