A recent article in nytimes discussed research that estimates the cost of some government regulations on businesses. It's done by first noticing that company size follows a power-law distribution and then measuring deviations. I wonder if you were able to get enough data on investment returns if you would find any interesting deviations?
Kudos should go to Bert Belder and Ben Noordhuis of Cloud9 who built much of libuv and Igor Zinkovsky of Microsoft has contributed a lot of important work as well. As well many other contributors.
Yep, serialized message passing between threads is slower - you didn't have to go through all that work. But it doesn't matter because that's not the bottleneck for real websites.
Also Node starts up in 35ms and doesn't require all those parentheses - both of which are waaaay more important.
Node is popular because it allows normal people to do high concurrency servers. It's not the fastest or leanest or even very well put together - but it makes good trade offs in terms of cognitive overhead, simplicity of implementation, and performance.
I have a lot of problems with Node myself - but the single event loop per process is not one of them. I think that is a good programming model for app developers. I love Go so much (SO MUCH), but I cannot get past the fact that goroutines share memory or that it's statically typed. I love Erlang but I cannot get the past the syntax. I do not like the JVM because it takes too long to startup and has a bad history of XML files and IDE integration - which give me a bad vibe. Maybe you don't care about Erlang's syntax or static typing but this is probably because you're looking at it from the perspective of an engineer trying to find a good way to implement your website today. This is the source of our misunderstanding - I am not an app programmer arguing what the best platform to use for my website--I'm a systems person attempting to make programming better. Syntax and overall vibe are important to me. I want programming computers to be like coloring with crayons and playing with duplo blocks. If my job was keeping Twitter up, of course I'd using a robust technology like the JVM.
Node's problem is that some of its users want to use it for everything? So what? I have no interest in educating people to be well-rounded pragmatic server engineers, that's Tim O'Reilly's job (or maybe it's your job?). I just want to make computers suck less. Node has a large number of newbie programmers. I'm proud of that; I want to make things that lots of people use.
The future of server programming does not have parallel access to shared memory. I am not concerned about serialization overhead for message passing between threads because I do not think it's the bottleneck for real programs.
Node follows a even/odd version scheme where even releases are stable and odd releases are unstable. v0.9.0 is just the first release of the unstable v0.9 series.
The versioning scheme is unfortunate because it confuses people. After Node 1.0 we'll switch a less confusing version system.
You're speaking of HTTP: the protocol on which a great deal of world's computing infrastructure is being set on top of. The protocol which we are communicating with each other over right now. HTTP on TCP is extremely successful and achieves all it was designed to for and has been extensible to handle much more. There are many basic problems which are abstracted well into stateless request response cycles: file serving, RPC. There was no "mistake" - it was not a bad fit. There are only expanding use-cases involving existing software infrastructure - for which websockets is solution. That's not to say that HTTP is perfect... It could be better in many ways - but it's ridiculous to write off its success and call it a mistake.
You should read my reply again (or maybe for the first time) and comprehend. I did not say nor imply that I think Erlang's processes are OS processes. Sorry for not using quotes ('process') if that's what has confused you so deeply.
Something that's different, at least from POE, EventMachine, Twisted is that it is attempting non-blocking purity. You can snub your nose at this but it turns out to be very important. It ends up abstracting away a problem in a way that EventMachine or Twisted will never be able to do simply because of the existence of massive amounts of blocking Ruby and Python libraries. The programmer simply doesn't have to know what non-blocking I/O is - they don't have to know that if they do "node script.js < hugefile" - that STDIN_FILENO cannot be selected on.
Erlang is different. Node presents a different programming model than Erlang - Node handles thousands of connections per process - and keeps itself close to the metal. Erlang is it's own operating system handling one connection per processes but allowing very many processes. Is Node's model better? Well at the moment it's incomparable since Erlang is very much a solid, production ready system and Node is not more than some dude's hack. But supposing that Node becomes stable and usable at some point, a major advantage of the Node model is that for the first 10,000-1,000,000 concurrent connections the programmer doesn't have to know anything about concurrency - a single process will just handle it. There is no forking or IPC - it's just synchronous events and callbacks. In Erlang you have to think about about IPC on the first connection. The Erlang-model might turn out to be the wrong level of process granularity. Maybe the right level of process granularity is how computers are already designed: 10,000-1,000,000 connections per process, use one per core.
I also wish for less hype around the Node project but I think you're short changing it by saying it's same thing as Twisted but in Javascript instead of Python. The main selling point is not that you can run the same code on browser and server. The main selling point is that you don't have to know what you're doing, at least for the first 10,000 concurrent connections.
i'm always surprised to hear things like this. it's certainly not unfounded - it's just so obvious and universally accepted that it doesn't require explanation - one would think.
That has to do a lot with Ruby's awful thread implementation. You could possibly port the app again to Ruby EventMachine and see even better performance.
The point is - for 99% of people it's not the language, it's the I/O
http://economix.blogs.nytimes.com/2013/01/02/why-49-is-a-mag...