IsaacSchlueter

But deontology and virtue ethics are just shorthand heuristics for consequentialism, to deal with the fact that humans tend to be very bad at doing utilitarianism properly.

When the consequences are clear, and you have no other options, the rational choice is to ignore virtue ethics.

Of course, in real life, there is almost never such a clear-cut problem as this, and pat examples are often used by those who want to throw away virtue ethics out of convenience rather than actual utilitarian benefits.

Sorry if my response was a bit overly strong. I know you're a good guy and we all just want these things to work well. I wasn't offended, just a bit confused by the results that weren't matching what I was seeing.

Of course, poking a bit further showed that converting a 16MB string to a buffer actually is quite expensive. You can avoid this by using buffers directly when you're serving files (or better yet, just pipe a fs.ReadStream directly into the response, so it'll stream it as it reads from disk, and buffer as little as possible.)

Aha, I take back some of what I said. ChangeLog is not big enough, that's all.

When running with a 16MB file, there's some more CPU spiking, but only if it's served as a single write.

Investigating further, I found that there's a bug in my gists, and I'm testing res.url instead of req.url, so I was making all the exact same mistakes in your test! Hah!

With this test, we see it spike up to 10% for a big string, but a big buffer still stays well below 1%. https://gist.github.com/2339010

I did it in coffeescript to just rule that out as a possible source of work.

The moral of the story is that Buffer<->string conversion is WAY too expensive in Node, and leads to situations where the easy approach leads to poor performance. That's a problem. Thankfully, it's one we already are aware of, and plan to fix, and it's easy to work around by just using a buffer rather than doing extra conversions.

First of all, writing bug reports to Hacker News is usually a bit like complaining about the government at a bus stop. It's fun, and you'll get lots of agreement from crazy people, and maybe start a little riot, but writing your representative is a better way to effect change.

We have two mailing lists, and an issue tracker on github. If someone hadn't emailed this to me, I probably would not have seen it.

There are three problems I see with your test.

1) It serves the file twice, since you don't filter out the /favicon.ico url

2) you're converting the file contents to a string, which needs to be converted back into raw bytes to send.

3) your gist is in JavaScript, but I see that you're actually running CoffeeScript. I'm not sure what kind of wrapper CoffeeScript is adding to the equation.

I ran the same test serving the ChangeLog file from node's source folder with node v0.6.15 (to be released tomorrow) https://raw.github.com/joyent/node/v0.6/ChangeLog

Here's the source code of the server.js: https://gist.github.com/2338851

It did use more CPU than nginx, but not 100x as much. Requesting the /buffer url made it spike up to about 0.2% cpu usage. Requesting the / url made it spike up to about 0.3%. Even when I disabled the /favicon.ico check, its behavior is nowhere near what you're seeing.

When I ran it with coffee script, it actually uses this JavaScript: https://gist.github.com/2338874. So, there's an extra Function.call in there, but otherwise, it's pretty much identical. My coffeescript version is here: https://gist.github.com/2338879

So, something is odd with your situation, and from your test, it's not clear what. I'd love to get more details.

On the more general note, clearly we in the node world are perfectly fine with using nginx to serve static assets. Qv. the nodejs.org home page. But node's performance here should be within an order of magnitude, or something is broken. This is not expected or normal performance that you're seeing. We run the "serve a big string over http" benchmark quite often, and so this was very surprising to me.

    its funny for a core group member to yet again make a
    joke about how Isaac can't be trusted because he's a
    mexican thief

Over the line, dude. Not cool.

This is very interesting. The problem, of course, is that a single person can't get as much done as a team. At a certain point, many projects need to have more developers involved.

What do you think it was that made the Linux Kernel different? I assume there are leaders and social whatevers going on there.

This is extremely useful, thanks!

Just signed up for http://www.codemeet.com/ I'm isaacs on there, and my email is in my profile (and all over the web) if you think it can be helpful for node.js things.

This is hilarious.

There is no validity to that rumor, that I'm aware of.

Node.js and npm use different JS styles. They're different programs with different places in their community. That's not changing.

To quote Mikeal Rogers, "The L in BDFL stands for LIFE, BRO!"

Ryan will be a part of node forever. He's not gone. He just somehow talked me into doing a lot more work :)

O_EXCL is in for 0.8: https://github.com/bnoordhuis/node/compare/O_EXCL

flock() is not trivial to do in a portable way. For a unix-only flock(), check out the fs-ext addon. Same for mktemp.

I wouldn't be opposed to either being in core if it could be done in a clean way, but this is just adding another knob that can be done with an addon easily enough. If you care more about having flock() than about writing portable programs, then that's what the fs-ext addon is for.

> We are going to be dealing with Node.js security bugs because of these issues for a VERY long time.

Of course we'll be "dealing with Node.js security bugs for a VERY long time", because we'll be using Node.js for a very long time. Software is buggy, and many bugs are security hazards. We'll be dealing with "Unix security bugs" and "C security bugs" and "Java security bugs" forever as well.

Please do not make vague suggestions about security issues. Either you've found an issue, and should be submitting it, or you haven't, and are just spreading fud.

