
To boldly go where Node man has gone before - jgrahamc
http://blog.jgc.org/2012/05/to-boldly-go-where-node-man-has-gone.html
======
moocow01
If there is one thing I've learned its to ignore benchmark tests on relatively
established technologies.

You'll drive yourself into the looney bin if you hop from one thing to the
next based on these comparisons that inevitably popup every month or so.

If you enjoy programming in JS with Node use it - if you enjoy programming
with Go use it. Your enjoyment will far outweigh performance differences that
will be minor in 99% of real world cases.

~~~
guscost
I use Express, because I can make and host a fast web page in 3 minutes, and
if I ever come across those fabled unsolvable "scaling problems" I can abandon
whatever needs to be rewritten without a second thought. Admittedly this is
usually for promotional media and assorted small projects, but it still works
great.

------
xxbondsxx
Choosing Node.JS isn't just a performance / scaling decision for me -- one of
the main draws to Node is the huge community and wealth of awesome modules.
Socket.io, Now.js, cradle, redis, and dozens of other modules abstract away
the tedious work and let me build functionality _really_ fast.

Go is really promising but it won't win over the majority of casual developers
until there's a community around it. I might as well write a webserver in C if
I'm only concerned with performance

~~~
paufernandez
As we are commenting here, the community is assembling by the minute... Go
allows you to import "github.com/user/package" and will download and compile
the code, so creating a new project is even easier than with node, no need to
"npm install ..." first.

For a taste of what's out there, see: <http://go.pkgdoc.org/index>.

~~~
jlarocco
The GitHub thing was neat the first time I saw it, but then I thought about it
some more, and I'm not sure it's such a good idea.

I couldn't find any way to specify a specific tag or revision, so it's
basically always getting the bleeding edge developer build of the library
code. That might be nice in some situations, but for getting work done I
almost always want the most recent _stable_ release.

Am I missing something?

~~~
paufernandez
If I wanted a specific tag or release, I would just download that revision in
the GOPATH directories, and refer to the package directly, instead of through
the github URL.

~~~
ConstantineXVI
Kind of a clunky way to handle versioning though. In Lein (for example),
adding

    
    
        [noir "1.2.0"]
    

ensures I'm always grabbing the same version. In Go, appears the only way to
guarantee this is to check in the full source of the library alongside your
own in your repo.

~~~
jamii
I wish Leiningen would also handle bleeding edge dependencies as easily as
rebar eg:

    
    
        {deps, [
          {quoted, "1.0.3",
            {git, "git://git.corp.smarkets.com/quoted.erl.git", {tag, "1.0.3"}}},
          {proper, ".*",
            {git, "git://git.corp.smarkets.com/proper.git", {branch, "master"}}}
        ]}.

~~~
ConstantineXVI
This plugin[1] looks like what you're looking for.

[1] <https://github.com/tobyhede/lein-git-deps>

~~~
jamii
"You will also need to manually add the checked-out project's dependencies as
your own (the plugin simply checks out the code, it doesn't recursively
resolve dependencies)."

I've seen this plugin before but its not particularly useful without
dependency checking. It's a start though. I'll have to look at leiningen to
see if it exposes hooks for that sort of thing.

------
arturadib
Node is popular not only because it's very fast (yes, it's still pretty darn
fast even if there might exist faster alternatives), but because it's
JavaScript.

That's an enormous advantage for startups as (a) the JavaScript hiring pool is
much larger than most other languages (particularly in comparison to nascent
ones, like Go), and (b) the ability to write client- and server-side code in
the same language means small teams can be far more integrated and
collaborative than otherwise (and if the startup has a single coder, the point
is even stronger).

Assuming these benchmarks are accurate and translate into similar results for
more complex applications, I'd gladly pay the 10-20% performance penalty to
get the above benefits. Node is fast enough for most startups.

~~~
virmundi
I've heard the JavaScript developers are easy to find argument before.
However, good JavaScript developers are really hard to find. Especially when
you need them to take those skills and run them on the server.

There is a big difference between a jQuery hack and a good JavaScript
developer.

~~~
antihero
Exactly, I just see the PHP problem repeating itself. Yes, you can get a PHP
developer for £7/hour, but are they going to write good code? Unlikely.

------
blantonl
I consider myself a pretty conservative developer when it comes to the tools
that I use, and mainly stick to the core LAMP stack for my deployments -
MySQL, Apache, PHP etc. I've ventured down the path with MongoDB and currently
use it for one special use case where the data served is static.

But for Node - I've really come to the conclusion that it is a great tool for
back end API work, such as serving very short requests, Ajax calls, etc.
Couple the ability to develop in Javascript while serving JSON makes Node a
really nice place to develop in.

Plus, performance is off the charts for my API serving applications. On a dev
instance I can serve close to 5500 reqs/sec for one of our APIs where PHP was
at about 1000 req/sec. And the difference in memory usage is fantastic.

