博客文章
A comparison between Misultin, Mochiweb, Cowboy, NodeJS and Tornadoweb
http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/
发表时间May 2011
恰如其名,这篇文章比较了 Misultin, Mochiweb, Cowboy, NodeJS and Tornadoweb,看比较图吧,评论也精彩:
In the webpage that will be displayed when you go to http://localhost:3000, you can set a number of messages to be sent to the server via socket.io.In my computer nodejs processes 10k messages in 1250ms, and erlang version does the same in 1050ms.
With 100k messages, erlang handles them in 70secs, and node drops the connection thus failing the test.
We know that benchmarks aren't really that useful, since they differ from real production code. But this one served me to decide to go with erlang instead of node for a game I will be developing. Not being able to handle 100k messages is a no-no, given that erlang is able to handle them without problem.
Node and Erlang both set out to solve an issue that developers of a particular class of systems routinely face: dealing with massive concurrency.
In the end, Node and Erlang find their way to almost the same place. They are both dynamic languages, with similar native datastructures, and one can see that Node’s ubiquitous EventEmitter is, in many ways, isomorphic to Erlang’s message passing scheme. Libraries like hook.ioprovide some semblance of the agnosticism with which one treats the location of an adressee in Erlang. Hotplugging of code is possible with no particular hassle, but—arguably as it should be—the responsibility of the programmer to do in such a way as to not break the application. They both are ideall suited to workloads that are primarily bottlenecked on IO, and both excel at shifting data from one place to another.
My main goal was to set out and exemplify a major difference in how a system like Node.js handles requests compared to Erlang. I think I have succeeded. It underpins the idea that you need to solve problems depending on platform. In Node.js, you will need to break up long-running jobs manually to give others a chance at the CPU (this is essentially cooperative multitasking). In Erlang, this is not a problem — and a single bad process can’t hose the system as a whole. On the other hand, I am sure there are problems for which Node.js shines and it will have to be worked around in Erlang.
Erlang vs node.js
Posted by David N. Welton on Thursday, April 29, 2010
http://journal.dedasys.com/2010/04/29/erlang-vs-node-js
"Good enough" concurrency, combined with a language that is at least an order of magnitude more popular than Erlang, and a fast runtime, combined with ease of use in general (it's way easier to get started with node.js than with most Erlang web stuff) make for a system that's likely to do fairly well in terms of diffusion and popularity, and is going to "eat some of Erlang's lunch". Or perhaps, rather than actually taking users away from Erlang, it's likely to attract people that might have otherwise gone to Erlang.
Felix's Node.js Convincing the boss guide
http://nodeguide.com/convincing_the_boss.html
Felix Geisendörfer, an early node.js core contributor and co-founder of transloadit.com.
But please be careful here, since JavaScript is a dynamic / garbage collected language, your response times may sometimes vary depending on how often and long the garbage collection kicks in (at which point your program is stopped). So don't try to build hard realtime systems in node, that require consistent response times. Erlang is probably a better choice for these kinds of applications.
问答站
图1: JavaScript的需求远远超出其他的语言。PHP和Python的增长很稳健。Groovy虽然在增长，但是总量还是太小了。Erlang呢，几乎可以忽略。
图2: 从短期18个月看，基本上没有太大增长，期间有些波动。基本上过去一年都没有什么增长，不知是否和整体的经济有关。
图3: 各个语言的增量对比,从增量上看，Erlang和Groovy虽然总量很小，但是增长的比例很高。而JS和PHP的需求已经非常大，增长100%就是很大的数字。这也是可以理解的。
