7 ms·

Io.js v3.0.0

159 points by antouank 11y ago

deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
- LukeB_UK 11y ago
  That's why it's a major version bump, because it has breaking changes.
hit8run 11y ago
I thought they would merge back into node? Why are they releasing a 3.0 version (new major version breaks even more compatibility?)?
- ultramancool 11y ago
  They're still operating separately for now, though under the "Node.js Foundation". I believe a merge back in is planned though I can't seem to find any specific dates.
- slasaus 11y ago
  They will probably release a merged version in October which will be named Node.js 4.0 and will be supported for 2,5 years. https://medium.com/@nodesource/essential-steps-long-term-support-for-node-js-8ecf7514dbd https://medium.com/@nodesource/essential-steps-long-term-sup...
  - rrss1122 11y ago
    Ah, seems version skipping is all the rage nowadays. Having an LTS version will be welcome though. Having to go in there and upgrade node every few months is a mild inconvenience on my project.
    - mattkrea 11y ago
      It isn't skipping versions. io.js is strictly following semver and have introduced breaking changes (usually due to a V8 upgrade) in each major bump.
      - coroutines 11y ago
        Ah, seems semantic versioning is all the rage nowadays.* Fixed it!
        serve_yay 11y ago
        Yeah, having your version numbers mean something? What'll those wacky JS hipsters come up with next?!
  - wukerplank 11y ago
    If that is true: That's just an odd jump, seeing that Node's current version is 0.12.7
    - LukeB_UK 11y ago
      It'll be version 4 because it'll be a continuation from version 3 of io.js
      - wukerplank 11y ago
        I understand that. But in my understanding a version number also reflects where a project stands in respect to features planned vs features implemented. Jumping from 0.x to 4.x is plain weird in this regard.
        grandalf 11y ago
        you must not have been following the IO.js saga so far... first they forked node, then began using semver, and very quickly got to 2.x and now 3.x. Merging with node just means now anyone using node can use whichever version they want, and future versions are officially part of node.
        seiji 11y ago
        But in my understanding a version number also reflects where a project stands in respect to features planned vs features implemented. Nope. Version numbers are completely arbitrary. Firefox is on version 39 and Chrome is on 46.0.2471.2 and Safari is on version 8.0.6 and Webkit is on version 10600.6.3. Windows 3.1 was followed by Windows 95 was followed by Windows 2000 was followed by Windows 7 was followed by Windows 10?
        yellowapple 11y ago
        Hell, TeX version numbers are just additional digits of pi (latest version is 3.14159265), and Slackware jumped version numbers from 4 to 7 because people kept thinking it lagged behind Debian's whole-number versioning (ultimately, Slackware's version numbers would have surpassed Debian's even without the artificial bump, but whatever). Arbitrary indeed.
smegel 11y ago
?
amelius 11y ago
I'm hoping they will converge towards Go, with its fine-grained threading model (with shared state), as opposed to an asynchronous model which is effectively the cooperative-multitasking that we remember from Windows 3.1. Asynchronous programming forgets that the CPU is also a resource that needs to be managed in a non-blocking way. Currently, in Nodejs, long-running computations (e.g., computing a large prime number), totally block the CPU. EDIT: For anybody saying that shared-state is a bad thing, read up on functional datastructures with structural sharing.
- seiji 11y ago
  Never say "shared state" and "threading" in the same sentence. If anything, all languages need to move to an Erlang shared-nothing model. But, Erlang was doing all this back in the 80s, so people have to re-invent it worse in the 2010s to feel special. You can't just go around using things other people made (OPC—other people's code) that just work, you have to make it your own and start your own conferences and books and webinars and vine instaslacks. Erlang is also preemptive (bumping reductions) so your "long running computation spinning on a thread" problem goes away too. Though, we can't say "goes away"—sounds too much like Go—how about it "erlangs away" the problem? Decent write up on erlang scheduling at http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html?view=classic http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-... Also see decent writeup about shared-nothing at http://jlouisramblings.blogspot.com/2013/10/embrace-copying.html?view=classic http://jlouisramblings.blogspot.com/2013/10/embrace-copying.... Erlang also has per-process (green thread) heap/GC (i.e. no 'stop the world' required), full load balancing over your CPUs, unbelievably useful pattern matching, atoms/symbols, full serialization of all native data types, built with network distribution in mind from the ground up, plus a syntax that doesn't look like somebody woke up from the 70s in 2010 and decided to write a new language just like their old favorite language. Any knocks against Erlang syntax is because it stands on the shoulders of giants, not because somebody made it in 2010 and ignored all programming language and usability research from the past 40 years.
  - jsprogrammer 11y ago
    Any benchmarks comparing Erlang, Go, C, Node performance for network applications (eg. max # connections, max requests/s, request latency, etc) that you can point to?
yellowapple 11y ago
PowerPC support is exciting. Can't wait to give this a whirl on some of my better hardware.
spion 11y ago
The faster url parser is still not merged [1] (was supposed to be added to 2.0.0). All in all, I think even io.js is still very conservative compared to how node was pre-0.10 [1]: https://github.com/nodejs/io.js/issues/643 https://github.com/nodejs/io.js/issues/643
- STRML 11y ago
  Thanks for the reminder - I saw this floating around months ago. @petkaantonov does fantastic work and I'm doing what I can to help get the PR merged.
  - spion 11y ago
    Haha, no problem. Its been a bit frustrating watching that PR, as requirements went back and forth from complete backward compatibility to whatwg compatibility a few times and petka did everything to accommodate. I just want to see node near the top of the list of benchmarks again - its never good publicity to be so close to PHP :)
