IsaacSchlueter

No, this does not have anything to do with him. This has been in the works for several months.

I also hope Luke's ok. Thanks.

What about 9/11?

> But there are hopefully creative business solutions to be had here.

I sure hope so! I'll be sharing many more details about the specifics in the next few days. I just kept it brief in this announcement so as not to drown out the message about TJ taking over Node.

> Q: How does this relate to the money I gave to the Scale NPM project a few months back? https://npm.nodejitsu.com/

The money you gave to Nodejitsu to continue supporting npm was a huge part of getting us in front of the exponential growth curve. I'll continue to be closely involved with Nodejitsu.

But a service of npm's scale and importance can't survive on handouts forever. At some point, we need much more continued investment and a focused team, and the way to get that is to develop additional features that people are willing to pay for.

> and I'm not in a position to fork the project myself if that happens

You don't have a github account?

Yep. Joyent's new corporate strategy: hunting witches. Nailed it.

You say "profit driven" like it's a bad thing.

I thought this was a forum about startups.

How do you know that no one approached him privately?

I'd call it a bug. It's fixed in master.

The new default in master is Infinity. (Also, there's opt-in KeepAlive that actually keeps sockets alive even if there are no pending requests.)

The ulimit will prevent you from opening up too many anyway. The HTTP Client is not the correct place to implement job control and queueing with such a low limit by default.

It's fixed in master already. Test with the latest 0.11 to verify.

Marek,

Streams return `false` when a write will buffer past a configurable highWaterMark. The first hand-rolled `on('data', write)` pipe doesn't take this into consideration, and so yes, backpressure is not handled. `r.pipe(w)` does the right thing here.

The single "extra read" that you're seeing is just filling up to that configureable highWaterMark, which is an intentional feature. In the real world, connections are often of extremely variable speeds. Consider sending data from a database on localhost to a client on a 3G or 4G network. The mobile connection is extremely bursty, but with a high max speed and periods of very high latency. The database connection is extremely steady, but with a slower max throughput because of hard disk latency. In that case, you absolutely don't want to miss a chance to send data to the mobile client during a burst, so the ideal default approach is for Node to smooth out those highs and lows by buffering a small amount of data in memory. We don't consider 64KB to be a large amount for most purposes, but as I mentioned, it is configurable.

There is no way to pause the accept call, it's true. We've considered adding that feature, but no one has ever asked for it. Perhaps if you explain your use case in a github issue, we could do that. You can `server.close()` but that also unbinds, so clients get an ECONNREFUSED. Except in the cluster use-case, bind() and accept() are typically very tied to one another. It wouldn't be too hard to expose them separately, but like I said, no one's ever asked. If your complaint is that we haven't implemented a feature that no one's ever asked for, well, ok, that's just not how we do things, so maybe it's just a cultural difference in our approaches to creating software, I don't know.

    First, I believe most node.js programmers (including myself)
    don't understand Streams and just don't implement the Stream
    interfaces correctly.

Ok, well, there's not really any excuse for that any more. They're thoroughly documented, base classes are provided, there are blogs and examples all over the place. Maybe start with http://api.nodejs.org/stream.html and if you have questions that aren't answered, complain about it at https://github.com/joyent/node/issues and mention `@isaacs` in the issue.

It's literally a single method that you have to override to implement a well-behaved Readable, Writable, or Transform stream.

    But even if Streams were properly implemented everywhere
    the API suffers a race condition: it's possible to get
    plenty of data before the writer reacts and stops the reader.

This is not true. The Writable stream object has a highWaterMark. Once that much data is buffered in memory, it starts returning `false` to its consumers. If you'd like to set that to 0, go right ahead. It will return `true` only if the data is immediately consumed by the underlying system. This doesn't happen "some time in the future". It happens at the first `write()` call that pushes the buffer over the high water mark. The example you describe is quite easy to simulate with setTimeout and the like. Perhaps you could post a bug if it behaves in a way that is problematic?

I have a hard time sussing out what you're actually complaining about in this article. You certainly seem upset about some things node does, but I can't figure out exactly what's bugging you. Is it the inability to delay accept() calls? Is it callbacks? Is it streams? Is it non-blocking IO as such?

Streams aren't really a "callback based" API as much as an event-based one, and actually, a more strictly callback-based stream API would be quite a bit easier to get right, in my opinion, with much less ceremony: http://lists.w3.org/Archives/Public/public-webapps/2013JulSe...

A similar approach could be taken to the listen/accept stuff you write about. `server.accept(function(conn) {})` and then call accept() again when you're ready for another one. A convenience method can then be trivially layered on top of that to call accept() repeatedly:

    Server.prototype.listen = function(cb) {
      this.accept(function onconn(conn) {
        cb(conn);
        this.accept(onconn);
      });
    };

I could be wrong, but I suspect, at the root, the cause of your distaste with Node is actually EventEmitters, rather than any of that other stuff you mention. And if so, I agree 100%. The "evented" part of Node is a mistake which can only be properly appreciated with the benefit of hindsight. It's too late to easily change now, of course, and so that's the design constraint we were faced with in building streams2 and streams3. But I think that platforms of the future should avoid this landmine.

Fair warning: I'm going to be offline first for NodeConf and then for vacation, for the next several weeks, so this is is a bit of a hit-and-run comment. Feel free to reply to i@izs.me or post issues on the Node.js github page. I probably won't see replies here.

Joyent owns the trademark and copyright on the IP related to Node.js. (Logo, "Node.js" mark, etc.) They also are involved with marketing, legal, etc.

The active core committers over the last month, and their employers, in order of whether or not they're me:

- Isaac Z. Schlueter (npm author/admin, lead gatekeeper, stream maintainer, javascripter), Joyent

- Ben Noordhuis (issues list champion, most opinionated C++ developer, libuv unix guy), StrongLoop

- TJ Fontaine (build owner, C shim author, tracing afficianado, Master of Robots), Joyent

- Trevor Norris (performance perfectionist, master of dirty hacks), Mozilla

- Fedor Indutny (russian ninja rockstar, TLS tamer), Voxer

Also very important to the project are Bert Belder (Windows guy, libuv co-author) at StrongLoop, and Scott Blomquist (Windows bug-chaser, Microsoft liason) at Microsoft.

Honorable Mention to Ryan Dahl (Node.js creator, BDFL) who is currently off being a professional hipster somewhere in NYC, and not involved with the project. When he did work on Node, he was paid by Joyent, and he got some money for selling the copyright to the company as well.

The Node.js community experience would be much less pleasant if not for Nodejitsu's continued support of the public npm registry. (Nodejitsu acquired IrisCouch a few months ago.)

Node would continue on even if Joyent bit the dust. (Depending on who assumed ownership of the mark, it may or may not have to change name/logo.)

If you've had a bad experience in the past with Joyent, it probably has nothing to do with the experience you might have with Node.js. I am given free reign here to manage the project free of any overt Joyent influence. Joyent is a big Node user, and a lot of really smart people, so I do take it seriously if they have something to say. Especially considering that most of the time when Joyent engineers have a problem with Node, it's related to other users hosted on their platform (Walmart, Voxer, etc.)

Please do read the readme for that repo.

I mean no disrespect or ill will towards GitHub.

https://github.com/isaacs/github/blob/master/README.md

-l does not mean "local". -l means "--long" and has no relevance to the install command.

Local is the default state. If you want to force non-globalness, you can do `--no-global`

Hacker News at its finest.

OMG A DATABSAE THINGIE! IMMA POST THE COMIC WHAT SAYS THE CURSE WORD!

Just because you're not offended by a racist comment doesn't mean it isn't racist.

A good first step is to actively reduce the level of misogyny and other ugliness in your circles to the degree possible.

This sort of crap goes on in part because it has tacit support from "normal" folks. We rush to punishment of Adria, but we shrug and say "oh well" about the others, or the initial incident that started it all.

(I'm assuming that "felix" is Felix Geisendorfer. If not, sorry for the confusion :)

True, despite my joking tweet earlier, I don't think that this is at all a Python problem, except insofar as the "python community" is a huge community of people who (by virtue of its size) mostly are strangers to one another.

You're right that it's not about the language of choice. But a community is made of people. I think that the Node community's niceness has little to do with JavaScript, and more to do with the fact that there were folks like you, mikeal, maxogden, nexxy, polotek, ryah, substack, janl, etc, who imprinted the community with your sense of values and a culture of kindness early on.

But keeping that ball rolling, as the community gets bigger, is very challenging, and it does stress me out a bit. It takes such a little match to set the whole thing on fire!

I do hope it's that easy, or at least, we can keep making it look that easy :)

In the last 3 years with Node, I've seen it go through some definite changes, and we have had to respond to those. I suspect that will continue.

In short, yes, we are, and it's shitty. Reg, everything you wrote here is pretty spot-on.

Adria Richards' behavior was definitely a tactical misstep. With the benefit of hindsight, she should have reported the inappropriate behavior to the conference staff more discretely. Or, even, turned around and told them to show some respect. (And, if they didn't cut the crap, THEN get them kicked from the conference.)

I don't believe that what she did was inappropriate/unacceptable in any kind of moral sense, and I would gladly hire Adria if I was hiring for that kind of role. If a person is making jokes with sexual innuendoes during a talk, they shouldn't be at that conference, and shouldn't be surprised that there are consequences, no matter how many kids they have. Behavior in public is already public; putting it on the internet may make it more so, but it's not as if they had any expectation of privacy in the first place.

At the root, I'm glad she stuck up for herself somehow, rather than just kept quiet. She did so in a clumsy way, and has been castigated for it far more harshly than is useful.

Furthermore, this is a clear incident of sexism in our community. If I had done the exact same thing, there's no way that /r/mensrights would DDoS Joyent into firing me. This is why women feel unsafe and mistreated in our communities: because they are. If they stick up for themselves, they're going to face an onslaught of trolling, and even the ostensible "good guys" are quick to point out that yes, yes, we don't condone this sort of thing, but come on, She Was Asking For It.

As I said, her reaction was a tactical misstep. At a higher level, there's a strategic point about preventing these sorts of things from happening in the first place. How do we ensure that the next Adria feels empowered enough to tell the boys behind her to cut it out, where they realize their inappropriateness for the environment and apologize and the world moves on with dignity? How do we build communities that are compassionate, without so many pikes looking for heads?

Every time some shitstorm like this happens, we all lose a chunk of our humanity, no matter what side we're on, or who does or doesn't get fired.

I feel like a parent of a 14-year-old child, reading a news story about a 16-year-old dying in some horrible car wreck on prom night, knowing that mine will be that age soon enough.

Node is SO nice right now. As technology communities go, it's astounding how compassionate and friendly we've managed to keep things. Even in the face of some strongly held religious feelings about CoffeeScript or async or promises etc, we still talk to one another, like human beings. Our IRC channel and mailing list has a zero-tolerance policy for rude conduct. Our meetups are small and there are enough regulars to keep up a culture of "We don't do that sort of thing here" with respect to lewd jokes, homophobia, sexism, ableism, etc.

What happens when Node is as big as Python? How do we keep this going?

> army of angry whiteknights

Please refrain from racist comments.

The node team has supported Windows since 0.6, and Linux forever.

StrongLoop Node is a bundled distro with modules etc that they're going to support as well.

No, it does not make sense to roll your own proxy turning read() calls into emits. You probably won't get it to go faster than it does now. Whether you use on('data') or read(), you get equivalent performance.

So, some people were acting immaturely at a tech conference, violating the CoC. They offended someone with their antics, and most likely embarrassed their employer, a sponsor of said conference.

The employer might have been a bit knee-jerk in their reaction, but maybe not. No matter how many children you've got, publicly embarrassing the company at a sponsored event is certainly ample grounds for termination.

I am not a member of the python community. But I've gotta say, it's nice to see that it was handled in the way that it was.

And then you people. This Hacker News crowd. Jesus H Christ. You're talking about how Adria failed to use her power responsibly? Give me a break. If I was sitting where she was, I might have done the same exact thing. When you are childish in public, and behave in a manner that the organizers of a community event do not want you to behave, you get kicked out. When you make an ass of yourself while waiving a company logo around, you can expect to have your career impacted.

It's unfortunate that such an example was made of them. It is not a wise strategic move, clearly, because doing so mobilizes the asshat army, as we're seeing.

The non-apology http://news.ycombinator.com/item?id=5398681 is just disappointing.

My hope is that the boys involved in this incident can learn from it, and behave more appropriately when in public.

It's a 3-tuple, not a float.

No.

StrongLoop employs 2 node core committers, Ben Noordhuis and Bert Belder, who are also two of the most active libuv committers. (They have other folks that work there, of course, but those two also work on Node itself quite a lot.)

Joyent still is the custodian and IP owner of the Node.js project. They pay me to work on node, and also provide the project with marketing, legal, hosting, and other resources. Joyent also uses Node extensively in their technology stack, and builds tools to debug their own and their customers' production Node applications.

StrongLoop will be providing support to users of their Node Distro, which bundles v0.10 with a few battle-tested npm modules.

Joyent and StrongLoop are very different companies, and while they're not officially partners, that I'm aware of, they are certainly not competitors in any sense.

If you add a listener for 'data', or call stream.resume() then it'll start flowing data as it receives it, just like v0.8 and before. The only caveat is that listening for 'end' will not automatically start the flow of data, so you do sometimes have to either call resume() or add a data listener.

In practice, it's rare that you care about the end of the stream, but not about the data coming through it, except in tests.

tl;dr Your existing programs will almost certainly Just Work.

I think you're confusing centralization of project control with centralization of domain names.

You would put the cleanup code in a separate function, and call it.

I don't think there's anything wrong with using goto in such a case, though, if it makes the code more understandable.