>Node was created by software developer Ryan Dahl
as a way of building and running entire online applications
with JavaScript—the standard programming language for writing
code that runs in your browser.
Really? I thought that they intentionally choose javascript because it doesn't have any features like threading.
> The massively popular programming framework Ruby on Rails,
for instance, is still sponsored by its creator, a company called Basecamp.
Basecamp isn't happy to the direction that ruby on rails is going, but they accept it. [1]
It's a widely held misconception that JS doesn't have threading. User code executes in a single thread, but asynchronous tasks are managed by a thread pool (libuv in node). Because the multi-threading is hidden with asynchronous calls, the user doesn't need to worry about it, which is why many people say JS is single-threaded. In fact worker threads execute async tasks behind the scenes; it's a very nice feature of the event-loop architecture.
DHH said there are things about the "large tent" aspect of rails that are annoying. That's not the same thing as being unhappy with the overall direction of the project.
> Really? I thought that they intentionally choose javascript because it doesn't have any features like threading.
Yes. I recall Ryan Dahl saying that he first looked at other languages, but he picked JS because it simply didn't have a server-side presence, and so he could 'define' the ecosystem to be async. And it was pretty fast what with the V8 improvements. The benefit of using js for both back- and front-end was just a nice extra.
While I think abandoning threading was originally a good move because it spawned (no pun intended) new methods of chaining callbacks together, I'm concerned that there is really no way out of callback hell by way of callbacks.
So I'm wondering if Node.js, Io.js or both will embrace coroutines, yield and generators. The real danger of threads was always shared memory, not so much simultaneous execution. I'm hoping that we'll start to see Go, Erlang and even shell-style piping of data through predictable, testable and debuggable threads of execution begin to replace callbacks.
If anyone has a general approach for converting callbacks to use coroutines and yield in Javascript, I'd be very eager to hear it. Also the problem of how to enforce scope in Javascript, to prevent sharing state between coroutines.
One of the main reasons for picking JS was that it didn't have a standard library filled with non-async code that would end up slowing apps down if used. Node folks were forced to create an ecosystem of modules from scratch and made them async.
In this case, we see sort of an "arab spring" of open source projects lately. Consider MySQL after it was bought by Oracle, and then the MariaDB fork was born. Now we have Node.js and Docker being forked. Until now, most successful communities have been monarchies or oligarchies, whether it was Linux or Python. Corporate sponsorship played a big role. But if more headless or democratic communities succeed, it will be interesting to watch. PHP is an example of a more headless community, and it used to be all over the place.
There are two ways politics and internet interact. One way is how the tools we use affect our society in meatspace and the other is how we organize online in cyberspace.
> Why not just fork Docker?
> From a security and composability perspective, the
> Docker process model - where everything runs through a
> central daemon - is fundamentally flawed. To “fix”
> Docker would essentially mean a rewrite of the project,
> while inheriting all the baggage of the existing
> implementation.
Docker is not being forked. CoreOS (which is another company, not a "democratic community") is launching a competing project: Rocket, and tries to leverage the popularity of Docker for that.
I could not agree more. But then again, I'm biased, as I wrote my senior thesis in organizational studies on the subject of the politics of information technology, in college in 2003 (and still have yet to publish it online somewhere!).
I think the most interesting aspect of this is the cross-disciplinary nature, when analyzing something like the Internet and information technology through the lens of a different field, politics. The way politics presents itself and interacts in this field (much like other fields) is a whole area of study itself.
This is more about how, for many companies, the OSS doctrine that they espouse doesn't really jive with their need for profitability.
In the long run, they need to make decisions for the company that are not in the best interest of the project, and either the project dies or is forked or abandoned.
Sun did really well by the OSS community for a very long time, but they had nothing to show for it and Oracle has since foisted a lot of their efforts on to the ASF. LibreOffice, hhvm, Mint, just to name a few, have all come about because the companies responsible for the stewardship of a project weren't doing their duty in the eyes of the community. I honestly think we're going to see a Firefox fork in the next 2-3 years.
It's just the nature of OSS and while it means that, long-term, fewer companies will invest in the space, the companies that do invest will do it for the right reasons.
An interesting intersection might be continuity. A big problem with dictatorships is succession. If a project relies on a leader as much as many do, can the project outlive them (or at least their desire to lead it).
> Future of Popular Coding Tool in Doubt After It Splits in Two
Are there convincing number of examples of very popular projects being forked and both ends being discontinued, or is this just a typical example of spreading FUD?
Forking is a natural process in the open-source world.
> is this just a typical example of spreading FUD?
Whatever the outcome, this is absolutely eyeball-grabbing FUD. A popular open source project, by definition, has identified "job(s) to be done" and has attracted an audience of supporters (users and developers). That's what keeps any project afloat. In long-term, a big project fork is a sign of a healthy community. That community occasionally has to come to grips with the evolution of their software. For a fork, this is usually a combination of social and technical dynamics. In the short-term, it's hard to see past the difficult (and occasionally acrimonious) social mechanics.
Ben Noordhuis, the center of the Node.js pronoun scandal [1] and one of the founders of Strongloop, has activity in IO.js more recent than his activity in Node.js.
I can't help but wonder how much of this is a power struggle between Strongloop and Joyent.
Off topic, I guess, but color me unimpressed by the guy claiming he would fire someone for rejecting a pull request that does nothing but advance a political agenda.
It isn't that. Really it's Fedor and Mikeal pushing it a lot, not the strongloop guys. The other core devs are behind it, too, except a couple from Joyent. It really has nothing to do with corporate power struggles (that's more what Joyent's advisory board is about, frankly)... it has to do with developers getting really frustrated at the stalled pace of development on the Joyent branch. The real objective is to get rapid release cycles, pull in updates on V8, better separation of core modules, and new features for better numerical computing, etc. Oh, and new logo proposals are going wild at the moment.
There is a big advantage to node.js that used to be mentioned a lot in its early days, but not much now. The advantage is still there, but it's only noticeable if a developer has experience in other server languages. The big advantage is that node.js had an asynchronous development model from the beginning. This caused all the code written since then to also be written using async. When a node.js project imports other libraries through npm, there is no need to worry about some random synchronous code blocking. All code is written using async because that's the way it was enforced from the beginning.
This is an advantage it shares with other new languages like Go that had good concurrency support from the start. Go has the same advantage with goroutines. All code written by the community since then uses goroutines.
Compare this to python and java which had better concurrency bolted on long after those languages were released. Twisted is basically node.js for python and it existed for a long time before node.js. But one of the main problems with Twisted is that all other existing python code is not written in an async way. A python dev could use Twisted, but as soon as they get some useful library form PIP, it's probably going to block and ruin the whole async.
Java has a similar issue. It was released with heavy threads as the only way to handle concurrency. There have been attempts to try to bolt on async and lightweight thread models. But there is a massive existing ecosystem of java code. None of that will work well with async and no one can rewrite all of it to use some new lightweight thread model.
This is the advantage of a fresh start like node.js or Go. Wheels will be reinvented, but it will have improvements that can't just be bolted on later.
The biggest flaw with node.js right now is that it came too early. If it came out with ES6, it would be a much better ecosystem. If generators/yield had existed from the start, all the callback mess could've been avoided. However, although the callbacks were an unavoidable mess, it did fundamentally force async on the ecosystem. NPM libraries like co show a migration path to the generators/yield future for older node.js code. The IO.js fork should use this opportunity to put something like the co library into core and push generators/yield as the way forward. If Joyent was the cause of the delayed generators/yield support, then they have done great damage to the node.js ecosystem. Node.js should've heavily promoted generator/yield use as soon as it was in V8, not hide it behind a --harmony flag for over a year.
Great comment - I do think the whole 'async by default' is a huge benefit, but I would add an asterisk and say you can technically write a module that performs synchronous I/O if you wanted to (see, for example, synchronous filesystem calls). So there's a possibility some random synchronous code blocking could happen with an untrusted module, albeit very unlikely. As far as I know the fs.*FileSync calls are the only ones.
I think it's great news. Node development has been glacial for a while now. There's an issue where people are sharing logos, https://github.com/iojs/io.js/issues/37, highly recommend.
When a company I worked for tried Joyent for hosting, I found it strange that Joyent's own package manager didn't offer the latest stable version--in fact, their confusingly named plans at that time came installed with a few different then-old versions as default options. That read to me like a lack of support or investment in Node as a technology.
I believe given the nature of those that forked it, we'll be replacing Node.JS with IO.JS (that is awkward to write) soon in http://Clara.io.
I think that the confusion around Node.JS versus IO.JS will persist for some time though. If I wasn't a regular HN reader, I would have missed this completely.
[+] [-] justplay|11 years ago|reply
[1]: https://www.youtube.com/watch?v=lBfVxBj61z0&feature=youtu.be...
[+] [-] drderidder|11 years ago|reply
[+] [-] masomenos|11 years ago|reply
[+] [-] mercer|11 years ago|reply
[+] [-] zackmorris|11 years ago|reply
So I'm wondering if Node.js, Io.js or both will embrace coroutines, yield and generators. The real danger of threads was always shared memory, not so much simultaneous execution. I'm hoping that we'll start to see Go, Erlang and even shell-style piping of data through predictable, testable and debuggable threads of execution begin to replace callbacks.
If anyone has a general approach for converting callbacks to use coroutines and yield in Javascript, I'd be very eager to hear it. Also the problem of how to enforce scope in Javascript, to prevent sharing state between coroutines.
[+] [-] mcantelon|11 years ago|reply
[+] [-] rquantz|11 years ago|reply
[+] [-] zkhalique|11 years ago|reply
In this case, we see sort of an "arab spring" of open source projects lately. Consider MySQL after it was bought by Oracle, and then the MariaDB fork was born. Now we have Node.js and Docker being forked. Until now, most successful communities have been monarchies or oligarchies, whether it was Linux or Python. Corporate sponsorship played a big role. But if more headless or democratic communities succeed, it will be interesting to watch. PHP is an example of a more headless community, and it used to be all over the place.
There are two ways politics and internet interact. One way is how the tools we use affect our society in meatspace and the other is how we organize online in cyberspace.
[+] [-] kibwen|11 years ago|reply
[+] [-] hbbio|11 years ago|reply
[+] [-] sixdimensional|11 years ago|reply
I think the most interesting aspect of this is the cross-disciplinary nature, when analyzing something like the Internet and information technology through the lens of a different field, politics. The way politics presents itself and interacts in this field (much like other fields) is a whole area of study itself.
[+] [-] debacle|11 years ago|reply
In the long run, they need to make decisions for the company that are not in the best interest of the project, and either the project dies or is forked or abandoned.
Sun did really well by the OSS community for a very long time, but they had nothing to show for it and Oracle has since foisted a lot of their efforts on to the ASF. LibreOffice, hhvm, Mint, just to name a few, have all come about because the companies responsible for the stewardship of a project weren't doing their duty in the eyes of the community. I honestly think we're going to see a Firefox fork in the next 2-3 years.
It's just the nature of OSS and while it means that, long-term, fewer companies will invest in the space, the companies that do invest will do it for the right reasons.
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] netcan|11 years ago|reply
[+] [-] egeozcan|11 years ago|reply
Are there convincing number of examples of very popular projects being forked and both ends being discontinued, or is this just a typical example of spreading FUD?
Forking is a natural process in the open-source world.
[+] [-] saidajigumi|11 years ago|reply
Whatever the outcome, this is absolutely eyeball-grabbing FUD. A popular open source project, by definition, has identified "job(s) to be done" and has attracted an audience of supporters (users and developers). That's what keeps any project afloat. In long-term, a big project fork is a sign of a healthy community. That community occasionally has to come to grips with the evolution of their software. For a fork, this is usually a combination of social and technical dynamics. In the short-term, it's hard to see past the difficult (and occasionally acrimonious) social mechanics.
[+] [-] dudus|11 years ago|reply
[+] [-] smackfu|11 years ago|reply
Future of Popular Coding Tool Unclear After It Splits in Two
[+] [-] Thaxll|11 years ago|reply
[+] [-] wcummings|11 years ago|reply
I can't help but wonder how much of this is a power struggle between Strongloop and Joyent.
https://www.joyent.com/blog/the-power-of-a-pronoun
[+] [-] SloopJon|11 years ago|reply
[+] [-] drderidder|11 years ago|reply
[+] [-] petercooper|11 years ago|reply
[+] [-] dmpk2k|11 years ago|reply
[+] [-] shortcircuit01|11 years ago|reply
This is an advantage it shares with other new languages like Go that had good concurrency support from the start. Go has the same advantage with goroutines. All code written by the community since then uses goroutines.
Compare this to python and java which had better concurrency bolted on long after those languages were released. Twisted is basically node.js for python and it existed for a long time before node.js. But one of the main problems with Twisted is that all other existing python code is not written in an async way. A python dev could use Twisted, but as soon as they get some useful library form PIP, it's probably going to block and ruin the whole async.
Java has a similar issue. It was released with heavy threads as the only way to handle concurrency. There have been attempts to try to bolt on async and lightweight thread models. But there is a massive existing ecosystem of java code. None of that will work well with async and no one can rewrite all of it to use some new lightweight thread model.
This is the advantage of a fresh start like node.js or Go. Wheels will be reinvented, but it will have improvements that can't just be bolted on later.
The biggest flaw with node.js right now is that it came too early. If it came out with ES6, it would be a much better ecosystem. If generators/yield had existed from the start, all the callback mess could've been avoided. However, although the callbacks were an unavoidable mess, it did fundamentally force async on the ecosystem. NPM libraries like co show a migration path to the generators/yield future for older node.js code. The IO.js fork should use this opportunity to put something like the co library into core and push generators/yield as the way forward. If Joyent was the cause of the delayed generators/yield support, then they have done great damage to the node.js ecosystem. Node.js should've heavily promoted generator/yield use as soon as it was in V8, not hide it behind a --harmony flag for over a year.
[+] [-] brainflake|11 years ago|reply
[+] [-] deathtrader666|11 years ago|reply
Why Elixir - http://www.theerlangelist.com/2014/01/why-elixir.html
[1] http://elixir-lang.org/
[+] [-] exabrial|11 years ago|reply
[+] [-] andypants|11 years ago|reply
[+] [-] calebm|11 years ago|reply
[+] [-] exabrial|11 years ago|reply
[+] [-] binarymax|11 years ago|reply
http://nodejs.org/api/child_process.html#child_process_child...
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] hartator|11 years ago|reply
The new contributors: https://github.com/iojs/io.js/graphs/contributors
Joyent really fucked up.
[+] [-] ulisesrmzroche|11 years ago|reply
[+] [-] esalman|11 years ago|reply
[+] [-] yoctonaut|11 years ago|reply
[+] [-] samsnelling|11 years ago|reply
[+] [-] debacle|11 years ago|reply
Is that naivete on the side of Io.js here, or is there more to the story?
[+] [-] JeremyMorgan|11 years ago|reply
http://compositecode.com/2014/12/05/im-so-mad-my-response-to...
I'm pretty sure he's right, nothing to freak out about.
[+] [-] bhouston|11 years ago|reply
I think that the confusion around Node.JS versus IO.JS will persist for some time though. If I wasn't a regular HN reader, I would have missed this completely.
[+] [-] anonfunction|11 years ago|reply
[+] [-] andrewstuart2|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] bipin-nag|11 years ago|reply
[deleted]
[+] [-] youaresolam3|11 years ago|reply
[deleted]
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] percept|11 years ago|reply
[+] [-] username223|11 years ago|reply