

Node.js v0.8.0 [stable] is out - pooriaazimi
http://blog.nodejs.org/2012/06/25/node-v0-8-0/

======
pooriaazimi
:-D I actually set an alarm this afternoon to submit v0.8.0 as soon as it
comes out, if you can possibly believe it ( _I still can't believe I've done
such a low, degenerate thing and am a little ashamed of myself_ )!

But I'm incredibly happy about this release, specially about the 'new' cluster
API[1] that has made my life a whole lot easier! So apologies for being a
karma whore, but I was _so_ glad I couldn't resist, if you know what I mean...

[1]: <http://nodejs.org/docs/v0.8.0/api/cluster.html>

~~~
IsaacSchlueter
I can't believe you managed to get this submitted to HN before I did. That's
what I get for posting it to twitter before coming here ;D Since I knew the
URL, I could have totally cheated and done it before even uploading the blog
post.

~~~
oscardelben
Was there a prize for the first person that posted this?

~~~
aaronblohowiak
what izs has called "Internet Points"

~~~
technomancy
Welcome to HN, the show where everything is made up and the points don't
matter.

------
radagaisus
Make sure you at least got this points correct when trying to upgrade:

1\. require('sys') throws, use require('util') now. The "sys" module was
deprecated in node v0.4.

2.cluster.fork() no longer return a child_process.fork() object use
cluster.fork().process to get the object.

3.the 'death' event on the cluster object is renamed to 'exit'

------
secoif
While the benchmarks look like there's an overall improvement, it's not
instantly clear how much of an improvement they demonstrate. To more easily
parse what the benchmarks are telling us, I calculated the percentage
difference and the results appear really impressive.

Some of the most notable improvements listed below (results rounded, possibly
misleading, but nonetheless awesome).

According to these benchmarks, 0.8 is approximately:

* 43% faster at reading files.

* 119% faster at reading 4096 byte buffers.

* 117% faster at writing 16384 byte buffers.

* 243% faster at http benchmark TYPE=bytes LENGTH=123456

* 506% faster at http benchmark TYPE=unicode LENGTH=55555

Be sure to note the actual figures though, as they are what really matter.