BTW, our production Node deployment is Node, with the memcache, mysql, mysql-
pool, cluster, and express modules. I've been thrilled so far.

~~~
sciurus
Out of curiosity, how were you running PHP?

------
shazow
My favourite thing about posts like these is the little comparison snippets
between a framework I already know (Node) and a language I want to learn (Go).
This is very educational, and the benchmarks are the cherry on top. Thank you.

------
veemjeem
I'm sure the reason why users pick node is probably similar reasons why one
picks ruby/python -- it's not for the speed.

The language of the web is javascript. Until web browsers allow Go as the
embeddable language, node will remain useful. I seriously doubt people would
pick Go over node because of a micro-benchmark.

~~~
kbd
> The language of the web is javascript. Until web browsers allow Go as the
> embeddable language, node will remain useful.

Do people really get that much code re-use between client and server that
using Javascript on the server provides a large benefit?

~~~
tomjen3
For small apps, no.

For complex ones yes. The actual code shared may not be that much, but
consider the advantages in sharing validation code between the client and
server -- you never accidentally forget one requirement on the server side,
leaving you vulnerable to an attack.

~~~
moe
_consider the advantages in sharing validation code between the client and
server_

Is there a _mature_ implementation of this yet?

One that is not tied to an entire immature framework (meteor) or programming
pattern (nowjs)?

Code-reuse was the big promise of node. Yet in reality I've never seen it
executed beyond brittle experiments.

Where is the form_for_model() function that emits code for both the client and
the server?

~~~
reissbaker
Template compilation being able to happen on either the client or the server
is a huge win for anyone writing webapps, and it's trivial to write view code
that can be compiled in both Node and browsers even without a framework.

In other languages, even if you write completely logicless views in a
templating language that can compile in the browser like Mustache, you'll end
up duplicating your presenter code if you don't use a language that browsers
can understand.

~~~
moe
_and it's trivial to write view code that can be compiled in both Node and
browsers even without a framework._

Nonsense. It's far from trivial to have the same code get binding and
validation right on both sides. That's why it needs to be wrapped in a _thin_
abstraction, which apparently nobody in the node-community has been capable of
writing.

Instead we see dozens of rails-clones (oh, exciting..), and a handful of very
half-baked full-stack universes that are nowhere near production ready.

------
kbd
So does Go's net/http module really provide basically exactly the same
programming model as Node? If so, why use Node?

One thing the author didn't mention is that Go will use multiple cores in this
example, whereas Node is single-threaded. Right?

~~~
chc
> _So does Go's net/http module really provide basically exactly the same
> programming model as Node? If so, why use Node?_

Well, for starters, Go is much more awkward for working with JSON than JS is
(which is to be expected since JSON is literally a subset of JavaScript). More
importantly, Go lacks the ridiculously vibrant ecosystem for Web development
that Node has — no NPM, no Connect, no Jade, no Stylus, etc.

~~~
paufernandez
'npm' is covered by the Go tools themselves. You can import packages using
their github/bitbucket/code.google.com URL.

~~~
chc
That is really interesting. Thanks for pointing that out. Can you specify
specific version dependencies like you do with a full-blown package manager?

~~~
BarkMore
After 'go get'ing the package, you can use git/hg/bzr to checkout the specific
version you want. From there, all of the Go build tools will work as normal.

------
ilaksh
I think that actually the Node example was significantly simpler.. there were
no pointers, and no types needed to be specified. Also I can use CoffeeScript
with Node. The only way Go is easier to write is if you know Go but don't know
Node. I say its easier to learn and use Node/Javascript.

I am surprised that Node performed so well.. I would like to see that same Go
benchmark with 4 CPUs vs. Node and also vs. Node with a clustered web server
and the code to see how much more code that involves for clustering with Node.

Also I would like to see some Go code and benchmark that reads a file and/or
database in the request and works efficiently.

Actually the code for a Node cluster that would use all of the available CPUs
for http in CoffeeScript would look like this:

    
    
        cluster = require 'cluster'
        http = require 'http'
    
        numCPUs = require('os').cpus().length
        if cluster.isMaster
          cluster.fork() for i in [1..numCPUs]
        else
          app = http.createServer()
          app.on 'request', (req, res) ->
            res.end "hello world\n"
          app.listen 8000
    

Maybe someone could take V8, change it so it compiles (immediately) to static
code and uses CoffeeScript, and add a way to optionally specify types (in an
unambiguous and readable way) and pointers only when you have to.

------
riobard
Just want to point out one obvious thing that I found very interesting: that
the V8 JavaScript engine which makes Node exist in the first place comes from
the same company which makes Go.

~~~
cageface
Google's Robert Griesemer, who worked on the V8 VM, is one of the main
contributors to Go.

------
adestefan
Are we now going to have a run of posts that tweak a stupid micro-benchmark?

