>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.
> The massively popular programming framework Ruby on Rails,
for instance, is still sponsored by its creator, a company called Basecamp.
[1]: https://www.youtube.com/watch?v=lBfVxBj61z0&feature=youtu.be...
And yes, to be pedantic, by JS I'm refering to ECMAScript, or ECMA-262. If by JS you mean JavaScript the implementation by Mozilla, then Node doesn't use that anyway :p
> I thought that they intentionally choose javascript because it doesn't have any features like threading.
I wanted to point out that JS doesn't preclude parallelism, it's just implemented as async calls. It would be more correct to say the runtime owns the thread pool. Thanks to other commenters for making the distinction.
> Really? I thought that they intentionally choose javascript because it doesn't have any features like threading.
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.
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.
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.
I can't help but wonder how much of this is a power struggle between Strongloop and Joyent.
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.
http://nodejs.org/api/child_process.html#child_process_child...
The new contributors: https://github.com/iojs/io.js/graphs/contributors
Joyent really fucked up.
Is that naivete on the side of Io.js here, or is there more to the story?
> the team hasn’t actually set up this foundation because they’re still hoping that Joyent will let them to use the Node.js trademark.
Frankly, I kinda like the name Io.js better than Node.js
Well, if it was for a project that was implementing Io [0] on top of JavaScript, sure. For a server-side JS stack based on V8, I don't really like the name at all.
http://compositecode.com/2014/12/05/im-so-mad-my-response-to...
I'm pretty sure he's right, nothing to freak out about.
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.
> 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.But what were seeing with Node along with the other examples from the post you're replying to is that so long as the source is freely available, the core developers and the community is what's important. There was a quote in yesterday's thread that 95% of Docker contributors don't work for Docker, Inc. This means that Docker, Inc will need to walk a tightrope between over-monetizing their platform, pissing off the 95% of contributors from outside Docker, Inc and under-monetizing it, pissing off their investors. If they try things that lock people into the platform and force them to pay for other Docker products, you'll see the developer community rebel with an actual fork of the Docker codebase. This is exactly what we're seeing here with Node...Joyent's stewardship of the project is being seen as lacking and the people who are really important, the core developers and the community are taking a proactive step to remedy that.
It think we're nowhere near the point where this will happen to Docker, but this should be an object lesson for Docker, Inc about what can happen if they try to push too much of the Docker, Inc agenda into Docker, the open source project.
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.
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.
Who is going to fork it? The active contributors that are employed by the Mozilla Foundation? Google? Microsoft? Opera? Some currently peripherally involved third party?
And what will the goals of this fork be? To be more focused on something other than producing a standards-compliant, multi-platform, performant browser?
There are already semi-forks (downstream distributions that continue to pull from upstream and are mostly synced, but also maintain distinct and divergent feature sets) -- both GNU IceCat is an example (Debian Iceweasel I think is less so, because IIRC it is synced but for branding with upstream.)
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.
Future of Popular Coding Tool Unclear After It Splits in Two
It's frustrating to get invested in a product if you know that it's got stagnant parts that nobody seriously plans to fix in the near-term at all.
It has very strong growth in Google trends:
The use cases for a single-threaded web server are specific and limited in the real world. Node.js will continue to solve those use cases (simple web server for static content or I/O bound apps) but the resultant decline will lead some to believe that the framework is dying.
All of those node services have since been rewritten in Go by the formerly-pro-node people. Go has been much more manageable and powerful.
I'd probably reject this too from a do-gooder searching github for pronouns to change.
"Get another hobby. Rejected."
It's bad enough that I have to use browserify to get working features in the browsers... I shouldn't have to do that for a leading edge server-side JS platform in the development version. Don't get me wrong, still love node, and JS is very effective, just the same, I'd rather not have to require in libraries that should be baked into the engine at this point... or writing shims to make for an easier transition.
co/koa are over a year old now... developed against features that still aren't in the supported release... prior to 0.10, v8 had been kept very close to the edge... it's now over a year behind.
"it has to do with developers getting really frustrated at the stalled pace of development on the Joyent branch"
is so hard to understand? Cuz this gets incessantly repeated in a calm, rational manner by people involved with the branch.
Why Elixir - http://www.theerlangelist.com/2014/01/why-elixir.html
The runtime/library does it under the hood.
It was the MariaDB fork that shook people up. Now suddenly the decision became "should I bet on one of these forks, or should I skip that drama and use Postgres which seems like a nice stable project" The fork is really what changed the game.
We trusted free software for a long time before we needed to call it open source to make it sound palatable to less visionary business leaders.
We'll go on trusting the FOSS. The free and open nature of it means that we're never really trusting the company (the corporate entity) just the people they've amassed to work on the FOSS. Those people can continue to work on the FOSS after the company disolves, because the osftware is open/free.
If they aren't volunteers doing it for fun, though, they wont, unless someone pays them.
And even some very popular FOSS projects millions of people use have just one or two overworked maintainers and not much in the way of funding or contributions.
So FOSS is no magic bullet "as long as the code is open and there are users the project will be worked on".
Rust on the other hand also has a bit of hype, but that hype actually has a base. It is due to a features that are quite significant, not because it comes from Mozilla. The ability to do memory safety checks at compile time is quite a big deal (maybe Rust is not first here to offer that, but it is first that it build the entire language around it).
I believe that Rust actually really has a huge chance to replace C and C++ (languages that were developed in 70s and 80s respectively) and influence future languages.
> My prediction is that Go will disappear in same way as it
> happen to Ruby, Perl and others.
> Rust on the other hand also has a bit of hype, but that
> hype actually has a base. It is due to a features that
> are quite significant, not because it comes from Mozilla.
> I believe that Rust actually really has a huge chance
> to replace C and C++ (languages that were developed in
> 70s and 80s respectively) and influence future languages.
Finally, I agree that Rust will be an influence on future languages. Just yesterday D proposed something akin to Rust's borrowed references (http://wiki.dlang.org/DIP69), and I'm curious to see if something similar emerges in future editions of C++. There's also Microsoft's secretive M# language, which I suspect will use a similar mechanism.
http://www.indeed.com/jobanalytics/jobtrends?q=ruby+on+rails...
MariaDB has done some decent stuff, tho.
And yes you are correct that V8 effectively has a GIL for its Javascript execution (though V8 does actually run other threads in the background for profiling).
What node will do is kick off the process (dns, grab a socket, connect tcp, write the header, wait for response etc.)... but it won't wait for any of this to finish, it just starts it on another thread. That thread doesn't need any JS-level synchronization because it has nothing to do with JS. Furthermore, you can kick off multiple requests like this in parallel.
When a request is done and has data to pass back, the external thread will queue up a V8 event. When V8 is free and is ready for the next event, it will see the finished request and trigger your callback with the data. When you're done handling that data (in Javascipt), V8 will wait for the next event and so on.
So you see, it's parallel but doesn't need any JS synchronizatioon.
> So you see, it's parallel but doesn't need any JS synchronizatioon.
I don't know much about V8/Node internals, but I think we can regard the queue as a synchronization primitive? Granted, from what you say it's not in JS, but it's there, so at least some JS implementations need synchronization.
The way it's implemented is similar to Windows 3.x times - collaborative multitasking. Then there is no code to execute in your thread, an background event loop runs, listens for messages from another threads and calls appropriate callback function in your thread.
This design has the benefit of being simple to do simple stuff. And near impossible for more complex multithreaded algorithms that require shared memory.
Edit: I get not wanting unsolicited input from "do-gooders," but if someone on the project made such a change, would you still reject it?
I don't like the idea of someone poking around to make one-word non-functional changes.
What about typos in docs? Contextually it seems reasonable to accept changes of a single word which may cause confusion on operational grounds.
Is a gendered word really different? Operationally, it would appear differentiating between pronouns might be required in documentation if some readers of the docs are offended by the masculine use. One could certainly argue that with excessive profanity.
I would note here that I probably wouldn't care if someone put 'she' in a document to represent a user entity, but that's a simply an observation of my own biases, not a rational to ignore another's.
I don't get it. Node is an open-source project that accepts unsolicited input in general...is there some objection to "doing good"?
So basically I was trying to sidestep the strawman argument.
I can understand the frustration of someone coming into a project and saying "I've made this change that no one on this project asked for cause the words used were offending me." It seems disrespectful to the hard work everyone is doing to keep the project up and running.
I think people would be a lot more open to things like this if there was some proof that removing gendered pronouns actually did something. It's claimed to make open source less hostile for women. Is there any proof that it's working?
But it appears that it's part of the WHATWG HTML spec rather than ECMAScript, which is a bit weird.
Languages like C which had them bodged on years later, well, I'd call that a bad way to do it. It worked for the time but there's a reason why we are all fleeing that implementation of threading and it still stains the entire idea of "multithreading" decades later.
If JS is ever going to get threading, the best case scenario is for it to look like Perl or PHP's efforts... years and years of implementation work to get to something that pretty much everybody recommends you still just stay away from. And Perl and PHP were trying to integrate threading into just one runtime each, and without a browser connected at the hip with its own ideas about threading embedded into decades of code. I would not hold your breath for "true" JS threads anytime soon.
We use Node.JS to run https://Clara.io. Clara.io isn't at all a simple website. I think you are underestimating Node.JS's flexibilities and capabilities.
You can always run multiple process instances, and communication between processes isn't really so different in practice than inter-server communication... Which just means you are scaling horizontally by design earlier in development.
A typical scenario would be the application querying a database for financial figures, doing a large amount of calculations on those figures and then generating an HTML report from them. I imagine any application with large amounts of business logic like this will be the same.
It seems possible that was a mostly IO-bound system, and the things which could have been conceivably CPU-bound should just have been batched and cached.
I develop on .NET all day, every day, building enterprise CRUD apps with fairly cutting-edge capabilities, for small-to-medium-sized companies. I suspect that Node would fit the server role quite handily if we bothered to port our hand-rolled client-side framework to it. But, as the lady said: "Ain't nobody got time for that."
Whether this is actually what happened, or is even a bad thing is up to debate.
In my opinion these trivial changes should be submitted as text in a bug report rather than patches or pull requests. For brevity a regex statement like s/foo/baz/ can be used.
For known contributors, yeah, it's a nice feature.
Yes. A typo is objectively wrong (as objectively as you can be in such matters, anyway). Gendered words is a matter of style. One style is to only masculine pronouns, another to only use feminine, to mix them, to avoid them altogether... and it's not clear which are better. Avoiding gendered pronouns altogether might be easier on the eyes for some people, for other people it seems confusing (singular they, what?), for others it is simply grating and hard to read, etc. Similar trade offs for the other options, of course.
We might as well have people who object to words that they interpret as being offensive, like using the word "right" to indicate "correct" or "good". They might feel that it is biased towards right handed people, and that argument seems to actually have some linguistic precedent - even other than English, "right" in some Germanic languages is also a synonym for "higher", another word with "good" connotations. Even beyond this far-fetched scenario, consider all words that could be argued to have a sexist background. Do we ban all of them, or do we just accept that although they have a nasty history, that history does not necessarily translate to how we intend to use them in this day and age?
I also remember some troll on GitHub that started to complain to a lot of repositories - after the Node.js controversy - that their documentation was being sexist. And many of the owners fell straight for it, because apparently it was a well executed troll, and/or they didn't want to risk being dismissive (because, you know, that could end badly for them).
In English the neuter pronoun is identical to the masculine. "to stop him" doesn't assume that he is male nor female it is agnostic on this point. Unless there is some other indication of the sex of the subject being referred to then you can't necessarily tell. Of course the reason for the use of the masculine pronoun as the neuter is probably historically based in language education being mainly provided to men, but that doesn't mean it needs to be "corrected".
Excepting that point I think I'd agree with what you said.