Hacker News new | past | comments | ask | show | jobs | submit login
Node.js, a popular tool for building modern internet services, has split in two (wired.com)
320 points by DieBuche on Dec 5, 2014 | hide | past | web | favorite | 152 comments



    >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]

[1]: https://www.youtube.com/watch?v=lBfVxBj61z0&feature=youtu.be...


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.


You may be speaking of a particular implementation or engine. JS, the language, has no such concept of a "thread". The standard describes execution of a valid program as linear. Libraries may add functions such as event listeners or threading or sockets, but these are not part of the language.

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


Well, there are Web Workers, which are basically threads. http://www.html5rocks.com/en/tutorials/workers/basics/

But it appears that it's part of the WHATWG HTML spec rather than ECMAScript, which is a bit weird.


Web Workers are closer to "processes" in the Erlang sense of the term. They're walled off fairly extensively from the rest of the JS runtime that spawned them because that is pretty much the only good way to backport threading onto a language that wasn't designed with it in mind from the beginning.

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.


That's because it's a Web platform API, not a language feature.


Timers are sort of threads..


Let me know if you disagree... Don't just hide behind a down vote...


Really? I've never seen any synchronization code (e.g., locks) in JavaScript. If multiple threads can execute async tasks in parallel, doesn't that mean JavaScript needs synchronization primitives? Most JS code I've seen in the wild relies implicitly on the single-threaded assumption—that only one callback (for example) will run at a time.


Say you wanna make an HTTP request.

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.


> the external thread will queue up a V8 event

> 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.


This is not done in parallel. Only one block of javascript is being executed at any given time. There is also no concept of preemption, if your function runs forever no other other events or callbacks will be handled.


How much time in a typical Node application is spent executing JS, vs. how much is in the C++ networking code?


JavaScript does not share memory between threads. No shared memory - no need for sync code. Instead it uses message passing and event loop to do the sync for you.

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.


Sorta. What you say it true, but it is also true that Node isn't multi-threaded because the user does not have access to that thread pool. The user cannot create their own threads to do CPU work unless they go into C/C++ land. In other words, only I/O is multi-threaded so if you need to do expensive CPU work then you need to spawn a process which can be cumbersome.


Just to clarify this was responding to:

> 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.


Does each thread get a separate V8 interpreter? I was pretty sure that V8 has a GIL (at least at the Isolate level), just like Python and (Matz) Ruby, and so how do they handle lock contention between multiple threads?


No, because the I/O threads never enter JS land (V8); they just dump their data for the main V8 thread to pick up.

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).


But for web workers there are two threads executing JavaScript in parallel no? However they cannot share state. They can only communicate via messages. It's basically the actor model and it does demonstrate how effective and safe it can be (although Erlang already demonstrated that in spades). No pure FP needed! (although in theory I suppose you could deadlock with two workers waiting on each other for a message)


Is that a language feature or a runtime/library feature though?


The language is designed to handle events/messages because it runs on single thread in the browser. As far as I know, you cannot spawn threads.

The runtime/library does it under the hood.


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.


If you want to get out of callback hell, I Promise you'll enjoy this library called Bluebird.


`Bluebird` looks good, i gonna try it out. thanks.


Thing is, if you want Go- or Erlang-style piping of data, well, Erlang and Go are right there... and both written from day 1 to support those use cases, rather than bodging them onto a language ten years later....


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.


The relevant question in the linked video starts at around 11:12


I think the intersection of politics and internet is interesting. I write about it quite a bit on my blog, as well as here: http://qbix.com/blog/index.php/2013/04/a-new-kind-of-platfor...

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.


Rocket actually isn't a fork of Docker. From https://coreos.com/blog/rocket/ :

  > 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.


There is a point to be made about Docker, even though it hasn't been forked. The prevailing sentiment in yesterday's thread about the new Docker announcements was one of worry over whether it was too much of a land grab by the people at Docker, Inc and whether we should be trusting so much of our infrastructure to one company that hasn't yet started to monetize the technology but will almost certainly do so at some point in the future.

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.


> whether we should be trusting so much of our infrastructure to one company that hasn't yet started to monetize the technology

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.


>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".


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.


Please post it. :)


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.


> I honestly think we're going to see a Firefox fork in the next 2-3 years.

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?


> I honestly think we're going to see a Firefox fork in the next 2-3 years.

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.)


https://www.waterfoxproject.org/ as well -- a 64 bit version.


