
Node v6.6.0 - samber
https://nodejs.org/en/blog/release/v6.6.0
======
STRiDEX
Been waiting for _promises: Unhandled rejections now emit a process warning
after the first tick._ I'm not sure how useful the warning is though.

Now using node v6.6.0 (npm v3.10.3)

$ node

> Promise.reject()

Promise { <rejected> undefined }

> (node:85928) UnhandledPromiseRejectionWarning: Unhandled promise rejection
> (rejection id: 1): undefined

~~~
danneu
This will save a lot of time across the Node ecosystem.

Forgetting to handle rejection is probably the most common error I see when
people post Promise snippets in #node.js. Silent failure is so deadly. "Why do
my requests hang?"

~~~
jamesrom
Sometimes you just want an error to bubble up and be caught above. There's
absolutely no reason to catch every rejection in the scope where the promise
was created.

~~~
danneu
Yeah, looks like it just checks on nextTick, so it only warns when you don't
attach a handler synchronously. Versus warning only if it's unreachable (like
on garbage collection).

Though it does emit another message when rejection is handled asynchronously.

    
    
        > var p = new Promise((_, reject) => reject('lol')) \
          setTimeout(() => p.catch(() => console.log('handled')), 0)
        UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 5): lol
        PromiseRejectionHandledWarning: Rejection handled asynchronously (rejection id: 5)
    

Consolation prize?

Fortunately, most of the run of the mill promises I can think of off the top
of my head get rejection handlers attached synchronously, like in upstream
middleware. I might be drawing a blank, though.

------
michaelsbradley
It seems generators and trampolines involve considerably more CPU overhead in
the 6.x series vs. 5.x, while tail calls are now fully optimized and/or the
default stack limit has grown considerably.

Try running the following script with v5.12.0 and again with v6.6.0:

[https://gist.github.com/michaelsbradleyjr/d1b104137e8e00468d...](https://gist.github.com/michaelsbradleyjr/d1b104137e8e00468d83)

    
    
       node --version && node --use_strict ./mutrec_vs_tramp_vs_gen.js

~~~
jnbiche
> while tail calls are now fully optimized and/or the default stack limit has
> grown considerably

That is great to hear. Now we can finally start _really_ doing functional
programming in JS. Too bad about the generators, though.

~~~
michaelsbradley
Well, I'm not sure which one is the case, sorry to say (TCO or bigger stack
limits, or both). I was only taking a guess as to why the mutual recursion
example works for very large values in node v6.x but not in v5.x. But yes, if
tail call optimization is guaranteed, then functional programming patterns can
certainly shine the brighter for it.

------
sciurus
Not much to see here. The release next month will be more notable; that's when
the 6.x series becomes an LTS.

[https://github.com/nodejs/LTS](https://github.com/nodejs/LTS)

------
gkya
The last time I checked node it was 0.12.* . How did it become 6.* in a couple
years time?

~~~
Touche
They adopted a different versioning system.

~~~
angersock
They adopted the _correct_ versioning system. The old one was rubbish.

------
bitroliest
Looking forward to node 6 being put in LTS later next month, we'll consider
moving from node 4 then.

------
afarrell
If you use the Anaconda distribution of Python, you can install this with
`conda install --channel amfarrell nodejs=6.6.0`

~~~
kough
This is sort of an insane suggestion. Why use a Python distribution to install
Node?

~~~
afarrell
The biggest advantage for me is using conda environments to avoid having to
install everything globally. That way if I want to switch back and forth
between python2 and python3 or different versions of node, I can just do
`source activate foo`.

~~~
inlineint
For Node.js you can use NVM for the same purpose. It is specially suited for
handling multiple node verions and installs everything to user's directory.

~~~
afarrell
yea, but you can't also use it for installing a particular version of MongoDB
or Postgres.

~~~
inlineint
Yes, it's a valid point. That's said I personally prefer Docker for installing
databases of all kinds on my development machine.

------
dmh2000
dang it i just installed 6.5 this morning

~~~
tlrobinson
I recommend nvm on your dev machines.

    
    
        $ nvm install 6.6.0
        Downloading https://nodejs.org/dist/v6.6.0/node-v6.6.0-darwin-x64.tar.xz...
        ######################################################################## 100.0%
        Now using node v6.6.0 (npm v3.10.3)
        $ node -v
        v6.6.0

~~~
sotojuan
I second something like `nvm`. Even homebrew takes a long time to update their
Node versions.

That said, I use `n` because for some reason `nvm` makes my shell take more
than a second to startup (I've tried tons of fixes and none work).

[https://github.com/tj/n](https://github.com/tj/n)

~~~
diggan
I have a little trick that makes nvm not impact your overall startup time.

First, put the version you commonly use in your path

    
    
      export PATH="${PATH}:/home/victor/.nvm/versions/node/v6.5.0/bin"
    

Then, instead of sourching nvm when your shell starts, do it when you call an
alias instead.

    
    
      export NVM_DIR="/home/victor/.nvm"
      alias n=". $NVM_DIR/nvm.sh" 
    

Now, you have a node+npm version by default, and you can do a quick flow if
you want to change

    
    
      $ n
      $ nvm install 6.6.0
      Now using node v6.5.0

~~~
jessaustin
I thought the point of a package manager was not having to mess with stuff
like that? "n" is simply better.

~~~
diggan
Yeah, sure, but sometimes you have to go a little bit extra to have it the
best...