nailer 11y ago
> Status codes now all use the official IANA names as per RFC7231, e.g. http.STATUS_CODES[414] now returns 'URI Too Long' rather than 'Request-URI Too Large' Nice. Using the names (from a reversed copy of http.STATUS_CODES) can make a code using non-common HTTP codes a lot more readable.
jtwebman 11y ago
This can't be stable at this rate.
- infamouscow 11y ago
  Do you have any reason to sustain this claim?
  - donpark 11y ago
    Have you tried io.js v3.0? It may be stable itself but breaks many modules which may be why major version got bumped.
    - dhritzkiv 11y ago
      Have you tried reinstalling these modules? Often, some modules have C++ bindings that need recompilation every few V8 version bumps. In any case, running `rm -rf node_modules` and `npm install` helps
izolate 11y ago
Was hoping for the inclusion of ES6 fat arrows. V8 has a solid implementation now.
- tracker1 11y ago
  You'd have to check which version of v8 added fat-arrow support... I've been using babeljs for most of my stuff regardless of node/v8 version as I want async/await support which is a ways off still.
  - mscdex 11y ago
    The next+1 branch has a fairly recent version of v8 4.5 that has fat arrows and other new language features shipped. My guess is that next+1 will become 4.0.0.
- antouank 11y ago
  Should be included in the next major ( which will get V8 4.5 I guess ) https://github.com/nodejs/io.js/pull/2221#issuecomment-126250362 https://github.com/nodejs/io.js/pull/2221#issuecomment-12625...
bricss 11y ago
The future of yesterday, today.
thomasfoster96 11y ago
I'd love for there to be some sort of indication of moving towards using a lot of ES6 features in the Node.js API. Having the file system module returning Promises would be amazing, especially when async functions are standardised. What'll also be awesome is if the streams and HTTP module become Observables (async generators, an ES7 proposal).

Io.js v3.0.0

159 points by antouank 11y ago

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

LukeB_UK 11y ago
That's why it's a major version bump, because it has breaking changes.

hit8run 11y ago

I thought they would merge back into node? Why are they releasing a 3.0 version (new major version breaks even more compatibility?)?

ultramancool 11y ago
They're still operating separately for now, though under the "Node.js Foundation". I believe a merge back in is planned though I can't seem to find any specific dates.
slasaus 11y ago
They will probably release a merged version in October which will be named Node.js 4.0 and will be supported for 2,5 years. https://medium.com/@nodesource/essential-steps-long-term-support-for-node-js-8ecf7514dbd https://medium.com/@nodesource/essential-steps-long-term-sup...
- rrss1122 11y ago
  Ah, seems version skipping is all the rage nowadays. Having an LTS version will be welcome though. Having to go in there and upgrade node every few months is a mild inconvenience on my project.
  - mattkrea 11y ago
    It isn't skipping versions. io.js is strictly following semver and have introduced breaking changes (usually due to a V8 upgrade) in each major bump.
    - coroutines 11y ago
      Ah, seems semantic versioning is all the rage nowadays.* Fixed it!
      - serve_yay 11y ago
        Yeah, having your version numbers mean something? What'll those wacky JS hipsters come up with next?!
- wukerplank 11y ago
  If that is true: That's just an odd jump, seeing that Node's current version is 0.12.7
  - LukeB_UK 11y ago
    It'll be version 4 because it'll be a continuation from version 3 of io.js
    - wukerplank 11y ago
      I understand that. But in my understanding a version number also reflects where a project stands in respect to features planned vs features implemented. Jumping from 0.x to 4.x is plain weird in this regard.
      - grandalf 11y ago
        you must not have been following the IO.js saga so far... first they forked node, then began using semver, and very quickly got to 2.x and now 3.x. Merging with node just means now anyone using node can use whichever version they want, and future versions are officially part of node.
      - seiji 11y ago
        But in my understanding a version number also reflects where a project stands in respect to features planned vs features implemented. Nope. Version numbers are completely arbitrary. Firefox is on version 39 and Chrome is on 46.0.2471.2 and Safari is on version 8.0.6 and Webkit is on version 10600.6.3. Windows 3.1 was followed by Windows 95 was followed by Windows 2000 was followed by Windows 7 was followed by Windows 10?
        yellowapple 11y ago
        Hell, TeX version numbers are just additional digits of pi (latest version is 3.14159265), and Slackware jumped version numbers from 4 to 7 because people kept thinking it lagged behind Debian's whole-number versioning (ultimately, Slackware's version numbers would have surpassed Debian's even without the artificial bump, but whatever). Arbitrary indeed.