And another, Pale Moon: http://www.palemoon.org/


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.


I can think of MySQL. While I wouldn't call it dead by any measure it certainly suffered when the spit happened.


Yeah, but how much of that was due to forking and how much of that was folks realising that PostgreSQL is much better than MySQL for most metrics of better?


Yes, but Postgres had lots of technical advantages of MySQL for years, and still was less popular. For most uses people would decide "MySQL is good enough feature-wise for me. It's so popular it's probably safest ecosystem-wise"

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.


The other thing to consider is that for me to think that forking makes the future of the project questionable, you'd have to show that it's likely that usage(original project) < usage(upstream) + usage(fork). In other words, I'd be interested to know the combined usage of MariaDB and MySQL and see if you could actually predict with confidence that it would significantly lower than original MySQL usage. Not just that one of the forks didn't have as many people.


I think most of that was because of Oracle buying Sun. The MariaDB for and Postgres's rising popularity are the outcomes of that.


By any measure? This web-site indicates no significant decline in MySQL usage:

http://db-engines.com/en/ranking_trend


Since i'm a newbie and I couldn't find anything with a simple search, could you elaborate on that particular MySQL situation?


Original creators left and created MariaDB. MariaDB is now used in place of MySQL in most Linux distros by default. They left after Oracle got control over it by buying Sun (who had previously bought MySQL.)


For me it was the closed-source new test cases. That marked a turning point for the direction of MySQL (IMO).


The short version is that MySQL was acquired by Oracle (when Oracle purchased Sun Microsystems). Following concerns about it remaining open source, MySQL was forked by it original creator, and is developed as MariaDB[0].

[0] https://en.wikipedia.org/wiki/MariaDB


Personally, I always though that the community over-reacted big time. After all, the core DB engine most people were using for MySQL for years (InnoDB) had been owned by Oracle for years before that.

MariaDB has done some decent stuff, tho.


forking didn't hurt MySQL. Going proprietary hurt MySQL.


A better headline would be:

Future of Popular Coding Tool Unclear After It Splits in Two


But it's true that Node is losing traction.


I don't think it's losing traction so much as it's losing some mindshare to faster-moving projects like Go. JavaScript is moving forward (both in the spec and in the browser) and Node hasn't kept up at all. There's no 1.0 release in sight. ES6 is effectively absent from Node. V8 is around version 3.30, while the version in the build of Node that's in Homebrew is 3.14, which "is so old it doesn't even receive security fixes anymore".

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.


By what, hacker news discussions? It seems here only "new" things are discussed, but not as much about platforms growing and stabilizing. Its almost like Rust and Golang have taken over the world if you measure by this community.


My prediction is that Go will disappear in same way as it happen to Ruby, Perl and others. It currently rides on the fame that it comes from Google "so it hast to be good". It doesn't really provide anything revolutionary, it just is more friendly toward writing specific type of applications. Just by seeing that majority of people who are using Go are the ones who always explore new languages, and you see majority of people coming from dynamically typed languages such as Python, Ruby, PHP and others makes me convinced of this position.

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.
Languages don't really ever disappear, they just become less trendy and therefore invisible to places like HN that revolve around hipness and novelty. Hell, when was the last time you heard about Perl? And yet there is an enormous amount of Perl out there powering systems the world over, and learning Perl will make you quite employable for maintaining and extending these systems. Replace Perl with Visual Basic, or COBOL, or RPG-LE, and this statement remains true.

  > 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.
Longtime Rustacean here, and I slightly disagree. Rust does get a lot of boost from being backed by Mozilla. People are incredibly wary of investing effort in an unestablished language without full-time corporate backing. But yes, the awesome language semantics are enticing in their own right. :)

  > 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.
I definitely don't expect the world to chuck out C++ and rewrite it all in Rust, though I do expect that Rust will provide an enticing proposition for new systems programming projects that value memory safety while demanding zero-cost abstractions. My hope is that with Rust we can gradually move towards a world that is safer by default.

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.


Node is losing traction where? I see it as being very strong, but it isn't the shiny new thing any more -- which means that it is beyond the first few stages of the hype cycle.

It has very strong growth in Google trends:

http://www.google.com/trends/explore#q=node.js


I think Google trends is a very laggy indicator of something like this.



I see this more as a return to reality from Node.js's astronomical levels of hype.

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.


