p*****2
发帖数: 21240 | 1 http://queue.acm.org/detail.cfm?id=2567673
信息量太大了。
We did some prototyping with Ruby and Python using the evented frameworks
EventMachine and Twisted. The bottom line was that Node proved to be 2-5
times faster than both of those in terms of raw throughput. What was even
more exciting and really sold us on Node was that it took only two or three
hours to write the Node prototype while it took us more on the order of a
day or two to write the EventMachine and Twisted ones, just because we had
to download so much more stuff.
For example, you need to make sure you're not using the standard HTTP
library in Python, but instead the Async HTTP library. That's the sort of
thing that pretty much applied across the board. No matter what we wanted to
do, we couldn't use the standard Python library. Instead, we had to use the
special Twisted version. The same held true with Ruby. Like a lot of others
in the community, we found out just how much easier it is to get started
with Node, where everything you need is essentially there by default.
Further, the fact that we could get stuff up so much faster with Node was
really important. That's just another form of performance, right? Developer
productivity definitely counts for something.
Memory footprint was also a factor. We looked at how well VMs (virtual
machines) worked in each of these languages, and the V8 JavaScript Engine
just blew everything else away. We were doing 50,000 QPS with all this
manipulation, and we were running that in about 20 to 25 MB of memory. In
EventMachine and Twisted, just loading all of the classes necessary to do
the async stuff rather than the standard stuff was more like 60 to 80 MB.
Just at a raw level, Node was going to run in only about half the memory
footprint. |
a***n
发帖数: 538 | 2 这个不公平，v8有jit。用pypy加tornado也可以快很多。twisted又慢又难写。 |
p*****2
发帖数: 21240 | 3 The light and thin nature of Node.js appealed to Prasad and his team more
than anything else. The extent of code reduction this allowed proved to be
huge—from 60,000 lines down to just a couple of thousand.
Our Node code base has grown a little from the original version, but it's
still on the order of 1,000 to 2,000 lines of code. The Ruby code base we
were using previously, in contrast, was in the neighborhood of 60,000 lines
of code. The biggest reason for that reduction is that our current code base
is essentially framework-free, which means there's just not a whole lot of
cruft in there.
The second big reason has to do with the more functional approach we're
taking now, as opposed to an object-oriented one, which proved to be an
important shift for us. In Ruby, the natural tendency is to create an object
that essentially wraps every communication and type. Even though Ruby is
actually a functional language, it has a much stronger notion of class and
object than does JavaScript. So in our earlier code base we had lots of
layers of abstraction and objects that had been created under the guise of
greater componentization, refactorability, and reusability. In retrospect,
however, we really didn't need most of that. |
d********g
发帖数: 10550 | 4 Node的async优势在于原生。从技术来说LinkedIn这个写Python的并不是很全面，
Python做async用Twisted是需要注意如果夹了标准blocking的库，不做优化的话async
还是会被blocking的库搞得效果大打折扣。不过看样子他们对Python async并没有太多
研究毕竟不是专业做Python的，我在这里补充一下好了，一般是这么几个方案搞：
1. 用Twisted的话，配合Redis，blocking的标准库部分放进queue里去实现异步
2. 用Tornado的话，除了有自带的async HTTP client之类，还有自带的gen（
generator）可以实现挂起、恢复来实现对blocking库的async化，但是这个方案也有缺
点就是无法嵌套，所以也有配合Redis的，目的是用solution弥补原生不足
3. 用gevent的话，monkey.patch_xxx就是用来patch标准库使其blocking变non-
blocking的，有点magic的味道。gevent能够做协程（coroutine，Tornado的generator
也勉强算但是不如gevent全面），这一个可以不需要Redis等配合
所以实际上在Python里上面3种都是常用的做比较纯的async的方案，当然和Node原生比
确实要麻烦一些毕竟不是亲妈生的，所以别的语言有条件的也在想着把async给做成原生
比如Python 3正在搞原生async支持，龟爷这个月23号就要给大家洗脑了。他的如意算
盘是幻想原生async库能够说服大家转到3：
http://www.meetup.com/silicon-valley-python/events/138635282/
不过就算官方async库不下放2，也应该会有社区版单独的backport库
Python shop里Pinterest搞gevent比较有心得，可以看看这个：
http://engineering.pinterest.com/post/65713073803/how-we-use-ge
综合起来效率（不是无脑serve一个简单的静态hello world）其实Node优势一般，它的
优势在于原生async和JS一门语言可以比较偷懒
three
【在 p*****2 的大作中提到】
: http://queue.acm.org/detail.cfm?id=2567673
: 信息量太大了。
: We did some prototyping with Ruby and Python using the evented frameworks
: EventMachine and Twisted. The bottom line was that Node proved to be 2-5
: times faster than both of those in terms of raw throughput. What was even
: more exciting and really sold us on Node was that it took only two or three
: hours to write the Node prototype while it took us more on the order of a
: day or two to write the EventMachine and Twisted ones, just because we had
: to download so much more stuff.
: For example, you need to make sure you're not using the standard HTTP
|
d****i
发帖数: 4809 | 5 公孙侠专业点评不错，请问如果Python3加入原生async支持的话，会不会更进一步和
python2.7不兼容？毕竟JS is born to be async.
async
generator
【在 d********g 的大作中提到】
: Node的async优势在于原生。从技术来说LinkedIn这个写Python的并不是很全面，
: Python做async用Twisted是需要注意如果夹了标准blocking的库，不做优化的话async
: 还是会被blocking的库搞得效果大打折扣。不过看样子他们对Python async并没有太多
: 研究毕竟不是专业做Python的，我在这里补充一下好了，一般是这么几个方案搞：
: 1. 用Twisted的话，配合Redis，blocking的标准库部分放进queue里去实现异步
: 2. 用Tornado的话，除了有自带的async HTTP client之类，还有自带的gen（
: generator）可以实现挂起、恢复来实现对blocking库的async化，但是这个方案也有缺
: 点就是无法嵌套，所以也有配合Redis的，目的是用solution弥补原生不足
: 3. 用gevent的话，monkey.patch_xxx就是用来patch标准库使其blocking变non-
: blocking的，有点magic的味道。gevent能够做协程（coroutine，Tornado的generator
|
d********g
发帖数: 10550 | 6 另外这篇文章提到Java没有主流async框架（2011年左右）？Play也被羞辱了？
“We started looking at some evented frameworks in Ruby such as EventMachine
, as well as Twisted in Python. But there seemed to be no mainstream evented
Java frameworks when we first started checking into this. While Play has
become a little more prevalent now, back when we were doing our analysis, in
early 2011, it didn't pop up on our radar for some reason.”
感觉不会吧，如果是他们瞎说的，那这文章的水平可见一斑……等Java的人来鉴定了
three
【在 p*****2 的大作中提到】
: http://queue.acm.org/detail.cfm?id=2567673
: 信息量太大了。
: We did some prototyping with Ruby and Python using the evented frameworks
: EventMachine and Twisted. The bottom line was that Node proved to be 2-5
: times faster than both of those in terms of raw throughput. What was even
: more exciting and really sold us on Node was that it took only two or three
: hours to write the Node prototype while it took us more on the order of a
: day or two to write the EventMachine and Twisted ones, just because we had
: to download so much more stuff.
: For example, you need to make sure you're not using the standard HTTP
|
d********g
发帖数: 10550 | 7 应该就是官方和非官方而已，社区应该会有自发的backport（如果单独抠出来难度不大
的话）。具体这个async是不是需要Python 3的新特性的支持还不清楚，现在还比较早
。不过参与的人中有不少以前做Twisted的，而Twisted还只能用2，不知道龟爷会不会
强行规定这个async库不要兼容2
【在 d****i 的大作中提到】
: 公孙侠专业点评不错，请问如果Python3加入原生async支持的话，会不会更进一步和
: python2.7不兼容？毕竟JS is born to be async.
:
: async
: generator
|
d*******r
发帖数: 3299 | 8 好文，信息量真大!
大牛如何看最近老赵天天 hype 的 vert.x?
http://www.youtube.com/watch?v=8ClYUo_A3h0
async
generator
【在 d********g 的大作中提到】
: Node的async优势在于原生。从技术来说LinkedIn这个写Python的并不是很全面，
: Python做async用Twisted是需要注意如果夹了标准blocking的库，不做优化的话async
: 还是会被blocking的库搞得效果大打折扣。不过看样子他们对Python async并没有太多
: 研究毕竟不是专业做Python的，我在这里补充一下好了，一般是这么几个方案搞：
: 1. 用Twisted的话，配合Redis，blocking的标准库部分放进queue里去实现异步
: 2. 用Tornado的话，除了有自带的async HTTP client之类，还有自带的gen（
: generator）可以实现挂起、恢复来实现对blocking库的async化，但是这个方案也有缺
: 点就是无法嵌套，所以也有配合Redis的，目的是用solution弥补原生不足
: 3. 用gevent的话，monkey.patch_xxx就是用来patch标准库使其blocking变non-
: blocking的，有点magic的味道。gevent能够做协程（coroutine，Tornado的generator
|
z****e
发帖数: 54598 | 9 play is the main framework of scala
so should be scala guys talk about this
EventMachine
evented
in
【在 d********g 的大作中提到】
: 另外这篇文章提到Java没有主流async框架（2011年左右）？Play也被羞辱了？
: “We started looking at some evented frameworks in Ruby such as EventMachine
: , as well as Twisted in Python. But there seemed to be no mainstream evented
: Java frameworks when we first started checking into this. While Play has
: become a little more prevalent now, back when we were doing our analysis, in
: early 2011, it didn't pop up on our radar for some reason.”
: 感觉不会吧，如果是他们瞎说的，那这文章的水平可见一斑……等Java的人来鉴定了
:
: three
|
d********g
发帖数: 10550 | 10 async web server的话vert.x看着像JVM系对抗Node的救星，我感觉和Tornado的定位（
侧重web）有点像。但Twisted/gevent这样更generic的async库不是单纯的web，比如
Twisted我们和Redis连用做RPC的async，gevent是放到嵌入式里做Python的async。
Tornado自己可以做点小的项目玩玩不错
【在 d*******r 的大作中提到】
: 好文，信息量真大!
: 大牛如何看最近老赵天天 hype 的 vert.x?
: http://www.youtube.com/watch?v=8ClYUo_A3h0
:
: async
: generator
|
|
|
p*****2
发帖数: 21240 | 11
vert.x要是能做牛逼了也是一件好事。
【在 d*******r 的大作中提到】
: 好文，信息量真大!
: 大牛如何看最近老赵天天 hype 的 vert.x?
: http://www.youtube.com/watch?v=8ClYUo_A3h0
:
: async
: generator
|
p*****2
发帖数: 21240 | 12
async
generator
这篇文章把公孙大神都给印出来了。
【在 d********g 的大作中提到】
: Node的async优势在于原生。从技术来说LinkedIn这个写Python的并不是很全面，
: Python做async用Twisted是需要注意如果夹了标准blocking的库，不做优化的话async
: 还是会被blocking的库搞得效果大打折扣。不过看样子他们对Python async并没有太多
: 研究毕竟不是专业做Python的，我在这里补充一下好了，一般是这么几个方案搞：
: 1. 用Twisted的话，配合Redis，blocking的标准库部分放进queue里去实现异步
: 2. 用Tornado的话，除了有自带的async HTTP client之类，还有自带的gen（
: generator）可以实现挂起、恢复来实现对blocking库的async化，但是这个方案也有缺
: 点就是无法嵌套，所以也有配合Redis的，目的是用solution弥补原生不足
: 3. 用gevent的话，monkey.patch_xxx就是用来patch标准库使其blocking变non-
: blocking的，有点magic的味道。gevent能够做协程（coroutine，Tornado的generator
|
d********g
发帖数: 10550 | 13 说明Ruby shop手忙脚乱换Python、Java方案还是水土不服导致浅尝辄止并没有深入，
最后只好头痛医头脚痛医脚赶紧上个Node先顶着用用
【在 p*****2 的大作中提到】
:
: async
: generator
: 这篇文章把公孙大神都给印出来了。
|
p*****2
发帖数: 21240 | 14
大牛怎么看60，000行Ruby代码变成2000 JS代码？
Python的代码量比Ruby只多不少吧？
【在 d********g 的大作中提到】
: 说明Ruby shop手忙脚乱换Python、Java方案还是水土不服导致浅尝辄止并没有深入，
: 最后只好头痛医头脚痛医脚赶紧上个Node先顶着用用
|
d********g
发帖数: 10550 | 15 离开framework的讨论没有任何意义，JS并不是一个不罗嗦的语言。好比我已经有一个
framework了，自己实现的代码量可多可少，没有任何意义
JS的underscore库知道吧？就是用JS重复发明一些基本功能的轮子。像map()这种常用
的通用函数（非Array的map()方法）JS原生都没有，jQuery也一样造了这个轮子，而
map()在Python里是内置的。这样比代码长度，JS如果不提lib那也就和Python一样一行
。真要比，lib实现的除非非要压缩到一行来硬比，是可以欺负Python这种需要换行的
【在 p*****2 的大作中提到】
:
: 大牛怎么看60，000行Ruby代码变成2000 JS代码？
: Python的代码量比Ruby只多不少吧？
|
d********g
发帖数: 10550 | 16 另外这篇文章的讨论根本就不在代码量上，你也不用转移话题了。我只是实话实说Ruby
shop评论Python和Java并不一定会很专业，如此而已
【在 p*****2 的大作中提到】
:
: 大牛怎么看60，000行Ruby代码变成2000 JS代码？
: Python的代码量比Ruby只多不少吧？
|
p*****2
发帖数: 21240 | 17
我主要是用coffee，你说的map，coffee里用list comprehension很容易做，不过这个
list comprehension也是从python过来的。你一般用这个还是map呢？
【在 d********g 的大作中提到】
: 离开framework的讨论没有任何意义，JS并不是一个不罗嗦的语言。好比我已经有一个
: framework了，自己实现的代码量可多可少，没有任何意义
: JS的underscore库知道吧？就是用JS重复发明一些基本功能的轮子。像map()这种常用
: 的通用函数（非Array的map()方法）JS原生都没有，jQuery也一样造了这个轮子，而
: map()在Python里是内置的。这样比代码长度，JS如果不提lib那也就和Python一样一行
: 。真要比，lib实现的除非非要压缩到一行来硬比，是可以欺负Python这种需要换行的
|
d********g
发帖数: 10550 | 18 显然各有各的用途，map()经常和zip()连用来组tuple list，这种情况我更喜欢用map()
CS不用说这里说的是JS，它本身从来不是以不罗嗦出名的，所以具体到Node，代码量有
缩短是framework的功劳不是JS本身不罗嗦
【在 p*****2 的大作中提到】
:
: 我主要是用coffee，你说的map，coffee里用list comprehension很容易做，不过这个
: list comprehension也是从python过来的。你一般用这个还是map呢？
|
p*****2
发帖数: 21240 | 19
map()
你指的什么framework？node本身还是其他？
【在 d********g 的大作中提到】
: 显然各有各的用途，map()经常和zip()连用来组tuple list，这种情况我更喜欢用map()
: CS不用说这里说的是JS，它本身从来不是以不罗嗦出名的，所以具体到Node，代码量有
: 缩短是framework的功劳不是JS本身不罗嗦
|
d********g
发帖数: 10550 | 20 比代码量的时候通常都是指自己写的这部分。整体的量包括用的各种lib、framework多
少用cloc一测就知道，可惜你看到的大部分都不算这个
极端一点的情况，不管你用什么语言做好的项目，Python/Java/JS/Ruby随便哪个拿来
包一下就开跑，那所有人都可以说只用了一行代码就实现了
【在 p*****2 的大作中提到】
:
: map()
: 你指的什么framework？node本身还是其他？
|
|
|
p*****2
发帖数: 21240 | 21
但是ruby，java，python都比node库多吧？怎么会差了几十倍？
【在 d********g 的大作中提到】
: 比代码量的时候通常都是指自己写的这部分。整体的量包括用的各种lib、framework多
: 少用cloc一测就知道，可惜你看到的大部分都不算这个
: 极端一点的情况，不管你用什么语言做好的项目，Python/Java/JS/Ruby随便哪个拿来
: 包一下就开跑，那所有人都可以说只用了一行代码就实现了
|
d********g
发帖数: 10550 | 22 Node的async目前是因为原生而且靠这个主打，所以没错，别的语言如果不是原生的那
在blocking改non-blocking上是需要patch或者重新搞一些库，因为这里比的是按照
Node的规矩来。npm里non-blocking库的支持比较好，因为别的语言之前都不怎么玩这个
Ruby/Java不知道，Python是要搞原生async，至于能不能进一步简化，还得看出来的效
果如何。可以肯定Python的原生async也是比较底层的，之后会在上面有进一步的
framework，慢慢搭
【在 p*****2 的大作中提到】
:
: 但是ruby，java，python都比node库多吧？怎么会差了几十倍？
|
L***s
发帖数: 1148 | 23 tulip 里面到处是 `yield from`, 扣不出来的，龟叔要强迫你们转py3了
【在 d********g 的大作中提到】
: 应该就是官方和非官方而已，社区应该会有自发的backport（如果单独抠出来难度不大
: 的话）。具体这个async是不是需要Python 3的新特性的支持还不清楚，现在还比较早
: 。不过参与的人中有不少以前做Twisted的，而Twisted还只能用2，不知道龟爷会不会
: 强行规定这个async库不要兼容2
|
d********g
发帖数: 10550 | 24 看了下是严重依赖PEP 380。龟爷破釜沉舟啊
【在 L***s 的大作中提到】
: tulip 里面到处是 `yield from`, 扣不出来的，龟叔要强迫你们转py3了
|
a*******o
发帖数: 290 | 25
That sounds unreal. To cover same amount of business logic, I believe the
code needed in Ruby and Javascript would be about the same. Their code
reduction is very unusual and could not be taken seriously. If those numbers
are real, I can take a guess:
1. Line of ruby code included Rails which is not right. If I generate a new
rails app, before I write one line of code, I already got thousands of lines
, or tens of thousands of lines if Rails itself is counted
2. The developers wrote the app in Java way and created many layers like
Java developers usually do. This is not the Rails way. In rails, you have
models, controllers, helpers, views. If you deviate from this, you'll write
a lot more code than needed.
3. He talked about view rendering being handled on client side. That implies
he has Javascript client that might be separate from the service layer. The
JS code he counted only included the service layer.
【在 p*****2 的大作中提到】
:
: 但是ruby，java，python都比node库多吧？怎么会差了几十倍？
|
z****e
发帖数: 54598 | 26 是
用了vert.x的ruby明显效率上
就没差用了vert.x的js很远
虽然还是低一点，但是远没有到档差的地步
基本上在同一档次上
所以js语言本身的设计并没有体现出优于其它语言 |
j********x
发帖数: 2330 | 27 没希望，node就是按这个场景设计的，python怎么玩也玩不过
node的缺陷应该在复杂度管理，似乎node目前都是通过搭service的模式解决的：复杂
？拆成几个小service就行。。。
【在 a***n 的大作中提到】
: 这个不公平，v8有jit。用pypy加tornado也可以快很多。twisted又慢又难写。
|
z****e
发帖数: 54598 | 28 try vert.py
【在 j********x 的大作中提到】
: 没希望，node就是按这个场景设计的，python怎么玩也玩不过
: node的缺陷应该在复杂度管理，似乎node目前都是通过搭service的模式解决的：复杂
: ？拆成几个小service就行。。。
|
j********x
发帖数: 2330 | 29 我又不是傻逼。。。
【在 z****e 的大作中提到】
: try vert.py
|
