I'll definitely admit that many of the inventive techniques that node.js users have come up with make dealing with callbacks less absurd, but the problem is that it's just polishing shit. It's extra hoops to jump through with no benefit, outside of the C10K fapfest.
Would all the developers writing apps on node.js who are doing 10,000+ concurrent requests per process please stand up?
Only the minority gives a shit how many Hello World requests your stack can pump out. Some of us use node.js because it's a) got some decent libraries, b) makes realtime easy, c) uses the same code server+client-side reducing context-switches, and d) gets quite enjoyable once you know what you're doing.
You obviously haven't written a lot of async code so not sure why you're so against the idea.
So again, to you, what benefit does everything being built on this async, single-threaded, event-driven model give you? Sounds like not much. You could get all of those benefits + much cleaner code using threading or fibers or actors, but that does not make for C10K badassness, so here we are, with our callbacks.
Also, I'd say I've written enough code on top of node.js to be qualified to comment on this. Here's some of it that's open source:
I get simple scalability, server-client code reuse, easy realtime, and, despite what you or others may think, I like Javascript as a language. Node.JS was also a perfect fit for the scraping framework I wrote: https://github.com/chriso/node.io
IMO async code isn't as difficult or ugly as you make it out to be. Is async code as easy to write and follow as sync code? No. Is it worth the benefits I've mentioned? For me, yes.
> Is it worth the benefits I've mentioned? For me, yes.
This sounds like a tacit admittance that you're willing to deal with it because you don't think you have other options, but you do. There is at least one CPS compiler for Node (TameJS), and there are other languages that allow for the same result, but more straightforward implementations of concurrent code (Erlang, Ocaml/LWT, Haskell). I'm not saying you should use though, but we can do better and we should, even if it's just compiling back to JS in the end.
If I can run one app with 10,000+ concurrent requests on one server, then I can run a hundred apps with a hundred concurrent requests each on that same server. You can say that doesn't matter either, but the cost of hosting a web app just dropped 99%.
And now the cost of hosting a hundred webapps is just a rounding error in contrast to the cost of developing one. Isn't it nice living in the future?
The additional benefit is that I can take the same program and handle 20,000+ concurrent users on two servers— which is when I suddenly become very glad that my hardware costs are significant compared to my dev costs.
And now the cost of hosting a hundred webapps is just a rounding error in contrast to the cost of developing one.
That's a weird way to look at it, unless you're in the webapp hosting business? For everyone else there is usually only one webapp that they care about.
I can take the same program and handle 20,000+ concurrent users on two servers
Sorry to break it, but that's not how it works. Unless you have one of those rare webapps that never need to touch a database.
Really? Show of hands, now, who here cares about one (and only one) webapp?
Anyway, what's good for the webapp hosting business is good for web developers, and what's good for web developers is good for the technical ecosystem in general (and then the world). Of course going from VPSes to EC2s was a significant improvement. But that isn't as good as it gets. EC2 rates were cheap already, but when Az started the free tier it represented a significantly lower barrier to entry. That's good for everyone.
And seriously, come on. This is a way of making programs run faster, and not a little faster, but a hundred times faster. It's the very definition of technological progress. It's absurd that we're here arguing about whether it matters or not.
This is a way of making programs run faster, and not a little faster, but a hundred times faster.
Sorry, but if anything then that statement is absurd.
Faster than what? And where's that "hundred times faster" figure coming from?
It seems there's a bit of a misconception about the bottlenecks and cost structure in real world web applications.
Rails (aka the slowest web framework known to man) is popular because it trades hardware for development velocity. Hardware is cheap, developer salaries are not.
It's cheap until it's not. At a certain point, you just can't process more requests at once in Rails. That's your limit. And it's not much— 100, maybe.
But node multiplies that, a lot. Which is nice, because you know it won't break or slow down if a bunch of people use it for some reason. And so you don't have to re-architect your system for a while longer, which is valuable time.
Yes. Rails is measured in hundreds per second. Node in thousands per second.
The point that you still seem to be missing is that the monetary amounts involved have normally turned into a rounding error long before you reach a traffic-volume where this difference becomes relevant.
Or, in other words, hosting a "webapp" already is nearly free in terms of hardware.
I have an server monitoring application that does this, currently I've tested on a vm with 4000+ clients with 1 server (all on the same vm), without any errors (CPU load spikes, but memory usage was actually low, I believe ~200MB for the entire test).
4000+ requests being sent every second to the server in total, the server is a single node process.
There are plenty of async idioms that make callbacks a breeze.