Node.js v0.8.0 [stable] is out(blog.nodejs.org)
blog.nodejs.org
Node.js v0.8.0 [stable] is out
http://blog.nodejs.org/2012/06/25/node-v0-8-0/
59 comments
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.
Now, quickly release 0.8.1 and make sure you beat everyone ;)
Joke aside, thanks for the great new release. I'm running 0.6 in production sometimes with 3000+ connected users and will soon need to scale. Being able to do so just by upgrading to 0.8 will make my life easier... until many more users come, of course.
Joke aside, thanks for the great new release. I'm running 0.6 in production sometimes with 3000+ connected users and will soon need to scale. Being able to do so just by upgrading to 0.8 will make my life easier... until many more users come, of course.
You got to give him props, he set an alarm to post it lol.
Isaac said it would be out in 15:00 UTC, and it was out in 15:00 UTC... I was studying for my exam, my alarm went off and bam! There's the blog post - It was amazing.
Was there a prize for the first person that posted this?
You're probably missing some necessary context here: Isaac is the maintainer of Node.js. So the funny thing is that pooriaazimi was so excited to post this to Hacker News that he beat the project's own maintainer to the punch.
Of course not. Just a few seconds of joy, that our favorite platform has reached another milestone...
I posted the above comment to say I was really happy and all (and I wasn't trying to be an ass) - I wish people would stop upvoting that stupid, non-constructive comment (for some reason, it has 10 upvotes).
I posted the above comment to say I was really happy and all (and I wasn't trying to be an ass) - I wish people would stop upvoting that stupid, non-constructive comment (for some reason, it has 10 upvotes).
what izs has called "Internet Points"
Welcome to HN, the show where everything is made up and the points don't matter.
Wrt the Cluster module, the autoFork method is mentioned a couple of times in the code examples, but isn't documented. Does it actually exist?
Yeah, that looks like a bug in the docs. It does not actually exist. https://github.com/joyent/node/issues/3532
[deleted]
Anyone have a TLDR on what new functionality has been added to cluster? I skimmed the API and the changes didn't jump out.
If you mean changes between 0.7.15+ and 0.8.0, nothing really significant. But if you mean changes between 0.6.x and 0.8.0, well, almost everything has changed!
Sorry for the non-answer... But take a look at https://github.com/joyent/node/wiki/API-changes-between-v0.6... and https://groups.google.com/d/forum/nodejs-dev for change log (in 0.7 branch).
Sorry for the non-answer... But take a look at https://github.com/joyent/node/wiki/API-changes-between-v0.6... and https://groups.google.com/d/forum/nodejs-dev for change log (in 0.7 branch).
Ah, thanks!
Read the blog post. It has a TLDR
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'
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'
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...
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...
This means contracts.coffee (http://disnetdev.com/contracts.coffee/) can finally be used on the stable version of node.js!
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!
Looking forward to trying out the cluster and domain modules in strata!
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.
"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.
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?
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?
> 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.
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.
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")
})
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.
Thanks! It is marked experimental, and we really do mean that. The API won't change in 0.8, but it probably will change somewhat in the next stable release. Please try it out and let us know what you think, especially in what ways it is lacking, how it actually helps or hurts in real apps, etc.
That description at the start of the docs is unhelpful.
After scanning the rest of the docs I get the impression that domains are weak containers for resource cleanup (not just IO), paired with an error handling context.
After scanning the rest of the docs I get the impression that domains are weak containers for resource cleanup (not just IO), paired with an error handling context.
Coincidentally, today is the day that I started looking into learning node. Anyone know some good guides which don't use deprecated code?
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
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
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.
Shameless self plug:
http://danielnill.com/blog/nodejs-tutorial-with-socketio/
Not a full tutorial, but hopefully a decent intro for those looking to learn the ropes.(I would love to hear feedback good or bad)
Not a full tutorial, but hopefully a decent intro for those looking to learn the ropes.(I would love to hear feedback good or bad)
Oh, and of course, if you don't mind paying for a video tutorial, the latest Peepcode screencasts look promising:
https://peepcode.com/products/full-stack-nodejs-i
https://peepcode.com/products/full-stack-nodejs-ii
(Don't purchase the old ones. They're desperately outdated. These two were published recently and use the latest APIs.)
https://peepcode.com/products/full-stack-nodejs-i
https://peepcode.com/products/full-stack-nodejs-ii
(Don't purchase the old ones. They're desperately outdated. These two were published recently and use the latest APIs.)
codeschool has a fairly profound introductory course
Tekpub has a course on node, it's fairly recent (I think it has been around for 3 months, give or take). The Tekpub site was rebuilt in node as well and the videos talk a little bit about somethings Rob Connery encountered during the process. The series taught me a lot, but my only other exposure was the peepcode video.
http://tekpub.com/view/node/1
http://tekpub.com/view/node/1
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?
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?
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.
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.
One thing to note is that there is no standard library. Most of your code will be dealing with modules. The most important thing is to get those dependencies right. Node comes with node package manager (npm), which is a great tool for the job. Still, be aware that you might be dealing with a lot of moving parts. Any tool that helps you with this should be worth checking out.
You should also check out modules like step or async, to make your chained callbacks look nicer. This way you will avoid long code pyramids.
Use a tool such as JSHint or similar, to detect errors and potential problems in JavaScript code. Try to integrate it with your editor or your complete development environment.
Regarding editors or an IDE, well, you basically have a standard pick here.
Although there is one interesting and somewhat new player you might want to check out - Cloud9 IDE, an online development environment for js and Node (amongst others). Since the code is available on github you can also deploy it on your own machines if the hosted options don't suit you.
You should also check out modules like step or async, to make your chained callbacks look nicer. This way you will avoid long code pyramids.
Use a tool such as JSHint or similar, to detect errors and potential problems in JavaScript code. Try to integrate it with your editor or your complete development environment.
Regarding editors or an IDE, well, you basically have a standard pick here.
Although there is one interesting and somewhat new player you might want to check out - Cloud9 IDE, an online development environment for js and Node (amongst others). Since the code is available on github you can also deploy it on your own machines if the hosted options don't suit you.
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.
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.
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
https://github.com/isaacs/nave
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
[1]: https://github.com/creationix/nvm
[2]: https://github.com/visionmedia/n
Does anybody know which optimization was added to V8 to improve the throughput by so much?
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.
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.
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?
Any ideas how long it usually takes Heroku to add a new release of Node?
You can use any version at any time: https://devcenter.heroku.com/articles/nodejs-versions
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...
...which doesn't list 0.8.
...which doesn't list 0.8.
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)
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.
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
[1] https://devcenter.heroku.com/articles/nodejs-versions
Now they have.
Just make sure you specify the latest npm as well. http://heroku-buildpack-nodejs.s3.amazonaws.com/manifest.npm
Upgraded my app to node 0.8.0 and npm 1.1.9 and seems to be working okay.
Just make sure you specify the latest npm as well. http://heroku-buildpack-nodejs.s3.amazonaws.com/manifest.npm
Upgraded my app to node 0.8.0 and npm 1.1.9 and seems to be working okay.
Now it does!
In the announcement: s/in favor of/in place of/, otherwise one can't parse which array implementation will be picked.
Congrats on the release, it looks great!
Gotta love that the homebrew recipe is already up.
brew update
brew upgrade node
brew update
brew upgrade node
Why does brew NOT include NPM? I used the mac installation package instead.
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
UPDATE: More on this here http://blog.izs.me/post/3295261330/on-npm-and-homebrew
[deleted]
The big difference is the switch from node-waf to node-gyp for native modules.
Anyone noticed increased CPU usage?
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