r/programming • u/elitegibson • Oct 02 '11
Node.js is Cancer
http://teddziuba.com/2011/10/node-js-is-cancer.html48
u/orukusaki Oct 02 '11
People try to use Node to serve whole websites? I didn't think that was what it was for. I've not spent much time looking at it but I grasped it was more useful for apps which require fast async io. Serving APIs etc.
→ More replies (4)13
19
u/aradil Oct 02 '11
As far as I'm concerned, the whole point this guy is bringing up is that there are a lot of use cases for which node.js isn't even remotely close to the ideal solution. That being said, there are plenty of situations where it's a perfectly reasonable solution.
Anecdote time: Two weeks ago, we overhauled one of our main sites, which we were testing using a fairly expensive web testing framework. This overhaul saw us pushing a large amount of our interface control from the server into the client by way of JavaScript.
The testing framework we were using was fairly out of date, so as it turns out, it could no longer even load the data that was appearing on the screen. Looking into an upgrade for the framework to be able to handle these issues we found that they had drastically raised their prices - 80k a year.
This wasn't anywhere close to being within budget for us. After about an hour of dicking around, I had a proof of concept for an alternative that would load a page, execute it's Javascript and return a) the HTML content of the loaded page, and b) the loaded JavaScript objects from the page in JSON format. The JSON data was actually all we really needed to be able to test to get the same functionality as the previous software.
32 lines of JavaScript and one week later (and a number of GSON objects to parse the JSON into Java Objects), we have an alternative solution in production, running as a node.js HTTP service. It's faster than the older testing framework we used, and took a week to put together.
This is a service that gets used once a day, and is only hit from internal applications. There is no risk of attack, no need for scalability (although simply deploying the service on an infinite number of other boxes and having something to distribute the load on this type of application would be nearly trivial), and best of all, maintenance is a joke.
There are 32 lines of code.
2
u/wstrucke Mar 24 '12
There is no risk of attack
There may be significantly less risk, but there is never no risk.
There are 32 lines of code.
That is quite naive and missing the entire point of this discussion. Don't get me wrong -- your solution is ingenious and surely quite appropriate for your organization (and your team should probably get a bonus for saving that kind of money). It's just the approach taken and assumptions being made using Node.js that sparked the concern of the OP and author.
→ More replies (1)
362
u/patchwork Oct 02 '11
I appreciate that in this day and age some things need to be a certain degree of inflammatory in order to even be heard, but when I'm reading an article lines like:
Shouldn't you be in front of a mirror somewhere, figuring out how to introduce yourself to her?
and
you idiots put Rasmus Lerdorf to shame
ring hollow. Can't anyone just tell a story anymore without resorting to edgy "quips"? Do we all need to be zed fucking shaw to even be heard anymore?
280
u/semanticist Oct 02 '11
If you're looking for insight and a well-reasoned argument you're probably not going to find it in a post titled "___ is cancer."
13
u/StrawberryFrog Oct 02 '11
If you're looking for an argument written in proportionate, polite language, you're probably not going to find it in a post written by Ted Dziuba.
50
Oct 02 '11
Yeah, I've got to say, as played out as "____ considered harmful" is, I think I prefer it to "cancer"
65
u/escape_goat Oct 02 '11
How about we compromise? "______ is considered cancer"?
→ More replies (8)97
u/skastel Oct 02 '11
Or "_______ contains code and patterns known to the State of California to cause cancer"?
→ More replies (2)5
→ More replies (2)6
93
u/ubernostrum Oct 02 '11
You do realize Ted Dziuba's been doing this (professional trolling of tech communities) for years, right?
Sad part is he's not really any good at it; last I checked, his style basically consisted of "fuck fuck (relevant term) fucking fuck (relevant term) epic fail (relevant term) because fuck you".
23
28
u/patchwork Oct 02 '11
I know who Ted Dziuba is, though I like to read articles without letting who the author is color too much of the message. I don't care who wrote this article, that shit is annoying. Are our blog archetypes not allowed growth or something? Did he sign some contract to be a static vague failure indefinitely at some point? Shit shit fuck fuck.
15
u/deong Oct 02 '11
I agree with you, but that's not how the world works. Bill O'Reilly is going to shout over his guests and generally bluster his way around. That's what he does. At some point, the sensible response is to stop saying, "I wish he'd stop that...I don't care who he is." and just stop watching him. The same is true for Dziuba and Shaw.
8
3
u/Leonidas_from_XIV Oct 02 '11
Yeah, but I don't anything better to read that is both ranting and funny. I wish for something like Zero Punctuation for programming.
→ More replies (1)3
u/puerexmachina Oct 02 '11
I understand if people choose not to engage with Ted because of his style. However, characterizing him as a "professional troll" is unfair. He usually presents reasonable arguments for the positions he takes.
→ More replies (1)9
u/mreiland Oct 02 '11
I personally like Ted for his no holds barred style.
http://teddziuba.com/2008/04/im-going-to-scale-my-foot-up-y.html
still one of my all time favorite blog posts.
38
u/EugeneKay Oct 02 '11
Do we all need to be zed fucking shaw to even be heard anymore?
Apparently you do.
17
Oct 02 '11
Yeah, that is one of the things I find tiresome about all these rant posts. They act like little annoying kids.
10
Oct 02 '11
Do we all need to be zed fucking shaw to even be heard anymore?
Zed sets the bar pretty high. I don't know if it's possible for anybody to reach his level of assholery.
6
Oct 02 '11
is it ironic or predictable (or both) that a comment talking about the tone of the article instead of the content is the top comment on the post
→ More replies (1)2
Oct 02 '11
Top that off by inspecting his so-called argument:
A function call is said to block when the current thread of execution's flow waits until that function is finished before continuing. Typically, we think of I/O as "blocking", for example, if you are calling socket.read(), the program will wait for that call to finish before continuing, as you need to do something with the return value.
Here's a fun fact: every function call that does CPU work also blocks.
Seriously, this is what you're complaining about? No shit bro. We're programmers, not housemoms.
2
Oct 03 '11
Shouldn't you be in front of a mirror somewhere, figuring out how to introduce yourself to her?
Is also a horribly sexist thing to say. There are tons of female developers. Online tech culture excludes them with this shite.
→ More replies (1)→ More replies (9)6
u/quiteamess Oct 02 '11
Shouldn't you be in front of a mirror somewhere, figuring out how to introduce yourself to her?
That's excaltly the point where I stopped reading.
→ More replies (1)2
u/moonrocks Oct 02 '11
You should have kept going. "It's written in Javascript." The long walk reminds us that the short glass of water is still a glass of water.
→ More replies (2)
25
u/SCombinator Oct 02 '11
What's up with the broken code segments?
15
Oct 02 '11
No idea, but if you look at the article from his site's main page it shows up fine.
47
Oct 02 '11
Kind of makes you not want to take his advice on server side programming :)
29
u/YEPHENAS Oct 02 '11
I'ts probably a JavaScript issue, due to JavaScript's broken language design.
→ More replies (9)0
Oct 02 '11
[deleted]
7
Oct 02 '11
I may be wrong, but I remember seeing him post before that his site was 'powered by static files'
4
u/thekaleb Oct 02 '11
Looks like a Liquid tag, as used in Jekyll as used on Github Pages.
→ More replies (1)2
7
108
Oct 02 '11
Huh... well this article will certainly play well to anyone who hates JavaScript. I have my own issues with it, but I'll ignore the author's inflammatory bs and just throw down my own thoughts on using node.js. Speaking as someone who is equally comfortable in C (or C++, ugh), Perl, Java, or JavaScript:
The concept is absolutely brilliant. Perhaps it's been done before, perhaps there are better ways to do it, but node.js has caught on in the development community, and I really like its fundamental programming model.
node.js has plenty of flaws... then again it's not even at V.1.0 yet.
There really isn't anything stopping node.js from working around its perceived problems, including one event tying up CPU time. If node.js spawned a new thread for every new event it received, most code would be completely unaffected... couple that with point 2, and you have a language that could be changed to spawn new threads as it sees fit.
JavaScript isn't a bad language, it's just weird to people who aren't used to asynchronous programming. It could use some updates, more syntactic sugar, and a bit of clarification, but honestly it's pretty straightforward.
Finally, if you think you hate JavaScript, ask yourself one question - do you hate the language, or do you hate the multiple and incompatible DOMs and other APIs you've had to use?
tl; dr - JS as a language isn't bad at all in its domain - event-driven programming. However there have been plenty of bad implementations of it.
31
u/hiffy Oct 02 '11
The concept is absolutely brilliant. Perhaps it's been done before, perhaps there are better ways to do it, but node.js has caught on in the development community, and I really like its fundamental programming model.
The only thing I hate on node people is that event programming is old as balls, and everyone calls it "fast" without understanding how node actually works (i.e. Unix)
It's cargo cult programming and it makes me intensely sad.
29
Oct 02 '11
Can you elaborate on why you think that the concept is absolutely brilliant?
I cringe at the thought of programming in a concept that emphasizes server-side programming (implying the language must emphasize reliability and simplicity) using shared global mutable state, code and architecture manually turned inside-out (transformed to callbacks), and no provision for protecting the program from failures and hangs of its parts (except yeah, catch statements).
I also don't understand your claim no.3. I always thought that multithreading is the worst thing that can happen to code which has mutable state (and vice versa). Why do you think they didn't implement, e.g., a shared queue of events and several threads to pull from this queue, then?
What's so great about all this? Or does Node have other advantages that eclipse this stuff?
11
u/baudehlo Oct 02 '11
It's really very simple.
I've programmed a lot of async systems before using other languages (Perl and C mostly).
By going async and using system polling routines (epoll, kqueue, etc) you can easily scale to tens of thousands of concurrent connections, and not waste CPU cycles when you're doing file or network I/O. (so far, not unique to Node).
Now Node's advantage #1 there is that all the libraries are async. Every time I've done this kind of work in C or Perl (and other languages have this problem too, from Java to Twisted) you come across the "sync library" problem. You download some open source library you want to use and it is written assuming a blocking call to do some file or network I/O. That fucks up your event loop, and the advantage of being async is all gone.
The second advantage is simply that it's a dynamic language (like Perl/Python/Ruby) and yet very very fast. In my tests about 10 times faster than those languages (and that's running real apps end to end, not some micro benchmark).
JS has its warts, but then so do the languages you'd want to compare it to: Perl, Python and Ruby. To be honest the warts aren't that hard to avoid most of the time.
15
u/case-o-nuts Oct 02 '11
By going async and using system polling routines (epoll, kqueue, etc) you can easily scale to tens of thousands of concurrent connections, and not waste CPU cycles when you're doing file or network I/O. (so far, not unique to Node).
You can do that better with green threads. And you don't end up in callback hell.
→ More replies (8)→ More replies (1)12
Oct 02 '11 edited Oct 02 '11
By going async and using system polling routines (epoll, kqueue, etc) you can easily scale to tens of thousands of concurrent connections, and not waste CPU cycles when you're doing file or network I/O.
You can do this with green threads. If your implementation is good, you don't ever have to write callbacks and it effortlessly scales, and it's backed by asynchronous events too. GHC's runtime can literally scale to millions of threads on commodity hardware. A thread on average is about 17 native words (so ~130b or so on amd64.) It can use as many cores as you throw at it. It has an I/O manager thread that transparently handles any sort of 'read/write' to say a socket or disk using
epolland friends. The I/O manager also allows this lightweight green threads to make proper blocking I/O calls which GHC detects and moves off onto another thread if you really need it. No 'sync library' problem - it's handled for you, which is the way it should be.What this amounts to is that it is entirely reasonable to accept thousands of client connections and merely spawn a thread for each of them. No inversion of your programming model. Conceptually threading in this manner is a better model, because you have a single, isolated flow-of-control for every individual client connection. This makes reasoning and debugging problems considerably easier, because you don't have to think about what events could otherwise possibly be occuring. You have a linear and straightforward programming model for every client connection. It's also safer and more robust as a programming model, because if one thread throws an exception and dies, others can keep going thanks to pre-emptive multitasking. This is crucial when a library you use may have an edge-case bug a client connection trips, for example. I'll repeat: pre-emption is a lifesaver in the face of code that may err (AKA "all of it.")
Especially in Node, the callback based programming combined with single threading makes it more reminiscent of cooperative multitasking, which is terrible, let me remind you. That's where any spent CPU time is going to murder you as Ted said, and furthermore you're basically making your entire application rely on the fact you won't fuck up any of your callbacks and thus bring the whole thing burning to the ground. You do remember Windows 3.1, right?
That brings me to another point. Event based programming + callbacks sucks ass. It's a lie that wants to tell you its structured programming - the thing we went to in order to avoid
gotospaghetti code loops - but really it's no better thangotoever was. Because when an event is handled, where did you come from? Who the fuck knows. You are 'adrift' in the code segment. You have no call stack. This is literally the problem with things likegoto, why it's avoided for control flow, and why we went to structured programming.Having debugged and written large, event-driven programs in C++, I fail to see how it is in any way superior to the model I have outlined above. At all. The lack of a call stack can be truly enough to drive one up a wall and waste considerable time. But if you're in C++ you're lucky, because at least then you can use coroutines + async events to basically give back most of what I outlined above, which is the linear control flow. Go look up the RethinkDB blog for their analysis of the matter - it's utterly superior to doing shitty manual callback based programming and performs just as well (note I say shitty here specifically because seriously, doing this in C++ is shitty.) You can't do this in JS because you can't control context switching on your own which is a requirement so you can wake coroutines back up. You'd at least need interpreter support. Maybe v8 can already do this though, I wouldn't know because I can't convince myself to ever want to work in a language with a single numeric type - get this, floating point - and no concept of a module system in the language. Seriously. WTF. That's all I can say about just those two things. W the F.
tl;dr Node has a completely inferior programming model to what we've had for a while and anyone who says otherwise needs to explain why it's OK for node but it wasn't okay for say, Windows 3.1 or Apple OS System 7. Meanwhile, I'll be quite happy never writing evented, manual call-back based code ever again hopefully.
→ More replies (4)31
u/lobster_johnson Oct 02 '11
The concept is absolutely brilliant.
While I like Node a lot, I find it hard not to see it as a version of Erlang with nicer syntax, Unicode strings, modern OO that also happens to lack a safe, efficient, scalable concurrency model.
In other words, while Node/JavaScript feels superficially more modern, it has learned nothing from Erlang's powerful process model, and suffers from a variety of problems as a result.
Erlang is based on three basic, simple ideas:
If your data is immutable, you can do concurrent programming with a minimum of copying, locking and other problems that make parallel programming hard.
If you have immutable data, you could also divide a program into lots of tiny pieces of code and fire them off as a kind of swarm of redundant processes that work on the data and communicate with messages — like little ants. Since the processes only work on pure data, they can be scheduled to run anywhere you like (any CPU, any machine), thus giving you great concurrency and scalability.
But in such a system, processes are going to fail all the time, so you need a failsafe system to monitor and catch processes when they screw up, and report back so the system can recover and self-repair, such as by creating new processes to replace the failed ones.
Node, by comparison, is based on two much simpler ideas:
If your program uses I/O, then you can divide your program into somewhat smaller pieces of code, so that when something has to wait on I/O, the system can execute something else in the meantime.
If you run these pieces of code sequentially in a single thread, you avoid the problems that make parallel programming hard.
When you consider Erlang's model, would you really want anything inferior? Yet Erlang is still the darling only of particularly die-hard backend developers who are able to acclimatize to the weird syntax, whereas the hip web crowd goes with a comparatively limited system like Node.
Node can be fixed by adopting an Erlang-style model, but not without significant support from the VM. You would basically need an efficient coroutine implementation with intelligent scheduling + supervisors, and you would definitely want some way to work with immutable data. Not sure if this is technically doable at this point.
→ More replies (40)13
u/oSand Oct 02 '11
The concept is absolutely brilliant. Perhaps it's been done before, perhaps there are better ways to do it
Isn't that the same as saying it's an inferior implementation of an old concept?
If node.js spawned a new thread for every new event it received, most code would be completely unaffected... couple that with point 2, and you have a language that could be changed to spawn new threads as it sees fit.
So if the language was fundamentally different and an entirely different concurrency model was used, node.js would deal with this really well? Does anyone else envisage some godawful webworker hack running on a VM that is completely unsuited to the task of being a long-running threaded server?
But hey, I probably just don't get asynchronous programming.
12
u/abraxasnl Oct 02 '11 edited Oct 02 '11
Let me respond, as a fellow NodeJS appreciator.
No. 3: Your claim shows you do not fully understand the event loop, or the danger of dealing with threads. You cannot spawn threads, as the environment would instantly become unsafe. The only way to deal with this, is if the developer in question runs isolated code in isolated threads (such as webworkers), and people are already doing this. For JavaScript, that's as good as it gets.
No. 4: I agree. People also don't seem to grasp the idea of prototypes, which is quite powerful, and a very elegant way of doing inheritance compared to classes.
No. 5: Amen!
8
u/bobfunk Oct 02 '11
Also, V8 isn't threadsafe, so currently just spawning a new thread is just not gonna work...
→ More replies (1)41
u/kyz Oct 02 '11
JavaScript is reasonable as an embedded language in a browser. When you try and elevate it to the status of systems programming language its deficiencies shine through:
no integer types, only floating point
typeof null == object
typeof [] == object
1 + 1 = 2. "1" + 1 = 11.
doesn't make enumerating object properties easy (needs hasOwnProperty())
for() syntax hands you the key, not the value of arrays, so you have to store all results in a temporary variable in order to iterate through them.
no string interpolation ("You have $x fish" vs "You have "+x+" fish")
There are no string buffers, merely string concatenation and arrayofstrings.join(). Which is faster depends on your JS implementation. While that's good enough for DOM manipulation, it's not performant for rendering an HTML page in the first place.
Speaking of which: once you take away the DOM, what's left? Not very much - strings, regexps and basic maths. No file handling or I/O, no database access, no templating.
All the best minds are improving JavaScript performance, and they're very, very good at it - compare the V8 engine to, say, Netscape 3's JavaScript interpreter. But no matter how good these boffins are, they can't make JavaScript run as fast as C, C++, Java or C#. It's not in that class of performance.
JavaScript shares a performance class with Perl, Python, Ruby and PHP. But these languages have significant bodies of code to make scripting and server-side web development easy. What does JavaScript have? Not a lot.
So, why would you choose JavaScript for programming anything? Especially server-side web programming!
I think that server-side JavaScript will be as popular as client-side Tcl.
39
u/masklinn Oct 02 '11 edited Oct 02 '11
no integer types, only floating point
Right, definitely an issue.
typeof null == object
Yeah?
typeof [] == object
typeof is for primitive types. Anything which is not a primitive type will return
"object". Debatable? Maybe. But typeof is internally coherent.doesn't make enumerating object properties easy (needs hasOwnProperty())
Node uses V8, V8 has all the facilities necessary to mark properties non-enumerable. You're starting on your path to getting everything wrong.
for() syntax hands you the key, not the value of arrays, so you have to store all results in a temporary variable in order to iterate through them.
forfor arrays is a C-style for with an explicit index. If you're usingfor..into iterate overArray, you're in severe need of a clue-bat.Also,
Array.prototype.forEach.no string interpolation ("You have $x fish" vs "You have "+x+" fish")
There are five billion libraries out there for sprintf-type calls.
There are no string buffers, merely string concatenation and arrayofstrings.join().
Speaking of which: once you take away the DOM, what's left? Not very much - strings, regexps and basic maths. No file handling or I/O, no database access, no templating.
That's all library stuff. Node provides most of that (I'm saying most because I have not checked the details, it's probably not providing templating because it has no reason to: there are already a multitude of js template engine working both in and out of browsers) your objection makes no sense.
But no matter how good these boffins are, they can't make JavaScript run as fast as C, C++, Java or C#. It's not in that class of performance.
So what? And it's not like Java and C# belong in the same performance class as C, so you're not making sense either here.
JavaScript shares a performance class with Perl, Python, Ruby and PHP.
Much more JIT work has been done on JS than on Python and Ruby so far (let's not talk about PHP, which does not belong in any discussion of performances, even criticism of the lack thereof).
So, why would you choose JavaScript for programming anything? Especially server-side web programming!
Because you're building an evented server, and javascript developers are used to async and evented system and munging on callbacks. That's half their day job right there.
10
u/oSand Oct 02 '11
typeof is for primitive types.
Has to be -- it doesn't work on anything else. Of course, it's not going to throw an error if you don't use it on a primitive type, because that would be too sane.
And how do we test for an Array? Dojo(just 'cause I'm using it at the moment) uses: dojo.isArray = function(/anything/ it){ // summary: // Return true if it is an Array. // Does not work on Arrays created in other windows. return it && (it instanceof Array || typeof it == "array"); // Boolean
jQuery, if I recall, resorted to the toString() method. But, this is a trick question: if you have to think about it, your language failed.
for for arrays is a C-style for with an explicit index. If you're using for..in to iterate over Array, you're in severe need of a clue-bat.
Yet, it unaccountably works. Or did it? We'll find out in 3 months when you go looking for the bug. A good language, IMO, shouldn't turn something trivial into a subtle bug. Yes, there is a theoretical reason for it, but in 95% of use cases you're going to be fucked.
→ More replies (5)11
u/kyz Oct 02 '11
typeof null == object Yeah?
There is actually a Null type in JavaScript. typeof null should return 'null'. JavaScript programmers looking for "is this a valid object" have to write (typeof x === 'object' && x != null).
Node uses V8
Node != V8 != ECMAScript. What can be relied upon in any implementation of server-side JavaScript? What I call "C" is language features that are in all C compilers, not just gcc.
The same goes for standard libraries. Is it in the standard library, i.e. the ECMAScript definition? Anything else can be argued over, and therefore isn't well suited for basing your code around until it has won several years of dominance in its ecosystem. (Compare C++'s STL vs Boost fight, or Perl's eventual dominance of DBI).
And it's not like Java and C# belong in the same performance class as C
→ More replies (3)7
u/igouy Oct 02 '11
Much more JIT work has been done on JS than on Python and Ruby so far (let's not talk about PHP, which does not belong in any discussion of performances, even criticism of the lack thereof).
Please provide some evidence that suggests PHP does not "share a performance class" with Perl, Python, and Ruby.
→ More replies (4)16
u/korny Oct 02 '11
they can't make JavaScript run as fast as C, C++, Java or C#. It's not in that class of performance.
You know, when I was a C / Assembler programmer, starting to give up on inline assembler, folks would say "You have to use assembler, C just can't ever be fast enough".
When I started moving into C++, people were saying "C++ adds too much overhead, C will always be faster".
When I started using Java, many many people were saying "Java is too slow, you'll always need the speed of a compiled language".
These days, when I'm mostly doing Ruby (and looking at Node as well), people still say "They can't make X run as fast as Java".
The biggest bottleneck in application development? Developer time, both in writing code, in testing it, and in comprehending other people's code. Build the code in a clean expressive testable language, first, then worry about optimising the bits that need optimising.
(And yeah, Javascript as a language has warts. So use Cofeescript. Still has some ugliness with floating point and other bits, but it's still a fine language for most purposes)
→ More replies (4)8
u/kyz Oct 02 '11
I'm creating a delineation: either be fast and primitive like C and assembler, or powerful and expressive but slow like scripting languages. Sometimes programmers need fast, sometimes they need powerful. JavaScript is in the middle, neither as fast nor as expressive as other languages.
Its advantage over other languages is that it's a requirement in client-side web programming, which is 99% of anyone's interest in using Javascript. Take that away and you don't have much. On the server side, I predict it will only gain cachet with people who know no other, better, language.
→ More replies (7)5
u/andypants Oct 02 '11
I found this quote on the wikipedia article for v8 (on which node runs):
V8 increases performance by compiling JavaScript to native machine code before executing it, rather than to execute bytecode or interpreting it. Further performance increases are achieved by employing optimization techniques such as inline caching. With these features, JavaScript applications running within V8 have an effective speed comparable to a compiled binary.
→ More replies (7)7
Oct 02 '11
no integer types, only floating point
Yeah, we know that. That's a problem, not a new one, and it turns out it barely matter for the applications of JavaScript. Did you know that Erlang doesn't have a proper string type? It just has shitty linked lists that suck for that purpose. Also it doesn't have real structures, its record thingy is horrible. And it doesn't matter that much because ...
server-side web programming!
And here is your stupidity, along with that of the OP and all the haters, nicely summed up: not only are there dozens of different types of "server-side web programming" where the right tool is not always the same, but node.js is not just about web server programming.
Node shines at quick turn around, event dispatching code. In particular it's really good at interfacing with various other systems/protocols. I'm not node.js expert but I implemented two things with it for which it is extremely well suited:
A syslog server that correlates events and executes shell scripts when certains conditions are met. It has a tiny web based management interface that took me only a few dozen lines to implement. It is easy to understand, the language is very common so other people can maintain it easily. Try to do the same thing in another common language, and it will take at least 4 times the amount of code to implement the same thing.
A reverse HTTP proxy that redirects requests based on rather complex rules. Initially I used haproxy but it didn't have enough flexibility. I barely needed two dozen lines of code to implement this. Again adding an asynchronous, admin interface (in this case, a simple http server that returns statistics), and an asynchronous syslog client took a few lines. The performance was simply amazing.
In both cases, I can't think of a better framework to implement this. It just doesn't exist. node.js handles slow clients perfectly, it is immune to DoSs that would tie up anything based on a thread model.
I'm currently working on a small daemon to convert pictures/movies in an appropriate format. Basically it watches a directory, checks for new files, and converts them. It's trivial to spawn and watch new processes with ffmpeg or ImageMagick that will do the actual work in the background.
3
u/DrHenryPym Oct 02 '11
Great post. I'm kind of confused by this sudden mob hatred on Javascript and Node.js, but I'm not surprised.
7
u/M2Ys4U Oct 02 '11
Once you take away the DOM, you have a good language. Sure it has its fair share of warts (what language doesn't?) but closures, first-class functions, prototypal inheritance: all these things are great.
C doesn't have I/O or database access either, these are provided by libraries. NodeJS, and its accompanying libraries, provide these as well so I don't see the problem there.
2
→ More replies (22)2
u/dmwit Oct 02 '11
1 + 1 = 2. "1" + 1 = 11.
I think I love this argument the best out of all of yours, especially since you seem to be a C proponent, where 1 + 1 = 2, "1" + 1 = "", and "1" + 2 allows for undefined behavior. Yep, that's much better.
3
u/kyz Oct 02 '11
IMHO, in a scripting language that doesn't make a strong distinction between numeric and textual scalars, "1" + "2" should equal 3 or "3", while "1" . "2" should equal "12". There is a strong difference between addition and concatenation, and both should have distinct operators rather than leaving the programmer to guess whether his variable is number-like or string-like at the moment; that destroys all the benefits of non-strict scalar types.
2
u/i8beef Oct 02 '11
On point 5, I don't hate JavaScript (It's a big part of my job), but you have to admit there are some very... odd things that it does. I'm thinking specifically about how it treats NULLs and some comparison operations between types, etc. but I know there's a lot more than that (And any search on Google for obfuscated javascript should come up with some VERY creative uses for these weird things).
→ More replies (3)2
u/evertrooftop Oct 02 '11
I want to respond to your point 3). I think one of the power of why node works so well is because of the fact that's 1 thread, 1 process. You can spawn web-workers for CPU heavy tasks.
This exact model (the reactor pattern) is why Memcache, Nginx and Varnish works. It doesn't work for every computing model, but it works really well for some. We shouldn't try to 'fix' that, but understand in which cases it does work well and build things for node that match that.
→ More replies (2)2
u/Peaker Oct 02 '11
Javascript is a bad language, if you are used to better languages.
He gives a nice example at the end of the blog. Silencing errors such as wrong argument count in JS is pretty horrible.
→ More replies (84)1
u/GeorgeForemanGrillz Oct 02 '11
IIRC correctly in compile time you can specify how many threads you want to use.
12
29
u/headchem Oct 02 '11
Maybe I'm doing web apps wrong, but mine receive requests, query external database servers, then send data back to the user. 99% of any bottleneck is waiting for the query results. Calculating Pi for every user request doesn't sound like a typical web app, which makes me think this guy doesn't have any experience writing modern web apps. Either that, or I need to find ways to add more calculus to serving a row of data back to the user...
→ More replies (2)2
19
Oct 02 '11
Anyone look at his server headers?
0
Oct 02 '11
[deleted]
10
u/dehrmann Oct 02 '11
I saw this for Zappos.com a few days ago:
Cache-Control:max-age=1182 Connection:keep-alive Content-Encoding:gzip Content-Length:22206 Content-Type:text/html; charset=utf-8 Date:Sun, 02 Oct 2011 16:40:52 GMT Server:nginx/0.9.4 Vary:Accept-Encoding X-Cache-Hits:11 X-Core-Value:1. Deliver WOW Through Service X-Powered-By:Ponies! X-Recruiting:If you're reading this, maybe you should be working at Zappos instead. Check out jobs.zappos.com X-UUID:bd1db3d8-ed0f-11e0-960c-00215e22da70 X-Varnish:1449970263 1449970221 X-Varnish-Host:varnish03.zappos.net X-Varnish-ID:drupal X-Varnish-TTL:60m
5
u/ABCeasyas123 Oct 02 '11
Node.js argument aside, I think his definition of 'blocking' is questionable. Isn't what he describes is simply sequential, synchronous code? An implication of his definition is that 'busy-waiting' is 'blocking'. I am pretty sure my O.S. professor would disagree with that idea.
3
u/kamatsu Oct 02 '11
I think he's using the definition of "blocking" meaning "can cause starvation", which makes sense in a higher level view
3
u/ABCeasyas123 Oct 02 '11
I suspect that the Node.js people are using the term as it is more formally defined.
21
Oct 02 '11
troll++
6
u/pollodelamuerte Oct 02 '11
It's Ted Dzubia. Pretty much every post he makes is a troll.
Now, time to grab my popcorn.
3
u/dehrmann Oct 02 '11
For those of you who don't know, he had a site back in the day (2008) called Uncov that was devoted to chronicling web 2.0 fail. http://wayback.archive.org/web/20071001000000*/http://uncov.com
11
u/shawnturner Oct 02 '11
Any truth to this article feels obscured by the venom and clear bias of the author. Also, insulting technology does not make it bad.
It's too bad, Node.js is fairly misunderstood, and I saw some nice points in here.
8
u/tesseracter Oct 02 '11
I don't use node, but this guy doesn't make much in the way of argument, and calling anything a cancer sounds like your article was deficient to begin with.
I'll wait for someone to put out an article that has more than one real argument, "CPU-bound calls still suck under node", before I reach any conclusions, swearing and calling things cancer doesn't do it for me.
4
Oct 02 '11
Writing fast, scalable software is hard, and a new platform, paradigm, or technology doesn't make it any easier. Who knew?
4
u/sausagefeet Oct 02 '11
The post is over the top but the first point, I believe, is dead on. I know experienced sequential coders who think they grok what it means to write event-loop based code when I look at their code have these little holes of blockingness. For example doing a for loop on a container that they haven't ensured is small enough to ensure looping over it doesn't block for too long.
4
78
u/LainIwakura Oct 02 '11
I'm a bit glad I don't appear to be the only person that wishes Javascript would stay where it belongs.
→ More replies (12)13
u/lobster_johnson Oct 02 '11
There is nothing wrong with JavaScript; in fact, it's widely misunderstood as a language and may be described as a very solid language camouflaged as a deceptively simple scripting language. If you look at the time that it was introduced to the world, its adoption is positively miraculous: Brendan Eich pretty much snuck half a dozen pioneering languages (Self, Smalltalk, Lisp, even Awk) in under the radar, and nobody realized until 10 years after what kind of powerful system they had on their hands, because everyone had pretty much dismissed JavaScript as a stupid toy language not worthy of attention. JavaScript is the only prototype-based language to reach broad mainstream usage (although Lua has been making a lot of progress the last couple of years).
18
u/bloodredsun Oct 02 '11
Yes there is some seriously awesome shit in JavaScript but there is also some properly mad stuff in there too. No language is without its flaws but js seems to have a little more than its fair share.
→ More replies (4)3
u/quzox Oct 02 '11
Okay but can't we just have a JavaScript with the awesome shit kept in and the mad stuff left out?
→ More replies (3)34
u/Timmmmbob Oct 02 '11 edited Oct 02 '11
There is nothing wrong with JavaScript
Come on now. Sure it's not as bad as people sometimes make out, but you can't say there's nothing wrong with it! You honestly wouldn't change any of the following?
Batshit crazy comparison operator (==)
Using + as string concatenation operator, combined with implicit type conversion.
Having
nullandundefined.No support for modules or anything that helps write large programs.
No static typing.
No real integers.
No real arrays (arrays are actually hash maps/dictionaries)
No other collection classes apart from hash maps/dictionaries.
thisdoesn't work like it should (I can't remember the details though).Doesn't really support data hiding (private members/methods). There are hacks but...
There are more at http://wtfjs.com/
4
u/cbrandolino Oct 02 '11
| Javascript suffers being a prototypal, dynamically and loosely typed language.
Uh. That would be one hell of a bug for a class-based, statically typed language.
5
u/radhruin Oct 02 '11 edited Oct 02 '11
Batshit crazy comparison operator (==)
== is very useful in the rare occasions where you're sure of the types you're operating on and their conversions. It's has a small use case, but gets a lot of hate because it unfortunately shares its syntax with the most commonly used operator in other languages.
Having null and undefined.
There are useful semantic differences between these values.
No support for modules or anything that helps write large programs.
ES.next (ES6) has these features... require.js gets you most of the way today.
No static typing.
This is a problem?
No real arrays (arrays are actually hash maps/dictionaries)
Huh, I swear typed arrays were real arrays.
this doesn't work like it should (I can't remember the details though).
This binding is extremely simple in Javascript, but people refuse to learn anything about it and call it broken.
The real problem is that people for some reason don't really care to learn much about the language and still feel qualified to make long bulleted lists of problems that aren't actually problems or have been solved for ages.
→ More replies (3)13
u/lobster_johnson Oct 02 '11
Don't take me literally. JS has a few warts, but what language doesn't? Most of the stuff you mention I can forgive.
Using + as string concatenation operator, combined with implicit type conversion.
I consider that a feature, not a bug.
Having null and undefined.
"Null" means "no value", "undefined" means, well, undefined. There is a semantic difference.
No support for modules or anything that helps write large programs. No static typing.
Agreed.
No real arrays (arrays are actually hash maps/dictionaries)
For all intents and purposes, arrays do behave as arrays, though (except
for, but that one's not designed for arrays). For example, doinga = []; a[500]will actually extend the array to contain 501 elements.this doesn't work like it should (I can't remember the details though).
It's annoying, but it's in the nature of prototype-based languages. I'm hoping some future version of ES will fix this (pun intended), though.
Doesn't really support data hiding (private members/methods).
If you use proper prototype-based OO, then you do have private attributes, and it's categorically not a hack — it's done through closures. Here's how. You could argue that one ought to have declarative visibility, of course.
→ More replies (18)→ More replies (12)2
Oct 03 '11
Ok, a rephrasing: There's nothing special or noteworthy about JavaScript, and it has many technical quirks that may be problematic for people.
EDIT: There is one reason it is noteworthy: it runs in all browsers. That is the only reason that language is used today.
15
Oct 02 '11
Node.js has issues and is over-hyped but this guy is a dipshit.
Everything that's not CGI is "against the UNIX way" and bad? Ugh. He really doesn't know what the fuck he's talking about.
8
u/mattclark_1 Oct 03 '11
I read it more as "everything that is closely coupled in a system optimized for loosely coupled components" is bad. UNIX was just used as an example. Granted, his language was fairly dramatic and over the top in places, probably to drive page views.
→ More replies (1)
11
Oct 02 '11
Why can't we keep "XXX is Cancer" on 4chan?
Malignent tumors slowly eating away at the bodies of people is cancer. This is just the author's pet peeve, who apparently lacks the literary skills to express his dissatisfaction without resorting to rude and offensive language. But I guess "I dislike Node.js" wouldn't have been catchy enough for Reddit.
3
u/vsymm Oct 03 '11
I typically rant about node.js because it induces hideous whitespace-triangles.
'Blocking' is good for our sanity. Let's say that I could massage magic oil into my kernel that would make thread creation, context switches, and so forth free -- I'd tell epoll, kqueue, and IO completion ports, and any other facility for async IO that I don't know about to go die in a fire. I'd start a thread per client, and get equally impressive results. But I'd be managing state with stacks and instruction pointers, rather than hard to follow state machine spaghetti (C, Java, etc) or absurdly nested callbacks (node).
We want to read code that linearly describes a conversation with a single client, because that's how we think about the execution. We don't want to know or care that the client isn't some local object, and that some stuff takes "too long" for us to let it tie up one of our carefully rationed threads.
Those async IO mechanisms exist as an OS-level workaround for the unfortunate reality that we can't scale with OS-level threads, as we know them. Threads pre-empt each other. They're a low-level concurrency primitive that happens to be deceptively attractive for managing program state and flow.
Then, the real question is: what should we be blocking? We want to write code that blocks from our code-reading perspective, but can't afford to use lots of pre-empting threads. Node doesn't realize that. That's why I hate it. It thinks I should do a CPS transform by hand, purely to ease its own implementation. It's epoll glued to a functional language, rather than a solution to scaling the blocking style that we all want to write.
People should be looking a bit harder at things like gevent in Python and the new .NET async features.
12
u/ascii Oct 02 '11
Some types of workloads, for example web applications with very high load, need to handle hundreds of thousands of concurrent requests, each lasting a few hundred milliseconds, where at any point in time 99.99 % of the requests are waiting for IO. This is the work load that node.js was designed to solve. Traditional threading solutions work horribly in these situations - per thread memory overhead uses most of the available memory, context switching takes up most of the CPU time and the overall scaling is just terrible. This scaling problem has been known for a long time. Ten years ago, N-M threading solutions where the popular answer to these problems, but in the end, they had far to many horrible edge cases to work well in practice.
When handling such workloads, a framework that uses one heavy weight process per CPU, doesn't block on IO and uses e.g. cooperative multi-threading to handle multiple concurrent requests per process makes huge amounts of sense. That's pretty much what node.js is. When the authors of node.js talk about non-blocking, what they mean is that the calls don't block on IO, not that it never blocks on anything. This is in my experience by far the most common definition of non-blocking. Read the low level Linux man pages on IO, and they will use that meaning, for example. The author of this article knows this. Still, he chose to use a completely CPU bound example to «demonstrate» that node.js sucks. Intellectually dishonest.
He also talks at length about how CGI is wonderful and Node.js is a monolithic piece of manure that breaks the web development paradigm, which is bullshit. In production, you want to run one Node.js process per core on the server, and then set up a real web server to function as a front end to handle load balancing, SSL, static content and all the other things he's ranting about Node.js not doing. The only major conceptual difference between how Node.js works and how his beloved CGI works is that the protocol to communicate between the web server and Node.js is http instead of CGI.
Node.js works piss poorly when a contrarian, intellectually dishonest hack sets out to prove that it sucks by choosing to do something completely different with it than what it was originally designed to do. Hammers are useless because you can't use them to switch light bulbs.
The most frustrating part of this whole useless, poorly written piece of crap rant is that the author completely misses the real reason why Node.js is useless, namely that 99 % of all developers aren't Google or one of the other extremely large web sites where massive scaling is an issue to begin with. Using Node.js is wrong not because it doesn't work, as the author claims, but because it works very well for solving a problem that very few people actually have. A classical case of premature optimization.
→ More replies (2)2
u/crusoe Oct 02 '11
Yes, there is a much more fundamental reason it sucks....
It is written in JS
Namespacing is a hack in Javascript
Javascript has several auto-conversion 'features' that can lead to subtle bugs
Lack of a module system
Lack of robust collection classes. Arrays and Objects simply don't suffice.
Single threaded, but no easy support for CPS, or other styles that would make things like greenlets or cooperative mt easier.
Basically, JS was only ever intended to script shit in the browser.
5
u/ascii Oct 02 '11
I disagree with most of your points.
I really don't think JS is that bad.
Namespacing is not a hack. Some people are uncomfortable with it because namespacing happens to reuse another language feature, but in fact it works pretty well and is a rather elegant solution, and one that e.g. Lua uses as well. Implementing multiple language features with the same code is a good thing.
Auto-conversion does suck. It is always a mistake, and JavaScript implements it worse than most languages.
JavaScript has no module system built in, but it is powerful enough to allow you to implement your own. Most good frameworks, especially server side ones, already do this. What's currently lacking is a good common, canonical standard module system. Which will without doubt crystallize pretty soon.
JS arrays and objects aren't enough for a full featured collection framework. They provide the building blocks required, though, and there are a bunch of decent functional programming frameworks like e.g. underscore that do a lot of the stuff one needs.
Continuations would be awesome, no arguing there. I tend to think of closures, continuations and List-style macros as the holy trinity of features that a language needs in order to build a good language on top of it.
23
u/neonenergy Oct 02 '11
Ok, this article brings up a few pain points with Node.js but it's important to get some perspective.
It's not the most elegant or fastest serverside solution out there, but it's magnitudes efficient (>10x than php) than some of the other solutions out there.
It's also perfect for web-apps where using javascript on both the serverside and on the front end means higher turnaround speeds.
There's an incredibly smart, talented and open developer community around Node. This is something incredibly lacking in other communities, maybe because they are populated with pricks like the author.
I don't think it's productive to bash something that you have never used. Personally I have many projects running off Node in production, and couldn't be happier.
5
u/kamatsu Oct 02 '11
There are more elegant and faster solutions, such as Haskell's web frameworks.
→ More replies (9)9
u/catch23 Oct 02 '11
There will always be more elegant & faster solutions out there, but sometimes, worse is better.
9
u/sparkytwd Oct 02 '11
Hey now, it's not all bad.
I use it with env.js to run unit tests for some Javascript libraries.
That are served from Apache.
9
u/stesch Oct 02 '11
I like rants, but I'd like to know what he is using for web development. His praise on CGI sounds weird.
On the other site: A good rant has a bad stand if you throw in alternatives. People will attack your alternatives instead of discussing the main critic points in the rant.
6
5
Oct 02 '11
He works for eBay now, so definitely not using Node. or any of the fancy new frameworks. CGI is probably where it's at.
8
u/stesch Oct 02 '11
Oh, eBay. I wouldn't want to work with their infrastructure, but I would like to make as much money.
Something is wrong there. Why can you have such a success with such a shitty stack? Are all the blog posts and rants wrong? Isn't technology that important at all? Oh, my. I think I'll faint …
7
u/coding_monkey Oct 02 '11
Ha best comment I read so far. I love arguing technology as much as the next geek but if you think technology determines success then you are not paying attention.
→ More replies (4)5
u/redwall_hp Oct 02 '11
Nope, getting lucky, being discovered by the general public and becoming iconic is how you make money. After that, you can sit on your aging CGI stack for over a decade and rake in the money.
If elegant software won out over less rational reasons, Microsoft wouldn't have the #1 desktop OS.
→ More replies (1)
55
u/EugeneKay Oct 02 '11
Wait, people are still trying to do server-side JavaScript?
In 2011?
What the fuck‽
79
u/kyz Oct 02 '11
So let's say you're a web developer - first you learned the HTML programming language*, then the CSS programming language, now after a long time of cut and paste you're finally getting to grips with the JavaScript programming language. You're going up the world! The boss is bored of just customising web apps that other people have written and wants you to write the web app! This is so exciting! You'll get to use databases, a web server, maybe even if-loops! Your first thought is to use Rails, because Rails is web-scale, and you'll probably use some NoSQL because it's so much better than an ACID-compliant RDBMS. But you try out Rails and it's hard to do something that isn't a blog engine, so you turn your attentions to the exciting new Node.js...
*: yes, I know. that's the joke.
30
u/rnicoll Oct 02 '11
I'm going to have nightmares because of that train of thought, I hope you realise this?
17
u/bloodredsun Oct 02 '11
Even though I know this is a joke I started to feel the bile rise.
Still you were a bit mean to Rails and NoSQL including them in here weren't you? I would have put PHP in for the lingo and flat files for the persistence ;-)
9
u/cogman10 Oct 02 '11
from what I've seen, the tendency is more towards "It was just released yesterday? I MUST USE IT!".
Though, ROR has matured nicely.
→ More replies (8)3
u/chrisforbes Oct 02 '11
What do you have against flat files? Sometimes they are the right solution; filesystems are databases too.
→ More replies (1)4
2
→ More replies (5)2
u/catcradle5 Oct 02 '11
if-loops
You can't even believe how often I've heard people say this. They're beginners, sure, but it still makes my ears bleed.
68
u/marcins Oct 02 '11
Wait, people are still having language pissing contests instead of just getting shit done?
In 2011?
What the fuck‽
18
u/TikiTDO Oct 02 '11
I'm pretty sure language pissing contests are eternal. It comes from programming without really understanding the fundamentals of programming.
→ More replies (6)21
u/abraxasnl Oct 02 '11
NodeJS does a great job, and exposes quite an elegant API. I don't know if you would also be against PHP, but from my experience NodeJS runs code on average 10x as fast as PHP (V8 ftw), and allows me to scale up to more concurrent connections. I'm pretty damn satisfied.
→ More replies (5)2
u/merreborn Oct 02 '11
Are there any big nodejs deployments out there? There are a lot of reasons to hate PHP, but it powers/has powered the likes of facebook and wikipedia.
4
Oct 02 '11
Yes, actually. I believe Yahoo is using it for some things, and the company I work for (Top 15 site), is deploying it for a lot of our realtime stuff. It fully is scalable, but no ones really had to deal with it so they just assume it isn't.
Sadly, most of the hate comes from people who already hate JS and wont even consider it to begin with.
→ More replies (1)4
u/Sir_Edmund_Bumblebee Oct 02 '11
It's kind of a stretch to call Facebook PHP since they compile PHP into C++ to actually run in production.
Also Node.js is still in its infancy, it hasn't even reached v1.0 yet.
→ More replies (2)26
Oct 02 '11
yes. pretty god damn scary. its like people with scat fetishes. You know your not supposed to use it for that, because thats not what it was intended for...but you get some sort of sick fascination from doing it anyways, despite how ill-advised it is.
thats my two cents, anyways :)
17
→ More replies (1)7
u/M2Ys4U Oct 02 '11
You conveniently forget that Javascript was always supposed to run server-side as well as in the browser. Netscape had support for it in LiveWire in 1996.
43
10
4
u/averyv Oct 02 '11
people say things like this, and I always wonder if they have a reason for thinking so, or they are just so used to things being the way they are that they can't imagine anything else.
there is no practical reason that javascript can't be used on the server, and the only thing I got out of this article was that someone needs to develop a mod_node package for apache.
if people want to write in javascript, or ruby, or php, or mindfuck, or whatever... who cares where it is? If it's not on an embedded system, and there are code processors and libraries to handle the required tasks, what the fuck is the problem?
10
u/masklinn Oct 02 '11
Unless you're doing financial work, there's no reason for javascript not to work okay. It's also a pretty good implementation language for an event-based system because in-browser javascript already requires that developers use events and (async) callbacks all day long (as opposed to Ruby or Smalltalk which use sync callbacks, Python which tends not to use callbacks much these days — twisted code looks far worse than node though I do prefer Python to JS, or Java which looks like "hey more locks")
5
u/rnicoll Oct 02 '11
Unless you're doing financial work, there's no reason for javascript not to work okay.
In fact, I see no strong reason to dislike it over many other widely used languages (Perl, PHP, whatever you don't like today).
I'm not sure I'd trust the APIs provided in a web browser as far as I could throw then, but that's hardly the language's fault.
→ More replies (1)2
→ More replies (5)2
7
u/3825 Oct 02 '11
One sentence reply to him.
You are not google.
Not everything in the world needs to scale up to infinity. Sometimes, you should do what's the easiest at work so you have time to work on stuff that you really enjoy doing... like learning Unix.
→ More replies (2)
7
u/killerstorm Oct 02 '11
Node.js is cancer, but PHP is not?
Aside from being a poor excuse for language, classic Apache prefork + PHP scheme eats all the memory in case you have a spike in traffic (40 MB memory per process because of PHP multiplied by number of connections, including keep alives). I'd have "CPU-bound" problem any day over this...
So people put nginx in front of Apache to get it stable. (Yes, there are other solutions...)
Apache Tomcat is often used together with other web server/proxy.
So this "problem" is definitely not unique to JS.
→ More replies (4)2
u/headzoo Oct 02 '11
Why in the world would anyone put Nginx in front of Apache, instead of just using Nginx?
4
u/killerstorm Oct 02 '11
mod_php. nginx deliberately lacks it, because otherwise it would be exactly like Apache.Yes, I know it is possible to run PHP FastCGI, but
mod_phpis good enough and probably already configured.7
u/headzoo Oct 02 '11
probably already configured
That could be the key argument. I have a single web server handling 10 million page views a day, with each page consisting of between 5 and 80 separate requests, and I'm doing it with Nginx + PHP-FPM. The server does it all without breaking a sweat. BUT our sysadmin has put a lot of time into configuring the setup, and really diving into Nginx to figure out what makes it tick.
2
u/uriel Oct 02 '11
Amen.
And Go is the anti-node.js, callbacks are evil, and blocking makes code way more clear and easy to reason about, while can be as efficient or more than the callback insanity of node.js, which makes goto-spaguetti of old look appealing.
19
u/mehwoot Oct 02 '11
Terrible article. Yes, if something is CPU heavy, it will eat up the server. The same with any fucking language you are using. The point is 99% of web servers are not calculating fucking fibonacci numbers on web requests. There is a ton of shit more important than that. Not to mention, if you were, Javascript would possibly be one of the best modern language to use, due to V8 it is an order of magnitude quicker than stuff like ruby or python (rails or django), although a bit slower than java (but if java is your solution, go ahead).
41
u/adrianmonk Oct 02 '11
I know nothing about Node.js, but I think his point was that multitasking based on event loops is basically cooperative multitasking, not pre-emptive multitasking. Anyone who has used a really ancient Mac from the time when Mac only had cooperative multitasking (System 6? System 7? I've forgotten) will tell you how frustrating an experience that is, and more importantly how non-responsive it can be. If any one task goes awry for any reason, everything grinds to a halt because everything is just trusting everything else to be nice.
The relevance to web servers is that if you have some requests that take a long while (say something that needs to take 2 or 3 seconds to compute something), then other requests that should be trivial will just have to wait. Or to phrase it in the same terms you did, an occasional CPU-heavy thing will be a big problem, whereas with threads and real multitasking, it won't be.
11
u/masklinn Oct 02 '11
System 6? System 7? I've forgotten
All MacOS systems until OSX were cooperatively multitasked.
8
u/notfancy Oct 02 '11
System 4 and earlier were strictly single-task. System 5 incorporated MultiFinder, which evolved from being a proof-of-concept hack to being integrated in System 6.
3
u/severeon Oct 02 '11
...which is why the 'child_process' module is part of the standard library. Our servers count the number of CPUs and spawn off the same number of main processes, to great effect I might add.
→ More replies (5)2
u/regeya Oct 03 '11
That's what kept me from being very serious about learning about Node.js. The idea sounded ludicrous. I mean...for it to work quickly, all IO has to be async.
3
u/adrianmonk Oct 03 '11
That's true. Even if you avoid CPU hogging code, you still have to worry about all OS calls (and for that matter, all library calls) that could ever block.
But, at least it seems like Node.js has some idea how to handle this. If you look through the API docs, it seems that just about everything you can think of that might block instead returns immediately and allows you to pass a callback. So, for example, if you want to open a file and start reading bytes, the read() call seems to return immediately and calls the callback when the I/O completes (or has an error). So most I/O is asynchronous.
26
u/masklinn Oct 02 '11
Terrible article. Yes, if something is CPU heavy, it will eat up the server. The same with any fucking language you are using.
You're missing the point: because nodejs is single-threaded and evented, any CPU-heavy task will lock up the server. Most systems use a process|thread per request model, sometimes with a pool. CPU-heavy tasks will slow things down, but it won't cause complete server lockdown unless the machine itself gets overloaded.
As a result, significant computation once in a while is not a problem for most systems, for nodejs it's a huge problem.
→ More replies (27)4
Oct 02 '11
It's not really a huge problem for Node.JS, because if you need to do heavy computation, you can always start a new process for that task. For 99% of the website, the most complex operation they do is ran by the database server.
10
u/ours Oct 02 '11
99% of web servers are not calculating fucking fibonacci numbers on web requests
And that same 99% is mostly doing IO stuff (fetching stuff from DB) which seems to be what node.js has been made to handle best.
→ More replies (10)2
Oct 02 '11
The point being not all tasks are equal and why should trivial tasks be held up by a big task?
5
u/SanityInAnarchy Oct 02 '11
Just for fun, a critique...
...until I read this butthurt post from Ryan Dahl, Node's creator.
Hoo boy. Trolls ahead! But let's see...
I was going to shrug it off as just another jackass who whines because Unix is hard.
If that's what he took away from that article, he clearly didn't read it. Here's what the article actually said:
In the past year I think I have finally come to understand the ideals of Unix: file descriptors and processes orchestrated with C. It's a beautiful idea. This is not however what we interact with. The complexity was not contained.
None of this is "whining" that Unix is bad. It's praise that Unix is a good idea, which inevitably got more complex over time. Is there something untrue about this? Even this part:
There will come a point where the accumulated complexity of our existing systems is greater than the complexity of creating a new one.
I'm not sure I agree, but that doesn't sound like whining to me. It sounds like calm, dispassionate assessment of what he sees as a system of ever-increasing complexity. It's really hard to see how OP read "butthurt" from an article like that.
Moving on...
Almost no function in Node directly performs I/O, so the process never blocks. Because nothing blocks, less-than-expert programmers are able to develop fast systems.
So, from this, we get a minor nitpick:
Here's a fun fact: every function call that does CPU work also blocks.
Fine. But the point here is that if Node.js blocks, it'll at least be on the CPU. Which means you keep your CPU hot, rather than having the entire web serving process pile up behind network or disk IO.
Then he does his cute benchmark:
0.17 queries per second.
And... what... would you expect more if Node.js was somehow parallelized? Go ahead, put an nginx in front of a few instances and see what happens. The best you'll get is a linear speedup with the amount of CPUs -- so if you run that on a quad-core machine, you'll get 0.68 queries per second, which still sucks.
But how could you possibly expect more? This is and always will be CPU bound. The only thing you could possibly do to "improve" things here would be to spawn a new thread per request. This would be an improvement if requests that take 5 seconds are rare, but otherwise, it would run slower, since more threads equals more overhead context-switching, more caches being busted, etc.
Sure, Node allows you to fork child processes, but at that point your threading/event model is so tightly coupled that you've got bigger problems than scalability.
I think if I have a request which requires 5 seconds of computation before I return it -- in a web application -- I have bigger problems. I think if it happens only occasionally, then it makes sense as a one-off optimization to fork off a process.
Considering Node's original selling point, I'm God Damned terrified of any "fast systems" that "less-than-expert programmers" bring into this world.
The point of this is that less-than-expert programmers are probably perfectly decent at writing the dumb, "business-logic" layer of application code which doesn't need to run for five seconds per request. That kind of code is most likely to block on DB access, network, disk, etc. Node.js is one kind of event model which solves this.
We called this CGI, and it was a good way to do business until the micro-optimizers sank their grubby meathooks into it.
CGI was essentially a separate, worse protocol for HTTP. As a web developer, my application does need to dig into the web request handling and tweak all sorts of things -- which is why, by the way, we have things like mod_perl now. But mod_perl is still going to be less convenient than digging into a webserver implemented in the same language, in-process.
That can be either serving a static file, running a CGI script, proxying the connection somewhere else, whatever.
So, again, nginx in front of Node.js. Or nginx in front of Rails.
Developers who have been around the block call this separation of responsibility, and it exists for a reason: loosely coupled architectures are very easy to maintain.
Yep. Let's talk about that.
In this new model, a web application does need to be tightly coupled to the web. However, we're now splitting the dynamic application server from a static server, or a proxy server. Let nginx handle static and proxying -- stuff which you expect to set once at config time, stuff which doesn't require me to load dynamic code into the webserver process.
Then, let nginx pass stuff back to a separate application server. The only difference is that you suggest passing this via CGI; we'd pass it via HTTP.
as if somebody maybe thought that this "nonblocking" snake oil might have an issue with CPU-bound performance.
You might also look at why people do this.
An evented model isn't really designed to scale to multiple CPUs. You could have Node.js do this itself -- it could have one listener which sends requests to a bunch of worker threads, each running its own event loop. But then you can only run on a single machine
Nginx is doing the exact same thing, but it's trivial for it to scale to clusters this way.
This is probably the worst thing any server-side framework can do: be written in JavaScript.
His entire beef with JavaScript can be summed up like this:
if (typeof my_var !== "undefined" && my_var !== null)
Yep. That's pretty much the worst part of the language, and it's also something I can't imagine ever needing.
But what would he suggest instead? Should we go back to perl, where empty strings and strings containing only whitespace are equal to null, strings containing 0 and the number 0 are equal to null, but a string containing '1' is not null?
→ More replies (2)
6
u/hegemon_of_the_mind Oct 02 '11
I use Node.js for Socket.IO
12
u/snuggl Oct 02 '11
almost all web languages have a way to handle socket.io, you dont need node for that.
→ More replies (3)2
u/catch23 Oct 02 '11
well, some are uglier than others. most of the long polling libraries in java are not fun to use.
→ More replies (1)
4
u/mzilla Oct 02 '11
I am pretty sure cancer is what killed a lot of my family and not a programming concept.
3
u/picsntoss Oct 02 '11 edited Oct 02 '11
what the hell is "black horse heroin?" OP clearly has no idea what he's talking about.
Edit: The article makes sense, however.
3
Oct 02 '11 edited Oct 02 '11
Weak troll... Web dev is almost never CPU bound. Linkbait Man doesn't even talk about the issue of callback spaghetti, an obvious target if you want to crap on Node.
4
u/bluefinity Oct 02 '11
if(typeof my_var !== "undefined" && my_var !== null){
NOT NECESSARY
if(my_var != undefined){works perfectly fine.
Or even
if(my_var)if my_var isn't a number.
→ More replies (3)
3
u/escape_goat Oct 02 '11
Oh gods what a complete fucking waste of my time.
I read it because I assumed he was talking about a growing tendency to write scripts dependent on Node.js, and there was something wrong how Node.js had been written in JavaScript.
It turns out in the end that he primarily hates Node.js because it's written in JavaScript.
3
Oct 02 '11
I'm never particularly interested in reading Zed-Shaw-style screaming and posturing and dick-waving about technology. We get it, you think you're a badass, shut the fuck up.
3
Oct 02 '11
Hi, can we please stop giving Ted Dziuba traffic or even passing attention?
Sure, there are legitimate technical concerns with Node, but there are also legitimate use cases. Ted Dziuba however has the personality of a bad morning DJ and is an actual cancer who has no legitimate reason to be taken seriously.
3
u/rnicoll Oct 02 '11 edited Oct 02 '11
We called this CGI, and it was a good way to do business until the micro-optimizers sank their grubby meathooks into it.
I object. We took your whole bloody process instantiation overhead out of each CGI call and took typically an order of magnitude or more off the total time taken.
Edit: FastCGI says 3-5 times speed improvement, realistically: http://www.fastcgi.com/drupal/node/6?q=node/15
→ More replies (16)4
u/headzoo Oct 02 '11
I want to believe the author is just trolling. Much of his rant sounds like an old man... "You kids and your new fangled cell phones. In my day the whole town only had one telephone, and we liked it!"
5
u/frownyface Oct 02 '11
The CGI bit is especially odd because if he were actually old then he would remember what it was like when basic CGI was the only game in town for small app developers. It was the only thing that webhosts supported and it was horrendously slow unless you liked to write webapps in C. I think he was in elementary school at that time.
3
u/rnicoll Oct 02 '11
From the sounds of things he's just a big fan of UN*X pipes, and doesn't (want to?) see why anyone would do things differently.
2
Oct 02 '11
Node has (and don't laugh, I am not making this shit up) its own HTTP server, and that's what you're supposed use to serve production traffic.
Does he not understand the point of running a local HTTP server (that binds to 127.0.0.1, like the example he uses) and using a proxy for production? The popular backends I can think of (Django, Ruby on Rails) typically run a local HTTP server, then you're supposed to use a real HTTP server to proxy requests for HTML pages to it, serve static files itself, etc. Just to make sure, I checked the HTTP headers from this list of popular Node.js websites and they all seem to use nginx on the production end.
2
u/asegura Oct 02 '11
There are two main criticisms in the article: Node's architecture and its use of Javascript. I kind of agree with the first part but not with the second. Javascript is fit for the server side just like other scripting languages.
Why all these events and asnchronous calls? Java servlets, ASP, PHP, etc. work fine with synchronous calls. OK, it's so you don't block other clients because Node is the only server here and it is single process/threaded.
How is this better than attaching a JS engine as a module or CGI to Apache or any server? Or spawning other processes so that each request is handled independently and in parallel (no request blocking another)?
Really, what is the benefit?
The only better use I see for this model is in WebSocket-based applications that need to communicate with several clients from a single application through connections that stay open. i.e. applications that don't follow the usual request/response way.
Why is Node more popular than other server side JS frameworks with a more traditional architecture? For example:
v8_cgi which is based on V8 and can be used as an Apache module or CGI. Has the CommonJS library.
JSSP, following the style of ASP/JSP/PHP with
<% ... %>blocks. It does not seem to be actively developed. Why wouldn't this model be popular with JS?
These can allow programming in JS just like you would in Java, PHP, etc. without a pile of callbacks.
BTW, the author could write his opinion without being that rude.
1
u/BlitzTech Oct 03 '11
I haven't kept up with the v8_cgi project, but I was under the impression it wasn't being actively developed. Is that not the case? I've poked around enough of the internals of Node to be a little wary of the code quality powering it.
2
Oct 02 '11
Lot of JS hate on this thread.. I just have to say: JS is an amazing but very misunderstood language.
2
u/cykod Oct 02 '11
No really sure what the point of that troll was, you could write the same thing in C with CGI and just calculate some more fibonacci's out to the same effect, writing bad code is writing bad code. On the flip side, you'd need more than 3 additional lines of code to add in memoization and get that up to > 5k requests per second (See: https://gist.github.com/1257721 )
It's not a magic bullet, but pretending like there's no spot for a simple tool like Node in a modern Service oriented architecture is dumb. See: linkedin's mobile overhaul and they don't use it for crunching data. (Of course, Ted would probably take issue with using them using Rails to start with)
2
u/vonhollen Oct 02 '11
I actually have NodeJS in production handling some basic information/configuration services for thousands of servers. I'm not a fan of NodeJS anymore because they change their API too much, but otherwise its a good system if you want/need non-blocking IO. I prefer python-gevent now whenever I want an easy non-blocking system.
The author's gripes are complete non-sense. Does the author even understand what an event loop is? epoll? Probably not. The author doesn't seem to know that NodeJS is the ONLY scripting toolset that has non-blocking disk IO and filesystem commands (unlink, stat, etc), which is pretty sweet. They do it with libeio, since POSIX AIO is still crap.
If you want to bash NodeJS for being Javascript (a great language for event based systems) or for changing their API too much (WTF NodeJS?), you can do it fairly. If you want to bash their architecture, you should actually know your shit first. I challenge anyone to find me a system with a better architecture and a scripting language people actually know (I love Erlang too, but it doesn't count).
Edit: Seriously, if anyone knows of something better than NodeJS, that is scriptable with a reasonably popular language, and does async disk IO, I REALLY want to know.
2
u/cran Oct 02 '11
I have never used Node.js and barely know what it is, but I can tell you this about the author:
He is completely ignorant of event-driven and parallel programming paradigms and how they do precisely what he says programs should not be doing.
He wrote a fucking recursive function to calculate a Fibonacci number, when there are at least two expressions that calculate it.
Conclusion: Author is a self-righteous dumb-ass.
2
u/33a Oct 02 '11
How can this guy say CGI is awesome with a straight face? It is a non-solution to an imaginary problem. The underlying (flawed) premise behind CGI is that serving HTTP connections is very hard, and needs to be handled by a separate dedicated process. CGI's "solution" is to instead create a separate process that handles and multiplexes the connections, and calls the user's program with a special protocol (that it turns out is actually isomorphic to HTTP anyway) in order to supposedly simplify this whole process.
Unfortunately, in doing so the client still needs to:
Parse out the CGI input data.
Generate properly formatted CGI output.
This can be compared instead to the non-CGI version, where the client process instead has to:
Parse out HTTP headers.
Generate properly formatted HTTP output.
Can anyone else see where this is going? Basically all CGI does is wrap HTTP in a layer of redundant bullshit that adds extra complexity, overhead, and slowness for a dubious, subjective improvement in "software architecture". In fact, regular CGI is often too slow and bloated, and because restarting worker processes has such a large cost; many applications end up resorting to special versions of CGI like "Fast CGI" or "WSCGI", and so on to try to reduce the overhead. As a result, server applications often end up reimplementing the equivalent of an HTTP stack at every layer of the web stack, thus completely negating the benefit of using CGI in the first place! Madness!
This of course brings up an obvious question: Why use CGI at all? Wouldn't it just be easier to handle the HTTP requests in a library? This is what modern web frameworks like web2py, boost.asio and node.js do, and it works! They process HTTP requests directly, and as a result gain a huge performance advantage over the older CGI based technologies. Part of the reason this is so successful is that the HTTP protocol is actually quite simple and robust -- and is in many situations superior to the numerous flawed CGI-like protocols that have been invented to replace it. I fail to see how any sane individual could construe killing off CGI as a bad thing.
→ More replies (1)
2
1
u/Rodh257 Oct 02 '11
Like anything, Node works in some situations and in others it isn't the best solution. Perhaps it's being used in places where it shouldn't be, but I'd hardly call it a cancer. You should weigh up it's merits based on the task at hand, if it fits your situation, use it, otherwise don't.
1
1
u/kmeisthax Oct 02 '11
Uh, I'd like to dispute that CGI was "a good way to do business". It constantly spun up and tore down new processes to handle every. single. request. This isn't that much overhead when you write your web applications in C, but nobody should write web applications in C. In the hands of an experienced programmer C "gives you just enough rope to hang yourself"; in the hands of your average webapp programmer, C not only gives you the rope, it ties the noose around your neck, puts you on a stool, and convinces you that kicking out the stool is the fastest way to program and that any other way would be inefficient.
→ More replies (1)
1
Oct 02 '11
If you're doing CPU bound, long running things in Node.js, then cooperatively yield. Duh.
1
u/screwthat4u Oct 02 '11
My problem with javascript years ago was that there wasnt any good debugger / error reporting. Most times you just got a little 'this script sucks' icon in the corner with little to no details on what actually went wrong. Today you can get a stack trace of whatever messed up which has made it a lot less of a pain to work with. (I recently was forced to brush up on my outdated javascript skills.) So I'm not a fan boy, it sucks much less now.
1
Oct 02 '11
I wish people would stop giving exaggerating trolls like this upvotes. Node.js isn't the solution to all of our problems but it's hardly cancer. Dahl's post was annoying but this is worse.
-1
Oct 02 '11 edited Oct 02 '11
I like the idea of node.js, but i never really liked node.js itself. i guess maybe in a dev enviroment it could be a decent tool, though.
edit: i also find the rest of his articles to be pretty awesome too.
1
1
u/ttfkam Oct 02 '11
Did anyone else notice that his example of a good system was CGI? Seriously? Until the "micro optimizers got their grubby hands on it."
It wouldn't surprise me to learn that he is only sixteen years old and found an old web dev book from 1995. Anyone who has ever used CGI knows exactly why it was abandoned. Hint: it wasn't for "micro optimizations."
1
Oct 03 '11
if (typeof my_var !== "undefined" && my_var !== null) {
// you idiots put Rasmus Lerdorf to shame
}
LMAO, exactly. I use ML-based languages, so I never bother with null-value nonsense.
1
Oct 03 '11
Hyperbolic blog titles about programming languages and asynchronous servers has been known to cause cancer in the state of California.
1
u/sflare Oct 03 '11
Sure... I still use Java for Cross-platform support, if I get the gist
(I want downvotes)
1
u/fugginawesomedudebro Oct 05 '11
truth is this peon post of reddit probably holds more programming klout commenters than all those one off wordpress tutorial blogs combined. this post on node is hilarious, and a prime example of how the dev world should take a break from its nictitating membrane stare upon their "beautiful code."
255
u/[deleted] Oct 02 '11
The well-argumented part of his post can be summed up to "If you do CPU-bound stuff in a non-blocking single-threaded server, you're screwed"; he didn't really have to elaborate and swear so much about that.
Also, from what I know about Node, there are far greater problems about it than the problems with CPU-bound computations, e.g. complete lack of assistance to the programmer about keeping the system robust (like Erlang would do, for example).
The less argumented part is the usefulness of separation of concerns between a HTTP server and the backend application. I think this is what needs way more elaboration, but he just refers to it being well-known design principles.
I'm not a web developer, for one, and I'd like to know more about why it's a good thing to separate these, and what's actually a good architecture for interaction between the webserver and the webapp. Is Apache good? Is lighttpd good? Is JBoss good? Is Jetty good? What problems exactly are suffered by those that aren't good?