
We switched to Node.js: the good and the not so good - julien
http://blog.superfeedr.com/nodejs-powered/
======
davidw
> What we liked the most of Javascript was the fact that it’s an asynchronous
> language ‘by default’.

That's not strictly true - a "while (true)" will lock up a Node process as far
as I can tell. I think a more accurate way of stating it would be that
"Javascript API's and libraries tend to be written with asynchronous use in
mind", with lots of callbacks.

If you want something that's async at a deeper level, Erlang is worth a look.

~~~
StavrosK
Will a "while True" not lock up an Erlang thread?

~~~
exo762
There are no reasons to use busy waiting in Erlang. Ever.

~~~
davidw
while(true) would be pretty bad form in a Node program too, and doesn't
_actually_ seem to be a big problem in practice for people.

~~~
rdtsc
It is a magnitude easier in Node to block the whole OS process by doing
anything CPU intensive. In Erlang, if not using C-bindings, there is nothing a
single Erlang process can do to block the whole runtime.

------
jondot
I am using a mix of Ruby, Node and Java in production but after some hard-
learned lessons chose to minimize the Node usage to things I absolutely need.

My experience with the Node community:

\- Great people (Substack!)

\- Great attitude #node.js/freenode

\- However, many hours spent on solving bugs in existing libraries.

My experience with maintaining production Node code:

\- It may be more maintainable than EventMachine, but it's absolutely not more
maintainable than Ruby.

\- V8 garbage collection is a real pain when you do work that needs it (this
also includes memory held by open sockets).

\- Was V8 built for the server? (rhetorical)

In the end, I prefer threaded Ruby code to evented Node code. I try to offset
the inefficiencies of "threads vs evented" or "Ruby vs Node" by using the JVM
and JRuby.

~~~
danenania
It seems needlessly limiting to make EventMachine and Node your only
candidates. Since you've already got java in the stack, what about clojure?
What about go?

~~~
jondot
I used the examples from the original article. I think the OP ported an
EventMachine code to Node.

When I said 'Java' I really meant JVM. Specifically I'm using Scala.

Regardless, I have a different Clojure based project, with it as well, I
prefer doing what clojure has to offer in terms of concurrency (pmap, etc).

I have dipped a toe in Go. Loved the fact that you get a compiled binary,
ecosystem still feels skinny. Ended up concluding that in a year or two it'll
be worth revisiting.

~~~
continuations
If you're already using Scala, why do you need Node?

What does Node give you that a Scala async framework like Play or Scalatra
doesn't?

Also what does Ruby give you that Scala doesn't?

Just wondering why do you choose to use 3 stacks (Ruby, Scala, Node) when one
could be enough.

~~~
jondot
I'll also try to address sandGordon's question.

Like superfeeder, I have "backend" services, but I also have client-facing
services.

I value how Node.js handles slow clients. It also services some more 'utility'
use cases for me, such as reverse proxies, etc.

JRuby and Scala cover IO bound processing for me over the Web.

JRuby covers the majority of the backend services.

I use Scala coupled with Storm, and I could have used JRuby here too, but you
can also use JRuby with Hadoop and you typically don't. Since this use case
actually required the optimization (I wasn't prematurely optimizing), I went
as bare metal as possible (ruled Java out, yes). Previously, this service was
a Node.js service and got rewritten into Scala+Storm.

I don't use Akka because I didn't feel it was needed yet. Old school threaded
workers with JRuby works fine so far.

I know that Scala is supposed to be a multi-layered solution and it can handle
all of this.

However, Ruby and Node brings the ecosystem Scala doesn't have (I'm not moved
by the "but Java has a million Jars out there" argument, already integrating
with them with JRuby).

And in general Ruby makes me happy (SBT makes me very very angry and sad, for
comparison - yet Scala is OK), that simple.

------
DoubleCluster
> It terms of performance, we also have seen a significant (about 25%) bump in
> terms of feeds processed by second per server.

They rewrote the entire codebase and obtained for just a 25% gain? It doesn't
sound like they are very happy to be coding in javascript now either.

Everyone: please don't rewrite your code, it's almost never worth it. The one
exception is rewriting a core part of an algorithm in C for speed (the last
10x speedup).

~~~
julien
Well, the reason we rewrote was not to explode all benchmarks. The reason we
rewrote was to be able to ease the maintenance of our code =)

~~~
mukundmr
from a long term maintainability perspective, javascript can be notorious. you
could always follow a disciplined approach for development to help with
maintainability, but that applies to all programming languages. i don't see
anything about javascript that makes it more maintainable especially for large
projects.

~~~
julien
It's not the language, it's the people, the community.

~~~
necrodome
what's different about node community from ruby community? are you sure that's
not confirmation bias?

~~~
julien
Well, again, most of the dependencies we used in Ruby did not see any update
in the 3 years we've been using them. We also reported several bugs in those
libraries/dependencies which were never fixed. This led us overtime to use our
own branch of all the significant dependencies we had (including the MySQL gem
for EM, the redis gem... and several other key ones).