------
robertpateii
This test shows Node handling 100 requests simultaneously just as easily as
handling them separately.

However Go's memory usage increases by about 5X.

So what happens when you reach 1000 simultaneous requests? Which will perform
better then?

I think this is called "selection bias."

~~~
reissbaker
Not only that, but Node actually got faster as simultaneous connections
increased while keeping a completely stable memory footprint. The benchmark
showed the opposite of what the author claimed -- Node scaled effortlessly.
Its performance was completely stable and predictable under load, whereas Go's
wasn't.

Not to knock Go -- it's a beautiful language, and absolutely faster than
Javascript for most purposes (and will no doubt increase in stability and
speed as time goes on). But this post had some pretty flawed analysis of the
benchmark presented.

~~~
supersillyus
FYI, the original article has been updated with graphs showing reqs/sec,
virtual, and real memory for both using 100, 500, and 1000 simultaneous
requests. Aside from virtual memory (do we care about that?) it seems to show
Go as continuing to perform better.

~~~
robertpateii
Ah, great. That's a good update. Go does end up responding well at 1000
concurrent requests for real memory. But a spike in virtual memory means it's
paging all that extra data, right? Doesn't that normally slow things down?
what's interesting is Go still maintains a similar requests per second.

of course, for a front end guy, Node is still the most exciting thing on the
block simply because it is server-side javascript. The fact that it's not much
worse than the latest greatest compiled language is pretty exciting to me.

~~~
supersillyus
I don't think the spike in VM means it's paging all that. That just means it
has that address space reserved, not that it's using it. I'm not aware of any
real cost to having a huge pile of address space reserved, aside from that
some monitoring utilities will penalize you for it (unreasonably). So, no, I
don't think it'll slow anything down by thrashing, unless the locality of the
memory it is accessing is really bad, but I'm no expert on Linux virtual
memory or how Go uses it.

------
cageface
Static typing + no callbacks make Go vs Node a no-brainer, IMO. I'm doing
mainly iOS work these days but I've been brainstorming ideas that require a
server component just so I can use Go for something.

~~~
lachenmayer
What do you mean by "no callbacks"?

~~~
cageface
You can do non-blocking I/O without the nested callbacks you have to use for
everything in Node. You just fire off a block to a goroutine and then code
sequentially there.

~~~
zoips
In the short term:

<https://github.com/laverdet/node-fibers>

In the long term:

<http://wiki.ecmascript.org/doku.php?id=harmony:generators>

~~~
jerf
No, and no, respectively. Hacked together libraries to sort of support rewrite
it at the wrong level of the stack (the compiler should be doing the
continuation transform, anything else will lack performance due to having to
jump through a lot more hoops) and merely having generators is not the same
thing. And _neither_ solution you propose will give you _true preemptive
multitasking_. Do you know how you fire off a long computation in Go or
Erlang? You just do it. No marshalling, no blocking, no dealing with OS
processes, no fuss.

Neither of those two things are new ideas. Python has had generators forever.
If it solved the underlying problems, Go would never have been written.

------
bdr
The point of Node is that it uses JavaScript, and browsers only speak
JavaScript. You have three choices: (1) use Node, (2) duplicate code client-
and server-side, or (3) use server-side code that compiles to JS. Right now 3
is the least popular (and 2 is the most) but I think it will end up being the
accepted solution in a couple years.

~~~
josephcooney
Or use a plug-in in the browser that speaks your language of choice.

------
exogen
"Easy to build, fast, scalable."

So which part of the test demonstrated that it was hard to build, slow, and/or
not scalable?

If you're not impressed that JavaScript reached 80% parity with a statically
typed, compiled language – well, sorry dude.

Anyway, nobody is begging you to be impressed. 99.999% of successful projects
are built with technology that is completely unimpressive.

------
david_k
I can personally vouch for the maturity of Node especially Socket.io. We're
building a web-based email client that relies heavily on real-time
communication with a Node-based email importer. See <http://philterit.com>.
I've found Node to be faster and more lightweight than Rails 3, which we
initially used for our prototype. With JavaScript being the lingua franca on
the client-side, specializing in it as a team has permitted us to master it
and offer a far better user experience.

~~~
tinyjoe
Nobody is comparing Node with Assembly. sigh

------
tluyben2
I pick Node because it's easy to move code from backend to frontend and back.
I find this very comfortable while creating and testing software.

------
exogen
If you consider something to be fast and scalable (e.g. Go), then something
with ~80% of the throughput (e.g. Node in this test) is probably also pretty
fucking fast and scalable. Scalability and performance don't walk fine lines
like that; there's a reason we talk about orders of magnitude.

------
jorangreef
Any language faster than Javascript would be fine if it worked in the browser.

------
euroclydon
Good God man, your iPhone theme is awful! I tried to pan the screen to view
all the results and it navs to the next blog post?!?

------
christkv
you know what both platforms are great, I'll use them both thank you.

