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.
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 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:
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.
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.
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'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.
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:
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.
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.
I think you may be mistaken here. Looking at the other comments, I don't believe they're trying to be inflammatory or just trying to get a rise out of people. The user could be say, intersex, physically disabled or both.
Some people don't identify with a particular gender. I don't have any issue with my gender identity, but we just have to take the word of people who say they do.
These can be legitimately sensitive things to some people and I'm of the opinion that a sincere adult response is not to silence their voices.
Unfortunately, that's a loophole large enough to drive a troll truck through, so it isn't workable.
Moderation is guesswork. We guess wrongly sometimes, but at least it's usually easy to show us that we're wrong. In such cases we correct the mistake and say sorry.
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