Most of node modules are still in active development. As I've stated in the
blog post, that's a pro and con, but we estimated that the pro was greater
than the con :)

~~~
LargeWu
What leads you to believe all of these node modules that you now have
dependencies on will still be in active development in 3 years?

~~~
mgkimsal
They might not be, but that doesn't matter as much as being able to report
bugs and have them fixed _now_ , while people are still actually
developing/fixing things.

------
antihero
Say I'm a Python developer and I'm looking to write services that are fast.
Would I likely be better off going down the route of node.js, Go, Haskell,
Erlang? I mean they are all fantastic languages and I've dabbled in most of
them but from what I've read, Go seems to be the best one to use if you don't
want to shake your world up, but if you do, Haskell or Erlang are nice new
paradigms to dive into. Is this true?

~~~
pilgrim689
Erlang has decades of use in fast, robust, large telecommunication systems.
Haskell promises more robustness than any other platform as well as
performance sometimes comparable to C. Its downside is just that steep
learning curve though.

So if you want speed, I'd go for those two out of your list. Go and node.js
are still infants in the game, so I don't think there is enough serious
software out there built with these to properly judge their effective speeds.

~~~
codygman
I agree that Erlang is probably the best example of proven to be robust due to
use in large telecommunication systems. I would also agree that Go and Node.js
are still infants in the game, but I'd argue that there is enough software out
there to judge Go's effective speeds.

\- Google is using it internally, where speed is an absolute requirement

\- Vitess, recently open sourced (and used internally by youtube) would
definitely have to be fast for the task youtube is using it for.
(<http://code.google.com/p/vitess/>)

\- Desktop window manager in Go that is very fast even on lower spec machines:
<https://github.com/BurntSushi/wingo>

Just my two cents. I would absolutely stay away from node.js if you are in an
environment where people touching the code aren't easily accessible, since
it's very easy to write javascript that only you understand. The other
languages seem to punish it a bit more, while at times it feels as if
javascript embraces it.

------
niggler
The complaints were summarized well by Crockford
<http://www.crockford.com/javascript/javascript.html>

Most of the people writing in JavaScript are not programmers. They lack the
training and discipline to write good programs. JavaScript has so much
expressive power that they are able to do useful things in it, anyway. This
has given JavaScript a reputation of being strictly for the amateurs, that it
is not suitable for professional programming. This is simply not the case.

------
nicholassmith
I tried Node, because it was the new hotness and trying new things is great.
It was distinctly Not For Me, for many of the same reasons that they've found;
many tutorials are out of date in subtle ways (I like to think of this as the
Rails effect from way back in the good old fun days), the language is just
painful to structure and read over for my syntax processing.

There's definitely a lot to like, and like they said it's still a very new
world with a lot of exploration to be done.

~~~
blacktulip
I have not tried Node (or in fact JS as a whole) yet. But it seems very hard
to avoid JS in these days. I am going to learn it in a few months. Can anyone
give me a rough idea how bad it is? (I know some Obj-C so is JS worse than
that?)

~~~
PommeDeTerre
Coming from Objective-C first, which is generally a rather sensible language,
I think you'll be surprised at how stupid, unnecessary and inexcusable many of
JavaScript's problems are.

People who only have a PHP background, for instance, have become accustomed to
such stupidity. They think it's "normal", solely because they don't really
know any better.

Those coming from C, C++, Java, C#, Ruby, Python or most other languages, on
the other hand, know that the JavaScript way is not the right way. These
people generally have a much harder time coming to terms with JavaScript's
numerous issues.

~~~
pkorzeniewski
It's not that JavaScript is a bad language, it's just easy to write bad code
in JavaScript. I don't get it why most people coming from languages you
mentioned like to bash JS so much, I used most of these languages in the past
or use them currently (mainly Java and Python) and I like JavaScript the most.
The problem is most people just don't want to learn JS, they write shitty code
because it's easier and than complain how bad the language is. Sure, there are
many issues with the language itself, usually because of how flexible it is,
but for almost every issue there is a 'good way' of dealing with it.

~~~
mattmanser
Unless you are lucky enough to work on only your own code, that it's so easy
to write bad code is a massive problem.

My big beef with js is that there's no 'right' way to lay out your code.
Trying to figure out how a js module works is always a unnecessarily massive
pita.

------
CoffeeDregs
I like JS and I like NodeJS, but I'm more of an integrator-coder and prefer
frameworks, so I miss things like Django, South, mature ORMs, etc. Though I
did somewhat overcome this hurdle, I particularly hurt for a migration library
when building a NodeJS project (we did find a decent one, but it was young,
immature and not well documented, so it took 10x the time to get comfortable
working with it and then it lacked lots of features). I also missed the
availability of batteries-included API libraries such as Tasty-Pie and Django-
Rest-Framework. Again, it's not hard to code up a few URLs for a model, but
then ... HATEOS ... default REST stuff ... JSONP support ... etc.

I do look forward to switching to NodeJS and I am _fairly_ early adopter...
but it's still been too early for me.

