io.js 1.4 released – featuring debuggable ES6 promises | Hacker News Reader

io.js 1.4 released – featuring debuggable ES6 promises

github.com

64 pointsinglor21 comments

Trevor Norris informed me that C++11 must be supported for the version of v8 that iojs ships with, which means node native module authors can use C++11. The native stream stuff looks neat, too. As an author of a node native add on, I look forward to this iojs/node fork stuff being resolved, so that I can start using new features. Until then, I refuse to make drop support for node.js.

So it appears that Node is vulnerable to the bug because Google won't backport the fix:

https://github.com/joyent/node/blob/master/deps/v8/src/heap/...

assuming this is the issue:

https://github.com/iojs/io.js/pull/952/files#diff-1440e8305d...

It is kind of annoying that the bug is embargoed...

In Google's defence - they have stated they won't support versions of v8 that reached end of life and have announced they're supporting io.js in favor of node. I totally get why Google won't backport fixes like this.

Google is actively helping io.js and development is coordinated.

To be clear, I find it annoying Google is not yet making the bug public even though the fix and test driver are available. Since they aren't going to patch the v8 in Node, I'd think Node users would really like to know if they are vulnerable to this and should manually patch it. stares at Joyent

Details about the rejectionUnhandled events dont seem to be in the docs yet, but this gist [1] explains it in detail. Looks like a decent solution to quiet suppression of unhandled rejections.

1 https://gist.github.com/benjamingr/0237932cee84712951a2

You can find them here: https://github.com/iojs/io.js/blob/v1.x/doc/api/process.mark... it'll take a bit longer until the website syncs.

We're interested in feedback on how the event descriptions are phrased since there is some controversy regarding how these events "should be used" - if anyone has any feedback on phrasing or how to explain the usage of these events better I'd love to know how to improve them more.

Docs look good to me.

I'm not seeing a 1.4 entry in the changelog. What's the deal?

Edit: They force pushed to master to remove the release due to issues on OSX

https://github.com/iojs/io.js/issues/932#issuecomment-760480...

There is a short regression for https://github.com/iojs/io.js/issues/932#issuecomment-760226...

Is this two releases in a row now that have had a major issue due to speed of release and lack of testing?

Seriously I think it is great to push the platform forward but this is exactly what Joyent was cautious about. Solves some bugs but creates other less predictable problems.

Current node-debugger still does not work with io.js so I am curious how the feature is debuggable.

Hang on - 1.3 was only about three days ago! Rapid progress is obviously fantastic, but is there a reason why these two releases weren't bundled together?

Edit: five days ago, but my point stands.

Probably due to V8 upgrade which contains an embargoed fix. These are usually critical bugs that remain undisclosed until major users (read as: large companies) have patched their systems.

Great question. It started off as 1.3.x but ended up being 1.4 for semver issues. There was discussion[1] about this. In short - it was named 1.4 because of how NPM updated and because of the big features landing.

[1] https://github.com/iojs/io.js/issues/932

So issues beyond the control of io.js then? Makes more sense, just unfortunate I suppose.

Not really unfortunate. Unlike with money, inflation of version numbers doesn't cause that much trouble. It just takes some getting used to. I've gotten used to the high version numbers in Chrome and Firefox, and I'm sure I'll get used to them in projects that use semver the right way as well.

I'm only seeing 1.3 in the changelog. =(

Yes there was a short regression with libuv on macs, here https://github.com/iojs/io.js/issues/932#issuecomment-760226...

So is the default use case this?

    process.on('unhandledRejection', function(ex){
      throw ex;
    });

...the idea being that it's analogous to an uncaught exception bubbling up to the top and causing the process to crash, which is generally what you want to happen?

Yes, it's possible this indeed will be the default behavior at some later point.

Some people don't like this since `unhandledRejection`s can be handled later on at some point (for example, after a week of not adding a catch handler).

There is a discussion here: https://github.com/iojs/io.js/issues/830

Sweet.

Any speed improvements to the ArrayBuffers? http://geekregator.com/2015-01-19-node_js_and_io_js_very_dif... For us with Clara.io, TypedBuffers are pretty important.

Is it a typo in title? From the page:

``` io.js ChangeLog 2015-02-20, Version 1.3.0, @rvagg ```

Reply on news.ycombinator.com