smegel 11y ago

amelius 11y ago

I'm hoping they will converge towards Go, with its fine-grained threading model (with shared state), as opposed to an asynchronous model which is effectively the cooperative-multitasking that we remember from Windows 3.1. Asynchronous programming forgets that the CPU is also a resource that needs to be managed in a non-blocking way. Currently, in Nodejs, long-running computations (e.g., computing a large prime number), totally block the CPU. EDIT: For anybody saying that shared-state is a bad thing, read up on functional datastructures with structural sharing.

seiji 11y ago
Never say "shared state" and "threading" in the same sentence. If anything, all languages need to move to an Erlang shared-nothing model. But, Erlang was doing all this back in the 80s, so people have to re-invent it worse in the 2010s to feel special. You can't just go around using things other people made (OPC—other people's code) that just work, you have to make it your own and start your own conferences and books and webinars and vine instaslacks. Erlang is also preemptive (bumping reductions) so your "long running computation spinning on a thread" problem goes away too. Though, we can't say "goes away"—sounds too much like Go—how about it "erlangs away" the problem? Decent write up on erlang scheduling at http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html?view=classic http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-... Also see decent writeup about shared-nothing at http://jlouisramblings.blogspot.com/2013/10/embrace-copying.html?view=classic http://jlouisramblings.blogspot.com/2013/10/embrace-copying.... Erlang also has per-process (green thread) heap/GC (i.e. no 'stop the world' required), full load balancing over your CPUs, unbelievably useful pattern matching, atoms/symbols, full serialization of all native data types, built with network distribution in mind from the ground up, plus a syntax that doesn't look like somebody woke up from the 70s in 2010 and decided to write a new language just like their old favorite language. Any knocks against Erlang syntax is because it stands on the shoulders of giants, not because somebody made it in 2010 and ignored all programming language and usability research from the past 40 years.
- jsprogrammer 11y ago
  Any benchmarks comparing Erlang, Go, C, Node performance for network applications (eg. max # connections, max requests/s, request latency, etc) that you can point to?

yellowapple 11y ago

PowerPC support is exciting. Can't wait to give this a whirl on some of my better hardware.

spion 11y ago

The faster url parser is still not merged [1] (was supposed to be added to 2.0.0). All in all, I think even io.js is still very conservative compared to how node was pre-0.10 [1]: https://github.com/nodejs/io.js/issues/643 https://github.com/nodejs/io.js/issues/643

STRML 11y ago
Thanks for the reminder - I saw this floating around months ago. @petkaantonov does fantastic work and I'm doing what I can to help get the PR merged.
- spion 11y ago
  Haha, no problem. Its been a bit frustrating watching that PR, as requirements went back and forth from complete backward compatibility to whatwg compatibility a few times and petka did everything to accommodate. I just want to see node near the top of the list of benchmarks again - its never good publicity to be so close to PHP :)

nailer 11y ago

> Status codes now all use the official IANA names as per RFC7231, e.g. http.STATUS_CODES[414] now returns 'URI Too Long' rather than 'Request-URI Too Large' Nice. Using the names (from a reversed copy of http.STATUS_CODES) can make a code using non-common HTTP codes a lot more readable.

jtwebman 11y ago

This can't be stable at this rate.

infamouscow 11y ago
Do you have any reason to sustain this claim?
- donpark 11y ago
  Have you tried io.js v3.0? It may be stable itself but breaks many modules which may be why major version got bumped.
  - dhritzkiv 11y ago
    Have you tried reinstalling these modules? Often, some modules have C++ bindings that need recompilation every few V8 version bumps. In any case, running `rm -rf node_modules` and `npm install` helps

izolate 11y ago

Was hoping for the inclusion of ES6 fat arrows. V8 has a solid implementation now.

tracker1 11y ago
You'd have to check which version of v8 added fat-arrow support... I've been using babeljs for most of my stuff regardless of node/v8 version as I want async/await support which is a ways off still.
- mscdex 11y ago
  The next+1 branch has a fairly recent version of v8 4.5 that has fat arrows and other new language features shipped. My guess is that next+1 will become 4.0.0.
antouank 11y ago
Should be included in the next major ( which will get V8 4.5 I guess ) https://github.com/nodejs/io.js/pull/2221#issuecomment-126250362 https://github.com/nodejs/io.js/pull/2221#issuecomment-12625...

bricss 11y ago

The future of yesterday, today.

thomasfoster96 11y ago

I'd love for there to be some sort of indication of moving towards using a lot of ES6 features in the Node.js API. Having the file system module returning Promises would be amazing, especially when async functions are standardised. What'll also be awesome is if the streams and HTTP module become Observables (async generators, an ES7 proposal).