[https://github.com/timoxley/node/blob/ddee8bcda50c8377d135d6...](https://github.com/timoxley/node/blob/ddee8bcda50c8377d135d68923ecac0a29f72173/doc/blog/release/node-v0.8.0.md)

------
jeremiep
This means contracts.coffee (<http://disnetdev.com/contracts.coffee/>) can
finally be used on the stable version of node.js!

------
mjackson
This looks incredible. Congrats to node core on this milestone! I really
appreciate how laser-focused you guys are on code consistency across the
board.

Looking forward to trying out the cluster and domain modules in strata!

~~~
fibertbh
The domain module looks fantastic: <http://nodejs.org/api/domain.html>

"Domains provide a way to handle multiple different IO operations as a single
group. If any of the event emitters or callbacks registered to a domain emit
an error event, or throw an error, then the domain object will be notified,
rather than losing the context of the error in the
process.on('uncaughtException') handler, or causing the program to exit with
an error code."

This will be great for things like request handlers, initialization code and
other "loose" blocks of code where you don't really care about success but you
do care about errors not propogating.

~~~
dtjohnnymonkey
I've been reading back and forth between this post and the docs and I'm still
not really getting it.

Is this just a way of registering a single callback to respond to error events
that could be emitted by different operations? What are some examples when
this would be better than handling error events individually?

Is it sort of like a try/catch for error events?

~~~
IsaacSchlueter
> Is it sort of like a try/catch for error events?

Yes, but it's also sort of like a try/catch for thrown errors.

    
    
        d = domain.create()
        d.on('error', function(e) {
          console.error('an error: ', e)
        });
        d.run(function() {
          throw new Error("whoops")
        })
    

would console.log, rather than crashing the program.

When an EventEmitter is bound to a domain, their error events and any errors
thrown while emitting an event on them will be handled by the domain object
that they're bound to.

------
AUmrysh
Coincidentally, today is the day that I started looking into learning node.
Anyone know some good guides which don't use deprecated code?

~~~
pooriaazimi
It's been a long since I watched "Introduction to Node.js with Ryan Dahl"[1],
but although I think it was circa v0.4.0, it's not _really_ outdated. It's a
short talk, but it talks a little about Node's philosophy and I highly
recommend watching it.

I haven't watched Pedro Teixeira's tutorials[2], but many recommend it.

But I personally think Manuel Kiessling's online book[3] is the best. It
really teaches you to think asynchronously. I took a quick look and I don't
think any of the modules he's used have had a significant change. Be sure to
check it out.

[1]: <http://www.youtube.com/watch?v=jo_B4LTHi3I>

[2]: <http://nodetuts.com>

[3]: <http://www.nodebeginner.org>

~~~
Justen
I just started teaching myself node a couple days ago and just finished with
Manuel Kiessling's online book yesterday. It really is a great tutorial and
helped me a lot. Thanks for the other links, I'm going to check out
nodetuts.com later today.

------
unit_testing
Congrats on the release!

I'd love to take this opportunity to dive into Node, but I have yet to stumble
accross an effective way of organizing medium to large Node projects. What
tools do you guys/gals use?

~~~
tlack
Late response, apologies..

Node is still young, and for its primary use case (multiuser/messaging-
oriented apps) it seems like the actual LoC stays pretty low. However, here
are some things I've picked up in my studies that seemed to make sense to me
as an Express user. Keep in mind I'm still a relative nodenoob, so take this
with a grain of salt..

\- Keep the actual 'route code' (i.e., code that handles your end points) in a
folder, named by the function: i.e., routes/login.js

\- The overall route map (i.e., app.get()) lives in the main app.js file or
routes/index.js

\- Use underscore.js where possible; this raises the cognitive level of your
code and its become a 'standard part' of Javascript to some degree.
Unfortunately the Node repl treats _ as a special value, so you can't really
test with it there. Kinda sucks..

\- Use config.js to contain database settings, default port, middleware
settings, etc.

\- Develop the more complicated parts of your code in libs/. Think of them as
open source components; keep them generic and disconnected from your app
itself. This increases reusability (obviously) and testability. I think it
creates better code overall. Some people even npm the core "hard parts" of
their code! This is a really interesting and freeing strategy.

------
dbau
Yay! This looks great. I'm particularly excited about v0.9x as the current SSL
performance is still a massive issue when it comes to actually running apps in
production (it's SUPER SLOW). It seems that optimising this will be a core
focus moving forward:

 _SSL performance leaves much to be desired at the moment. Node's interface
with OpenSSL is somewhat naive and leaves a lot of potential optimization on
the table._

------
substack
If you want to play with this new version but also have code running on older
versions that hasn't been completely ported yet, I recommend using nave to
manage your node versions. After you `npm install -g nave` you can just `nave
install 0.8.0` to get node 0.8 then type `nave use 0.8.0` to start using it!

<https://github.com/isaacs/nave>

~~~
pooriaazimi
Or 'nvm'[1], or 'n'[2]... All of them are bash-specific so if you're using
'fish' for example (what I really like to), you're out of luck and you must
hack your own.

[1]: <https://github.com/creationix/nvm>

[2]: <https://github.com/visionmedia/n>

------
amix
Does anybody know which optimization was added to V8 to improve the throughput
by so much?

~~~
mraleph
It is hard to say: that's 2642 worth of revisions in V8.

String (unicode) benchmark throughput was definitely greatly affected by
improvements in string handling (both internal operations and writing then out
of V8 heap through the API; V8 also reintroduced string slices to avoid
copying of characters for long substrings).

Other notable things on the compiler front: V8 has switched to a new counting
profiler from statistical one, and now makes slightly different optimization
decisions. There were improvements in functions inlining (including inlining
of constructors). There was some cleanup in invocation sequences for functions
and we enabled type feedback for function calls through local variables on x64
(which opened the door to all optimizations that were dormant at such
callsites: e.g. inlining or direct calls).

Other notable things in the runtime: new GC has landed and was tweaked for
quite some time. Unboxing of double arrays and tracking of smi-arrays (should
not affect node.js though).

I think the only way to see which changes in V8 resulted in throughput boosts
is to get per-V8-revision measurements.

------
nfriedly
Does anybody know the details on cluster.autoFork()?
<http://nodejs.org/api/cluster.html> has it in a couple of examples, but not
documented - is that supposed to be there?

------
tg3
Any ideas how long it usually takes Heroku to add a new release of Node?

~~~
willlll
You can use any version at any time:
<https://devcenter.heroku.com/articles/nodejs-versions>

~~~
exogen
Not quite, I think? That page suggests that you can only use versions in this
manifest: [http://heroku-buildpack-
nodejs.s3.amazonaws.com/manifest.nod...](http://heroku-buildpack-
nodejs.s3.amazonaws.com/manifest.nodejs)

...which doesn't list 0.8.

~~~
randometc
The node.js buildpack has good instructions for how to upgrade it yourself if
needed: <https://github.com/heroku/heroku-buildpack-nodejs> (and the buildpack
docs are now public since Heroku's Cedar stack became the official default)

~~~
tg3
I meant when will they update it so that you can use the new version of Node
without hacking the buildpack. >To change the vendored binaries for Node.js,
NPM, and SCons, use the helper scripts in the support/ subdirectory. You'll
need an S3-enabled AWS account and a bucket to store your binaries in. I don't
want to mess with that, I'd rather wait for Heroku to update so I can change
one line in my package.json.

~~~
aashay
I'm beginning to wonder if Heroku is going to bother with this any time soon.
The default version is _still_ 0.4.7 [1] and personally I'm starting to feel
the pressure to update, especially considering recent performance
improvements.

[1] <https://devcenter.heroku.com/articles/nodejs-versions>

------
obtu
In the announcement: s/in favor of/in place of/, otherwise one can't parse
which array implementation will be picked.

------
louischatriot
Congrats on the release, it looks great!

------
rapind
Gotta love that the homebrew recipe is already up.

brew update

brew upgrade node

~~~
dstroot
Why does brew NOT include NPM? I used the mac installation package instead.

~~~
jherdman
Homebrew doesn't handle software that updates itself. It's an opinionated
piece of software.

UPDATE: More on this here <http://blog.izs.me/post/3295261330/on-npm-and-
homebrew>

------
mgd8
The big difference is the switch from node-waf to node-gyp for native modules.

------
ruethewhirled
Anyone noticed increased CPU usage?

