Node v6.6.0 | Hacker News Reader

Node v6.6.0

nodejs.org

152 pointssamber47 comments

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

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

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.

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.

It will at least print the rejection value coerced to a string ("undefined" in your example), but line numbers would be nice.

What will it give you what 'unhandledRejection' [0] doesn't?

I don't mind that it also emits a warning, but AFAIK you could already get that information by subscribing to this more specific event?

[0] https://nodejs.org/dist/latest-v6.x/docs/api/process.html#pr...

It will hopefully remind you that you forgot to register that event.

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

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

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

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.

> tail calls are now fully optimized

Can't remember where I heard this, but I'm given to understand they aren't optimized, just allowed. As in, recursive calls from tail position won't be super-fast or anything, they just won't blow out the call stack. Optimization may or may not be added to the engine at some future date.

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

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

They adopted a different versioning system.

They adopted the correct versioning system. The old one was rubbish.

A bunch of folks unhappy with Joyent's progress on node forked it into io.js, they had an aggressive release schedule, and then when the 2 project reunited, they chose to use io.js's versioning. (io was at 3.3; the new unified release was 4.0)

It now uses semantic versioning: http://semver.org

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

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

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

It's pretty sane if you are also a python programmer. I personally can no longer keep track of how I installed/set up my environments and would much prefer everything under a single package manager (instead of pip, easy install, eggs, virtual env, apt-get, nvm, npm, docker, brew, macports, etc etc).

That's exactly what Nix [1] tries to accomplish. You should look into it. I have been using it for about six months and has worked very well for me, especially for haskell and python development.

[1]: http://nixos.org/nix/

I came across it back in 2014 and have been meaning to check it out since. Do y'all have a how-to-build-a-package walkthrough?

The Nix manual is a good start: http://nixos.org/nix/manual/#chap-quick-start Then there are a lot tutorial about setting up a development environment for a particular language. See:

go: http://lethalman.blogspot.it/2015/02/developing-in-golang-wi...

haskell: https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-...

python: http://datakurre.pandala.org/2015/10/nix-for-python-develope...

node.js: http://sandervanderburg.blogspot.it/2014/10/deploying-npm-pa...

I recommend reading Luca Bruno's blog for learning Nix internals and more advanced topics.

Conda is not a python package manager. It's just a package manager. You can keep all kinds of software in your home folder.

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

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.

Nvm sucks at npm link. If you use npm link and nvm things will break. Thats why you should use n instead.

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

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

Thanks for packaging node for Conda, amfarrell! It's nice to see non-Python packages in Conda.

Yea, I wish there was more of this, but the limiting factor is walkthrough documentation for folks who are new to packaging to learn to create and debug conda packages. I have long wanted to write an such and intro tutorial, but only recently succeeded in learning how to build packages and haven't had the time science.

The real problem is that creating a good intro developer experience takes sustained skilled time. I'm right now working on a similar project at GoCardless and we've got 3 engineers and a designer focused almost full-time on writing, designing, and user-testing our API tutorial. The Conda community would either have a patreon to sponsor someone to work on it, or convince a company to do that.

dang it i just installed 6.5 this morning

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

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

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

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

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

'n' has always worked perfectly for me. Takes all of twenty seconds to get up to date, and switching between versions is stupid simple.

I do something similar to @diggan, but expand with globbing because I'm probably lazy:

  NODE_PATH=$(dirname ~/.nvm/versions/node/v6*/bin/node)
  export PATH="\
  ${NODE_PATH}:\
  ...

  export NVM_DIR="/Users/jbergstroem/.nvm"
  [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"

Also, the delay that a lot of you may be experiencing has to do with npm, not nvm.

and

  nvm reinstall-packages v6.5.0

to reinstall all your global packages from v6.5.0 or other versions.

I learned this subtle trick via nvm. If you use "nvm install 6" it will automatically download the latest version.

Reply on news.ycombinator.com