

io.js 1.4 released – featuring debuggable ES6 promises - inglor
https://github.com/iojs/io.js/blob/v1.x/CHANGELOG.md

======
ndesaulniers
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.

------
apaprocki
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/...](https://github.com/joyent/node/blob/master/deps/v8/src/heap/mark-
compact.cc#L3185)

assuming this is the issue:

[https://github.com/iojs/io.js/pull/952/files#diff-1440e8305d...](https://github.com/iojs/io.js/pull/952/files#diff-1440e8305d54e104797269f3835ac0bfR3055)

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

~~~
inglor
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.

~~~
apaprocki
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_

------
pfraze
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](https://gist.github.com/benjamingr/0237932cee84712951a2)

~~~
inglor
You can find them here:
[https://github.com/iojs/io.js/blob/v1.x/doc/api/process.mark...](https://github.com/iojs/io.js/blob/v1.x/doc/api/process.markdown#event-
unhandledrejection) 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.

~~~
pfraze
Docs look good to me.

------
statenjason
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...](https://github.com/iojs/io.js/issues/932#issuecomment-76048069)

~~~
inglor
There is a short regression for
[https://github.com/iojs/io.js/issues/932#issuecomment-760226...](https://github.com/iojs/io.js/issues/932#issuecomment-76022607)

------
colinramsay
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.

~~~
inglor
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](https://github.com/iojs/io.js/issues/932)

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

~~~
shouldbeworking
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.

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

~~~
inglor
Yes there was a short regression with libuv on macs, here
[https://github.com/iojs/io.js/issues/932#issuecomment-760226...](https://github.com/iojs/io.js/issues/932#issuecomment-76022607)

------
_greim_
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?

~~~
inglor
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](https://github.com/iojs/io.js/issues/830)

------
bhouston
Sweet.

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

------
gnrlbzik
Is it a typo in title? From the page:

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

