
Io.js v3.0.0 - antouank
https://github.com/nodejs/io.js/blob/master/CHANGELOG.md
======
hit8run
I thought they would merge back into node? Why are they releasing a 3.0
version (new major version breaks even more compatibility?)?

~~~
slasaus
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-
sup...](https://medium.com/@nodesource/essential-steps-long-term-support-for-
node-js-8ecf7514dbd)

~~~
rrss1122
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
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
Ah, seems semantic versioning is all the rage nowadays.*

Fixed it!

~~~
serve_yay
Yeah, having your version numbers mean something? What'll those wacky JS
hipsters come up with next?!

------
spion
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
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
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 :)

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

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

------
thomasfoster96
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).

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

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

------
jtwebman
This can't be stable at this rate.

~~~
infamouscow
Do you have any reason to sustain this claim?

~~~
donpark
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
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

------
bricss
The future of yesterday, today.

------
amelius
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
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-...](http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-
scheduling.html?view=classic)

Also see decent writeup about shared-nothing at
[http://jlouisramblings.blogspot.com/2013/10/embrace-
copying....](http://jlouisramblings.blogspot.com/2013/10/embrace-
copying.html?view=classic)

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

~~~
seiji
Benchmarks are interesting these days. Software can generally be made "fast
enough," but there's no benchmark for maintainability or ease of coding.

What good is a Java program being 2x as fast as a Python program if the Java
program requires 3,000 lines and two weeks to write while the Python program
requires 300 lines and two days?

The idea for Go is "become the new Java but without that startup time
penalty." The goal of Java was to be a "dumb enough" language where individual
talent or skill or knowledge doesn't matter. So, you get a language not
targeted at expressiveness or ease of thought or ease of programming, but at
ease of using people as interchangeable cogs in a multi-billion dollar
software development machine. Not really exciting to be a part of.

We've come full circle back to Averages
([http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)) —
startups _not_ using Go will fare much better than encumbered startups just
due to the brain rot you're required to experience while using Go itself. (I
mean, TABS? In 2015? Non-versioned web-placed dependencies? What is wrong with
these people?)

~~~
jsprogrammer
>What good is a Java program being 2x as fast as a Python program if the Java
program requires 3,000 lines and two weeks to write while the Python program
requires 300 lines and two days?

I will stop you right there.

If there is a 2x difference it very well might be worth it to me if that means
I only have to run half the machines I would with the slower solution. Run-
time costs can dominate all other concerns for some problems.

Specifically, I am looking for Erlang vs. other (ie. C, Go, Node) performance
commentary.

~~~
mike_ivanov
> If there is a 2x difference .. I only have to run half the machines

No, it doesn't work that way. CPU is almost never an issue, it's all about
startup time, network latency -- that kind of stuff. So, unless you're mining
bitcoins, 2x difference is negligible.

~~~
jsprogrammer
I guess I don't understand where Erlang would fit in your (my) stack.

If you want to handle millions->billions of external client connections, you
may want to be able to pack as many on to a machine as possible to reduce
costs (the difference between paying for 5,000 machines vs 10,000 machines).
If you want these to be secure connections (which I do), there is significant
CPU overhead in encrypting and decrypting all network traffic. Even if you
aren't doing encryption work, there is still significant CPU work in managing
large numbers of sockets. Implementations may also vary significantly in the
amount of memory required to support the connection, affecting costs and
machine count.

