Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node v4.0.0

nodejs.org

Post reply on HN
Print view View original

181–190 of 277 posts

Re: Node v4.0.0

#181

Post by _greim_ »

ap22213 wrote: post #172
blowski wrote: post #17

Earlier quoted context omitted.

As somebody who uses Node only at the periphery of my role (for things like the Zombie browser, and SASS parsing) the massive instability has put me off from relying on it for anything core. Documentation is quickly out of date, libraries seem to have incompatibilities which only become obvious when they don't work, there's no 'recommended' approach for even basic tasks. I won't pretend I'm speaking for everyone, as…

Geez, that's a bit harsh, don't you think? I've used node on several high-volume production apps, and I haven't seen any instability. And, if the documentation is poor, then it's only poor forsomuch as one unwilling to delve into the code. Node has its place, and it's not for everything, but for quickly whipping together sturdy, flexible web APIs, it's great.

> I've used node on several high-volume production apps, and I haven't seen any instability.

Not sure if this is what you meant, but I read the ancestor comment not as being about "will the process crash randomly?" but "will an upgrade break something in my app?"

It's just that I've seen whole comment threads go by with people tripping over this misunderstanding without ever acknowledging it.

Re: Node v4.0.0

#182

Post by spankalee »

spion wrote: post #176
spankalee wrote: post #159

Earlier quoted context omitted.

Blocking threads. People associate threads with shared-memory concurrency, which can be really hard to deal with, but shared heaps are not the important part - blocking is. Blocking threads means that all your functions can call each other, all control flow constructs just work, and debugging is sane. With blocking threads functions don't need to belong to a special class of async functions that in general need to be…

Now that we have ES6 generators, this is much less of an issue.

Generators don't help with the sync/async split.

Generators are just iterators, and are synchronous. The consumer asks for a value with next() and the value must be computable (even if that value is a Promise).

If you have an async function (one that returns a Promise or in the future a Stream), and you need to call it from a sync function, and somehow incorporate the future value into the return value of the sync function, you're stuck. You have to async-ify your functions all the way up the call chain.

With blocking this isn't a problem. We just need environments that make blocking cheap.

Re: Node v4.0.0

#183

Post by denzil_holles »

dcwca wrote: post #5

The io.js fork and subsequent merge back into Node.js, including the birth of the Node Foundation, has been one of the best examples of the power of open source I have ever seen in action. The situation went from bad, to worse, to the best possible outcome, and that's remarkable to say the least. Congratulations to everyone involved and thank you for the hard work.

Unlike Bitcoin Core / Bitcoin XT / BIP 120392?

Re: Node v4.0.0

#185

Post by Dashron »

ivank wrote: post #149
aikah wrote: post #76

Earlier quoted context omitted.

> I don't think most people working on Node want a Rails equivalent It wouldn't really be possible anyway. Async programming is hard and the shortcuts one can take with synchronous Ruby are impossible with Async Javascript. Nodejs has a "fibers" lib though , but it doesn't look like it is widely popular, but AFAIK it is the only to truly abstract async programming.

Try bluebird's Promise.coroutine, I use it everywhere and it works great. https://github.com/petkaantonov/bluebird/blob/master/API.md#...

Or if you want to use native promises, I threw this together

https://github.com/Dashron/roads-coroutine

Re: Node v4.0.0

#187

Post by ap22213 »

_greim_ wrote: post #181
ap22213 wrote: post #172

Earlier quoted context omitted.

Geez, that's a bit harsh, don't you think? I've used node on several high-volume production apps, and I haven't seen any instability. And, if the documentation is poor, then it's only poor forsomuch as one unwilling to delve into the code. Node has its place, and it's not for everything, but for quickly whipping together sturdy, flexible web APIs, it's great.

> I've used node on several high-volume production apps, and I haven't seen any instability. Not sure if this is what you meant, but I read the ancestor comment not as being about "will the process crash randomly?" but "will an upgrade break something in my app?" It's just that I've seen whole comment threads go by with people tripping over this misunderstanding without ever acknowledging it.

Makes sense, on a rereading.

npm coupled with drastically and frequently changing libraries (and transitive dependency clashes) does make a hell of a dependency mess; I agree.

But, on the plus side, most node libraries are easy to modify. In fact, I have a private repository full of github forks that I've had to make over the years (and not had the time or patience to submit pull requests). Luckily, npm supports private repos easily.

Re: Node v4.0.0

#188

Post by rhinoceraptor »

blowski wrote: post #17
dcwca wrote: post #5

The io.js fork and subsequent merge back into Node.js, including the birth of the Node Foundation, has been one of the best examples of the power of open source I have ever seen in action. The situation went from bad, to worse, to the best possible outcome, and that's remarkable to say the least. Congratulations to everyone involved and thank you for the hard work.

As somebody who uses Node only at the periphery of my role (for things like the Zombie browser, and SASS parsing) the massive instability has put me off from relying on it for anything core. Documentation is quickly out of date, libraries seem to have incompatibilities which only become obvious when they don't work, there's no 'recommended' approach for even basic tasks. I won't pretend I'm speaking for everyone, as…

I didn't know what bad documentation was until I used Ruby. I'll take Node's docs over Ruby's any day.

Re: Node v4.0.0

#189

Post by jkrems »

msoad wrote: post #32

When node supports `import` how you'll import node modules? I hope it works like this import {readFile} from 'fs'; import {clone} from 'lodash'; rather than explicitly providing "correct" URL to the modules. EDIT: edited the syntax.

Adding support for `import` will be a huge breaking change unless all existing packages have to opt-into it somehow. I don't think anybody has a good plan for this yet, apart from treating it as syntactic sugar for CommonJS.

Re: Node v4.0.0

#190

Post by lobster_johnson »

bsimpson wrote: post #135
ploxiln wrote: post #109

Earlier quoted context omitted.

No api stability promises before 1.0 is technically part of semver. It sounds like io.js should have stayed below 1.0 if they broke backwards compatibility three times in less than a year! I always found the naming-and-proclaiming of semver in the javascript community silly. Old style C libs have been doing what semver describes for decades, and while the js community talks it up like crazy, the compatibility and sta…

The Node library is massive, and tightly coupled to V8. The changes that bumped the major version weren't major changes for most people, just for those who happened to be using the parts of the library that changed. Maybe that's a deficiency in semver (or the way io.js used it), but going to v4 in one year isn't as unstable as it sounds; it's just following Chrome's example of not caring how big the version number ge…

It's a good argument for adding another level in addition to semver: A human-oriented release number.

After all, when a project goes from 2.0 to 3.0, you expect something big to have happened -- not just some breakage.

Some projects use release names (e.g., Ubuntu and Android), but if every project starts using release names we'll have a lot of (mostly silly) names to deal with on a daily basis. Plus, there's no inherent ordering in names.

Post reply on HN