> The use cases for a single-threaded web server are specific and limited in the real world.

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.


Perhaps you could name some website/app servers that aren't mostly i/o (or event-timing) bound? I wouldn't say the use cases are limited at all.

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.


I worked on some web-based project management software which was highly CPU-bound.

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.


Could you describe the sorts of calculations those were? Are these regressions or similar? Do PMs really look at that sort of thing? Maybe they were basing a TSP on the latest financial figures? b^)

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 would suggest that what you are describing is the exception to the rule... Most queries, in such a case could either be done in the database or pushed to the browser... Generally if you're doing something CPU bound that isn't video processing or gaming, you push that out of process through a worker queue anyhow.


I have come to believe that the truth about Node is somewhere in the middle: not severely limited, as you imply, but probably not fit to dominate the server ecosystem, either.

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."


I can only speak from the perspective of my company. We had quite a few pro-node people. They wrote services in node.

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.


Just wait 5 years they'll be re-written in Swift, Dart, Rust (other shiny new thing). The important thing is, it will probably be the same people doing it ;-)


Really? Dart?


Is that not cool anymore. What's the next "cool" thing?


ITs not that its not cool, its the likelihood of Dart to be implemented in most browsers is low.


Browsers don't implement CoffeeScript, TypeScript, etc either, but that hasn't hindered those projects.


Okay now I see your point, but Dart is far from replacing Node or IO as the next cool thing.


As I said on reddit as well, I'd really like to hear from someone with a year of serious Node experience and then a year of serious Go experience who ended up wanting to go back to Node, for anything other than perhaps a library than only Node had. While the Internet is large and any crazy criterion will match somebody, somewhere, my strong suspicion is that this is not a large set of people. I suspect it's more-or-less a one-way door.


What kind of services are they?


Hello World, a todo list and a blog application. After that we put "proficient experience with node.js" on all of our developers their CVs. Our company website now lists that we have "enterprise grade expertise with Node.JS" and I haven't even talked about the nodejs-rebranding of our social media dootprint (exclusively liking, following and interacting with nodejs content). We are basically swimming in nodejs client work now. So much, that we are considering splitting the company and having an exclusive branche for the nodejs playfield.


#dootprint


Keep in mind that opinions on HN often do not reflect the situation in the general programming community. I think what we are seeing is a particular developer demographic performing their periodic migration. I'm referring to the group of developers that simply follow the heat possibly caused by some sort of anxiety or fear of being left behind. They did some Java, jumped to Ruby then Node and now Go.


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.

https://www.joyent.com/blog/the-power-of-a-pronoun


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.


Yeah, talk about an over the top reaction.

I'd probably reject this too from a do-gooder searching github for pronouns to change.

"Get another hobby. Rejected."


Out of curiosity, what's the harm in accepting the pull request after someone's already done the work?

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?


@buckbova, what's wrong with one-word changes? I run a semi-popular OS project and accept them all the time. It makes the newbs feel good and encourages them to explore further into the source code.


If I were in this position, I would accept it from a frequent contributor to the project.

I don't like the idea of someone poking around to make one-word non-functional changes.


> 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.


The parent is implying that someone was going out of there way to find pronoun errors, to make a political issue of it, not out of genuine interest in project.

Whether this is actually what happened, or is even a bad thing is up to debate.


> What about typos in docs?

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.


That's a way one could do things, and fairly common with non-GitHub repositories. But it's not the cultural norm on GitHub. The typical process is to submit pull requests even for small doc changes. The interface encourages this by even having an "edit" button and online editor, which wraps up the fork/commit/pull-request cycle into a button push. And the GitHub docs encourage that as well.


I think any serious projects should have a CLA, or require sign off like the Linux project does, and suggesting a change is the only way to get around having to deal with that.

For known contributors, yeah, it's a nice feature.


CLA?


Contributor License Agreement.


> Is a gendered word really different?

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).


>One style is to only masculine pronouns, another to only use feminine //

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.


> I get not wanting unsolicited input from "do-gooders,"

I don't get it. Node is an open-source project that accepts unsolicited input in general...is there some objection to "doing good"?


That's fair. By "do-gooders" I was referring to rude people that make it their business to point out all of your problems. Their motivation is not to "do good," it's to be right, and I totally understand not wanting to accept unsolicited input from them because, well, they're rude. :)

So basically I was trying to sidestep the strawman argument.


Actually, it was also some red-tape as the contributor was new, he has to sign some documents and be on the CLA.

