141–150 of 277 posts
Earlier quoted context omitted.
- Ruby: 20 years old - Python: 24 years old - Node: 6 years old Maybe your comparison is somewhat unfair...
- language - language - io loop + vm
- language + environment + ecosystem
- language + environment + ecosystem
What happened with the version numbers? I could have sworn Node was on v0.10 just a couple of months back?
Joyent were incompetent stewards of the node project, so it was forked into "iojs". The iojs project adopted the semantic versioning system, where a new major version number indicates backwards-compatible changes (which mainly happen when they update the version of V8). Eventually Joyent recognised they were on the losing side, and so they agreed to merge back together, under a new foundation which was set up with th…
Earlier quoted context omitted.
I can't reply to the grand-child of this post, so here's my reply. It seems that you don't like Node and are intent not to use it. I respect that and am not trying to push it. I think asynchronous programming in the reactor pattern is a good solution pattern for many types of problems, and Node.js is a solid application of that pattern. But it certainly is more complicated than synchronous programming in the kinds of…
I'm not 'shitting all over Node'. I do use it for certain applications, and would love to use it more because it is a fantastic solution for some problems. As a back-end for websockets it's in a league of its own, and 'Isomorphic JavaScript' is very exciting if you ever need to hire developers. I am using this discussion as a means of saying "here's what I think Node needs to get more people using it in production".…
Earlier quoted context omitted.
I meant stability not in the sense of 'frequently crashing', in the sense of the API and 'how things work' remaining the same over time.
It's 0.x.x for a reason, don't you think? The leading 0 denotes probable instability in the API that devs are willing to take the risk for and act upon. You're familiar with SemVer, aren't you?
Earlier quoted context omitted.
It's backwards compatible and works fine from what I see
I thought changing the first number in SEMVER means breaking changes?
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…
Or consider gtk+. 2.x was backwards ABI (binary!) compatible for over a decade. Compatibility was broken once in the last decade, for 3.x (for applications. for themes and windowing environments is a different story unfortunately.) So programs written for 2.10 or so still work today with (still continuing) recent releases of 2.x.
Does anyone have a good source of information about the major changes between Node and IO? I haven't kept up with the community recently and I'm curious as to what the delta really is and what merging IO back into Node will mean practically.
Earlier quoted context omitted.
I mean, Ruby was created in 1995, Python in 1991. Node was first released in 2009. That's not an entirely fair comparison since, of course, JavaScript was created long before Node, but Node introduced the language to a new environment, and a lot of complications needed (and in some cases, still need) to be sorted out. As for no recommend approach - that's deliberate. I don't think most people working on Node want a R…
> 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.
Earlier quoted context omitted.
I mean, Ruby was created in 1995, Python in 1991. Node was first released in 2009. That's not an entirely fair comparison since, of course, JavaScript was created long before Node, but Node introduced the language to a new environment, and a lot of complications needed (and in some cases, still need) to be sorted out. As for no recommend approach - that's deliberate. I don't think most people working on Node want a R…
> 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.
https://github.com/petkaantonov/bluebird/blob/master/API.md#...