You have to remember, developers close to a platform always live 6-12 months in the future, at least. (Talk to Brendan Eich about JavaScript, he's like 5 years in the future.)

What "finished" means in this context is that we've established which problems we're going to solve, and the solutions to those are well-understood. There aren't new problems that node-core is setting out to address by making changes to the binary itself.

The new hard things to tackle are above the core layer - CI, userland module documentation and discoverability, binary deployments, etc. There's quite a bit of polish and refinement to be done at the lower level, but the paths are clear at this point, as far as that goes.

Thanks everyone for the huge vote of confidence. I'm flattered and overwhelmed by the response.

You can open a file with O_EXCL if you pass in the open flags as a number. (You can find them on require("constants"), and they need to be binary-OR'ed together.) This isn't documented. It should be. It should probably also be exposed in a cleaner way.

Most of the rest of what you describe is APIs that need to be polished and refined a bit. The boundaries are well defined at this point, though. We probably won't add another builtin module at this point, or dramatically expand what any of them can do. (I don't consider seek() dramatic, it's just tricky to get right given JavaScript's annoying Number problems.)

It's regional. He grew up in Queens, New York City. His dialect is pretty common.

I think part of the gist of the article was that abused CoffeeScript is more bad than abused JavaScript. So, yes, of course, you can do everything differently. But the point is, in the moment when writing it, it's not confusing, and doesn't stand out as a bad thing. Later, when you look at it, it IS confusing.

Node has been "production ready" for a while, yes. At least, Voxer, Ebay, LinkedIn, Joyent, and Microsoft (among others) seem to think so :)

The API is not changing quickly any more. In fact, in most areas (if you're just dealing with documented features and not diving into obscure internals) it's as stable as it's going to get.

The most recent breaking change that I'm aware of was announced almost a year in advance (though it still caused some hardship). We really are trying to avoid doing that sort of thing if at all possible.

Yes, it's young and there will be bugs, but updates that "break all the nodes" should be a thing of the past.

"Stdin" is the "standard input" to a program. Typically, this is connected to your keyboard input through a tty, but not always.

Node tries to rely on Unix terminology when applicable. If you've never done systems programming of any sort, then yes, this may be a blocker. But, I don't think that most programming language documentation takes the time to explain what "stdin" is.

Request is really quite nice. It's the simple high-level counterpart to node's low-level HTTP client. Very useful "sweet spot" in the abstraction levels.

There are a few option parsers in node that do automatically generate usage. However, this is actually quite problematic if you have a lot of options.

Check out https://github.com/harthur/nomnom, it may be more to your liking.

Moe,

So, when you say "obscure blowup", do you mean, "someone posted any issue whatsoever"?

Several of those are feature requests, or node-core bugs, or things that have been fixed.

I find your blowup very obscure. As for npm failing for you, gist or it didn't happen.

What is a "class" in this context? Let's define it.

As a rough strawman to move forward, let's say that a "Class" is a programming object consisting of:

- A constructor method.

- A set of properties and methods

- Optionally, a parent Class from which it inherits properties and methods, which may be overridden.

And that, when invoked, a "Class" returns an Object which is said to be an "instance of" that Class. The constructor method is called in the context of the instance, and the properties and methods are inherited by the instance.

JavaScript has those things that I'm calling "Classes". In fact, every single function is a "Class" if it's just invoked with "new", and every single object can be a prototype. It's so full of classes, the only excuse for missing them is that you weren't even looking.

Please see almost any JavaScript tutorial ever for an explanation of the "new" and "instanceof" operators, or any from the last 5 years for an explanation of the "Object.create" method.

Or better yet, just sit down with the ES5 spec, and actually read it before you talk about what this language does and does not have.

Additionally, if you mean something by "object inheritance" other than "objects can inherit from objects", then I don't even think we're on the same planet. That's actually something that JS has which most other "object-oriented" languages don't have.

I'm done being trolled for now, I think. Have fun, kids.

A few comments were not showing up as quickly as usual. They are there now.

What do you mean by "blow up in obscure ways"?

It generally dumps a ton of colorful errors to your terminal. If you find them obscure, please be comforted by the fact that I certainly do not find them obscure, and would love to fix whatever problem they indicate. It's actually my job.

Also, npm is a software program, and not intelligent. It doesn't "like" things. To the extent that it has preferences, it loves semantic versions, accurate metadata, and especially you.

JavaScript does have inheritance, and classes.

Please troll using facts next time.

You had me right up until:

> The "limited surface area" is all well and fine in JS, because there is no object inheritance in JavaScript

It doesn't really matter what the "this is not valid json" return value is.

I just don't think that it's worth the cost of capturing a bunch of stack frames for such a common occurrence as "you posted bad data to my web service".

It's a strange loop, actually. The requiring attribution would be more restrictive, since the current license does not require attribution. If you re-license it with a license that does not require a less restrictive license, and then license it again with a license that is more restrictive, then you've violated the original one.

Logically, it implies "You can only release it under this license".

That is, the license says, "This is obvious, and doesn't need a license", and is a joke.

This is neat :)

I spent a lot of years in php, and the lack of a serious code-sharing story was certainly a pain point.

Using JSON (and being strict about it) is a good idea. If people really want to use Yaml, then they can write a composer.yaml, and have a build step that dumps it into composer.json. Courier does this for node projects that want to write their package metadata in coffeescript.