3,218 karma · joined May 22, 2008
I don't look at this site much.
http://blog.izs.me/
https://bsky.app/profile/isaacs.bsky.social
https://www.reddit.com/user/isaacs_/
Other comments on this page so far show predictable HN-style "Hate anything new" bias. The page is pretty easy to understand what's going on, and all of the objections don't make any sense. Good work. Ignore the bozos.
This site appeals to the absolute worst in everyone. I find myself becoming an asshole every time I come here, and I don't like that feeling.
The root cause here is that some stuff didn't get handed over properly in the switch from Ryan to me as Node.js manager. So, the emails were indeed going to a non-functioning inbox.
It's resolved now, and we're setting it up to auto-renew so that this doesn't happen again.
But does that theory actually limit what we'd predict about the future? Does it retroactively predict all the past data that we've seen? As you pointed out, Lisp was quite popular for a bit.
What if we just said, Lisp isn't popular because it didn't get/stay lucky?
That anti-theory isn't quite as satisfying, but at least it doesn't pretend at knowledge that it doesn't have.
One really nice thing, in my opinion, about JavaScript programmers is that they don't sit around kvetching about why the wrong language won. We all know it was a fluke, but the fluke happened, and here we are, so you can either squawk about languages, or get real things done instead, and improve the tools and software that you have.
I disagree. Coding directly against system calls is much harder in C, because you don't have the advantage of closures and flexible typing. But, that aside, node is intended to be a very low-level library that facilitates higher-level extensions and abstractions in userland. It is more like C than it is like Python, and that is by design.
Node is JavaScript on the server. It is not JavaScript-like, or Compiles-to-JavaScript, or Erlang-with-semicolons-and-braces on the server. We don't mess around with the language runtime, we take it mostly as-is, and there is a huge benefit to doing that.
When and if V8 implements generators (as they are likely to do somewhat soon), then I expect we'll see a lot of experimentation in this area in userland modules. They'll have to be run with a --harmony_generators flag, most likely, but they won't need to be compiled or do scary bad-touch things with threads and stacks.
When the area has been explored a bit in those userland modules, and one or a few of them are popular and good and intuitive to use, and V8 moves generators out from behind a flag, and they're fast enough to be used in node without introducing performance regressions, then we'll investigate adding something like this to node-core.
Part of the reason why you meet such backlash from people in the Node community when you complain about "callback hell" is that the model is very simple, and it really is not as bad as it looks at first. JavaScript's bulky "function" keyword does make CPS quite a bit uglier than it is in Scheme, but it's a very reasonable approach to the problem which is extremely extensible.
The crappiest part in my opinion is doing `if (er) return cb(er)` all the damn time. Domains make that a little bit easier, but you're just trading one bit of boilerplate for another, so I don't know. Generators are probably the ideal approach to that problem, but I'm personally not sure they're worth the complexity cost they introduce. I am often wrong, and try to be quick to admit it. We'll see how they change the shape of things once they're a real thing and not just an idea.
In the meantime, use named functions. Use the "async" utility. Use Stream interfaces and .pip() them to one another. And most of all, Don't write big apps! Write small modules that each do one thing, and assemble them into other modules that do a bigger thing. You can't get into callback hell if you don't go there.
Shame on you, sir. Shame on you.
Yes, but it's also sort of like a try/catch for thrown errors.
d = domain.create()
d.on('error', function(e) {
console.error('an error: ', e)
});
d.run(function() {
throw new Error("whoops")
})
When an EventEmitter is bound to a domain, their error events and any errors thrown while emitting an event on them will be handled by the domain object that they're bound to.
(It isn't.)
Many people who write code in C, Ada, Pascal, etc. call themselves programmers.
But if they were tasked with writing machine instructions or even assembly they could not do it.
And how do we know throwaway63-90 himself can even do it.
Show us throwaway63-90's machine code and let's have a look.
It's probably full of security holes.
Objects in JavaScript are not cheap, they need to carry
around lots of extra information and can be many times
larger than their C style counterparts, moreover property
access is slow.
It's much more valuable to actually prove it with numbers that show where it's fast and where it's slow.
In my experience, object creation and property access is almost never the bottleneck, and GC pauses only are relevant (in v8 at least) if you're leaking a large number of objects, especially where those objects are of mixed generations. (Ie, have a lot of long-lived and short-lived objects that refer to one another and occasionally leak.) That is, if you are getting hit with long GC pauses, then it's worth re-thinking your design and tracking down objects that may be leaking.
Newer JS engines (ie, the ones that implement TypedArrays) already highly optimize object creation and property access. The benefit therefor seems slim and highly niche. Looking at the generated code, it seems like the debugging cost is going to be very high, and it drastically increases the number of lines that the programmer has to write, which will increase bugs.
I could see the value in certain niche situations, but I would really like to see the performance characteristics explored more fully.
Put another way: What evidence could you potentially see that would convince you it's not a fad?
As some other commenters pointed out, if you pre-load the file contents, the discrepancy goes away. Also, if you actually limit vert.x to 1 CPU, it gets erratic and loses any performance benefits.
If a program spends 2% of its time in V8, 10% of its time in the network stack, and 80-something% of its time reading a file from disk, then how can you even consider that you can make it 10 times more effective by optimizing away the 2%? Even if the JVM was 100 times faster than V8, then you would expect to get faster by a factor of just slightly less than 2%.
Ie, if you were seeing 1000 requests per second before, and you're spending 2% of your time parsing and running actual JavaScript, and you make the VM go to literally zero latency (which is impossible, but the asymptotic goal), then you'd expect each request to take 2% less time. So, they'd go from an avg of 1ms to 0.98ms. Congratulations. You've increased your 1000qps server to 1020.4 qps.
On the other hand, if you take the 80% of time spent reading the file over and over again, and optimize that down to zero (again, impossible, but the asymptote that we approach as it is reduced), then you would expect every request to take 80% less time. So, your 1ms response becomes a 0.2ms response, and your 1000 qps server is now a 50000 qps server.
So, no, if you respond to 10x as many requests, it's almost certainly either a bug in the benchmark, or some apples-to-oranges comparison of the work it's doing. I called out one obvious issue like this, that the author is using a deprecated API that's known to be slow. But even still, it's not THAT slow.
You can't summon speed out of the ether. All you can do is reduce latency, and you can only reduce the latency that exists. Even if your VM is faster, that only matters if your VM is actually a considerable portion of the work being done. The JVM and V8 are both fast enough to be almost negligible.
I started using this style originally because I -- not new to JavaScript, and adhering to the "semicolons everywhere" style -- was bitten twice in rapid succession; first by a leading [ causing a function to receive "undefined" as an argument (instead of two arrays), and then again by a leading ( resulting in a non-function being called. Both were unnecessarily difficult to debug, because my brain couldn't see the error. (Even when JSLint complained, I thought it was lying. ,] looks a lot like ], at first glance, and is valid JS. Maybe I'm a little dyslexic or something.)
So, I thought, "New rule: Commas first, prefix ( and [ with semicolons." Problem solved.
But ending a line with a semicolon seemed kind of silly when I was then prefixing with a semicolon the next line, even though I'd learned that it was absolutely necessary for any kind of "safety" (even as an expert, even as a semicolon user). So, I thought, if I'm doing this silly prefixing thing to make ASI safe, why not just let it be safe, and drop them everywhere?
So I did. And it's pretty nice.
I don't understand why people get so upset about how I write programs, especially those that they don't even use or contribute to. The first time a professional JavaScripter cursed me out at the top of his lungs in a bar, literally spitting in my face while he screamed at me, I realized that there was some essential human weirdness involved here, and it became much too interesting to drop. Every time I ask people to please not lie about JavaScript to newcomers, they accuse me of being dogmatic or a semicolon hater.
But I maintain the JavaScript in Node.js as well, which follows Google's (occasionally insane) C++-inspired semicolon-ridden JavaScript style, and I'm fine with that. It's kind of nice, too, in a different way. More dots. Vim's auto-indenter works a little better.
What's wrong with just not lying? I don't get it at all. People who already know C and Java are usually veteran enough to grok weird language warts. People from Python and Ruby have an easier time learning the exceptions than sticking to the rule, since their habits are usually to omit the ceremonial EOL punctuation. And newcomers don't have any preconceptions anyway; they're busy learning why we call "this" a string, and why this is always something different, and crazy shit like "a function is an object and you construct an instance of it with new which calls it on a this that inherits from its prototype". (I mean, seriously, read that sentence to a nonprogrammer, and ask them what it means. It's gibberish!)
But people react to it like I've insulted them personally, when I just ask that they not fill newcomers' heads with lies and fud. I still don't understand it.
>>>
@douglascrockford If TC-39 makes ! an infix operator, which causes \n to not terminate the statement, then that will be a syntax change that is incompatible with current code in the wild, which would be an insanely stupid move on their part.
The fact of the matter is that JSMin isn't parsing JavaScript correctly. I thought the separation of concerns was that JSLint tells you about stupid code, and JSMin correctly parses JavaScript according to the ES standard and minifies it safely.
>>>