Source: https://github.com/joyent/libuv/pull/1015


Makes sense. For the record, I don't know much about the issue at hand, was specifically talking about one-word contributions (which I encourage on my project).


I think it's less harm and more about principle. Nodejs is presumably maintained by hardworking people who devote their time to making it as good as they can. Presumably there's a bug tracker and they'd love contributions, and presumably this issue wasn't on their tracker (otherwise it would have been accepted outright without any issue).

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?


He didn't just reject it, he tried to undo it after it was accepted by someone else.


He didn't just try to undo it, he `git push -f`'d over it.


Well that is a different thing. At that point he couldn't claim that it was about saving his energies for more "worthwhile" project goals.


Color me impressed, because the political agenda that's being advanced is gender equality in technology, which to me seems pretty worthy.


Problem with that situation was that the Joyent guy was commenting on Noordhuis, an employee of a direct competitor to Joyent. So to many it came off as political opportunism to screw with Strongloop and not a sincere evaluation of the situation.


I haven't seen the commit in question, but it seems like there's a balancing act here between gender neutrality and avoiding awkward phrasing. It's just an unfortunate fact of English that being gender neutral all the time leads to awkward prose. Sometimes readability wins.


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.


New features for numerical computing? I am intrigued... for me that essentially means operator overloading, including []. I think that would open the door for implementing a numpy like module for Node. Is that the plan?


No, operator overloading isn't in the language spec, with reason. I think numerical computing libs like LAPACK, if ported to JS, will probably require a wrapper around 64-bit floats (a la BigDecimal) and math operators that are really function calls. The plan has been to look into transpiling from fortran to asm.js although my personal feeling is it would be better just to use the C API and compile a module that statically links in the necessary libs. They'll figure it out...



Reminds me of the Docker/Rocket situation, at least in the monetary sense. Node.js became big, money went to heads, and here we are.


I don't feel that's the case at all... relative to development of every stable release of Node, 0.10 is getting very long in the tooth, and 0.11 is pretty stagnant as well. If only from the perspective of v8 supported features alone. At this point we really should be working on 0.13 (towards 1.0) which should have the --harmony features by default.

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.


What part of

"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.


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.


Or you could just step over Node, and grab on to Elixir[1]

Why Elixir - http://www.theerlangelist.com/2014/01/why-elixir.html

[1] http://elixir-lang.org/


If Node forks, does this mean one of the projects will block?


No, node.js is event-driven and non-blocking.


But there is only a single thread, so io.js will probably hog all the time and effectively block everybody else.


As it was forked by some of the top Node contributors, I'm guessing yes.


How can Node fork? I thought it ran everything in the event loop...


I see your bad joke and raise you an example :)

http://nodejs.org/api/child_process.html#child_process_child...


Haha! Oh man...


The new repository: https://github.com/iojs/io.js/

The new contributors: https://github.com/iojs/io.js/graphs/contributors

Joyent really fucked up.


The "new contributors" link you provided uses commits from before the fork, so it doesn't really have any information.


Do you know who the 4 developers mentioned are? isaacs probably is the NPM one.


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.


Better visualization: http://tableflip.io:1234/


Nice link! Check this one instead of mine if you haven't done so.


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.


One of the downsides to doing stuff like this is many devs turning away from node / io altogether.


> actually set up this foundation because they’re still hoping that Joyent will let them to use the Node.js trademark.

Is that naivete on the side of Io.js here, or is there more to the story?


I'm not sure what you're asking, you left out the key part of the quote:

> 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


> 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.

[0] http://iolanguage.org/


It's more likely that they be called Microsoft.js than Node.js at this point.


Here's a take from one of my friends who is a pretty heavy Node developer:

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 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.


You're not the only one. iojs is already pulling ahead in momentum, fixes, features. Not to mention it has a bazillion logos to choose from haha


I must be missing something. What features has io.js added?


The community has created a lot of rad logos you can find here: http://tableflip.io:1234/


Well now there's a missing consonant in the MEAI stack. Add golang for the IMAGE stack?


AIME? ;)


Oh I like that- drop the 'E' for express since it's a little redundant and you get "AIM"


Hey, that's even in front-to-backend order.


Here's your Friday entertainment...


The guy squatting on the js.io domain (Michael Carter from Claremont) just bought a yacht.


That's ok since internet has been squatting on Javascript for years.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: