V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
esyed
V2EX  ›  程序员

与 Ruby 相比,NodeJS 有哪些优势?

  •  1
     
  •   esyed · 2015-02-27 13:04:18 +08:00 · 13233 次点击
    这是一个创建于 3317 天前的主题,其中的信息可能已经有所发展或是发生改变。

    对于前端转后端的童鞋来说,可以直接用前端语言写后台,这个是优势
    对于其他童鞋来说,用NodeJS有啥优势呢?
    有什么非用Node不可的理由么?

    92 条回复    2016-03-18 09:43:15 +08:00
    dalang
        1
    dalang  
       2015-02-27 13:10:25 +08:00
    主要还是性能吧,速度快,占用资源少。如果对性能要求不高,我觉得就没到非 node 不可的地步。
    alsotang
        2
    alsotang  
       2015-02-27 13:25:39 +08:00   ❤️ 1
    @dalang 对性能高的话,也没必要用 node 啊。cpu 性能还是要静态语言才撑得住。
    otakustay
        3
    otakustay  
       2015-02-27 13:30:41 +08:00
    NodeJS强在IO性能上,这点确实不是Ruby可以比的

    现在很多系统,瓶颈都在IO而不是CPU了,NodeJS在同样精力进行运维的情况下,IO性能强过主流静态语言Web框架是没啥问题的
    esyed
        4
    esyed  
    OP
       2015-02-27 13:34:11 +08:00
    @dalang node资源占用不少的吧
    esyed
        5
    esyed  
    OP
       2015-02-27 13:38:09 +08:00
    @otakustay node IO比java还强大么?
    datou552211
        6
    datou552211  
       2015-02-27 13:43:32 +08:00 via iPhone
    因为它用的是js
    jarlyyn
        7
    jarlyyn  
       2015-02-27 13:56:13 +08:00
    1.性能
    2.js.前后端一致,可以共用很多库。
    youxiachai
        8
    youxiachai  
       2015-02-27 14:18:27 +08:00
    主要是对js有爱..... 扯其他的都没用....特别是扯性能的....
    zhaoweikid
        9
    zhaoweikid  
       2015-02-27 14:27:24 +08:00 via iPhone
    没有非用不可的优势
    kalasoo
        10
    kalasoo  
       2015-02-27 14:30:37 +08:00
    入 Node.js 坑前,可以看一下 io.js
    typcn
        11
    typcn  
       2015-02-27 14:31:55 +08:00
    Java 不是性能最差的吗?
    各种测试结果都很高
    实际使用起来倒数第一
    acthtml
        12
    acthtml  
       2015-02-27 14:34:05 +08:00
    对我而言

    ruby的优势是ror
    nodejs的优势是js

    但是都没有万能的php好用。
    esyed
        13
    esyed  
    OP
       2015-02-27 14:40:30 +08:00
    @acthtml js有啥优势?
    @typcn 不至于吧,java还是公司的最爱吧?
    WildCat
        14
    WildCat  
       2015-02-27 14:42:26 +08:00 via iPhone
    个人感觉 nodejs 的内存占用不比 Ruby 小。
    marshalchen
        15
    marshalchen  
       2015-02-27 14:42:56 +08:00
    性能的话是rails的劣势,不是ruby的劣势。
    node的优势只在少数场景下比较明显,整体没太多优势,只是多了种选择而已。
    Mirana
        16
    Mirana  
       2015-02-27 14:49:22 +08:00
    异步的io把,假如同步的框架并发1000个请求挂掉了,那么node应该还没挂掉
    skywalker
        17
    skywalker  
       2015-02-27 14:55:27 +08:00
    > 有什么非用Node不可的理由么?

    没有。

    论写程序的舒服程度,肯定不如Ruby;论性能,不如Go;论并发性,应该不如erlang。

    但是大部分的项目其实要求都没有这么高,找个写着舒服的吧。
    momo5269
        18
    momo5269  
       2015-02-27 14:56:51 +08:00
    66beta
        19
    66beta  
       2015-02-27 14:58:25 +08:00   ❤️ 1
    nodejs被拿来跟各种语言比,每个语言都在某个点上战胜它
    反过来,也就是说,node的综合性能是最强的

    抵制java
    PHP万能
    jprovim
        20
    jprovim  
       2015-02-27 15:08:29 +08:00
    Rails vs NodeJS
    Ruby vs JavaScript

    拿一個 Programming Language和 Framework比較, 是沒有意義的.

    如果非要這兩個比較的話,

    * Rails的話, 框架成熟, 畢竟是05年的有將近10年產齡的老產品.
    * 前端上手Node快, 不用2次學習, 開發快.

    當然了, 具體怎麼選擇, 還是看整個團隊擅長什麼.
    scarecrow
        21
    scarecrow  
       2015-02-27 15:18:36 +08:00   ❤️ 1
    又是语言之争,没有最好的只有最合适的。

    ruby 优雅灵活,一旦喜欢上让人欲罢不能

    nodejs 前后端一套解决方案,用着省心。

    顺便说一句,相比性能,开发效率,快速验证想法更重要是,很多产品还轮不到你考虑性能问题的时候就挂了,性能问题只是意淫而已。
    kleetaurus
        22
    kleetaurus  
       2015-02-27 15:27:55 +08:00
    Node.JS的优势:
    1. JS通吃前后端,学习语言的时间成本比较低;
    2. 处理效率非常高(基于Google v8引擎、非阻塞I/O)。
    dalang
        23
    dalang  
       2015-02-27 15:46:20 +08:00
    @esyed 楼主明确了 ‘与 ruby 相比’,在资源占用上 node 还是很有优势的。
    dalang
        24
    dalang  
       2015-02-27 15:49:24 +08:00
    @alsotang 性能瓶颈比较常见的还是 IO 性能
    tabris17
        25
    tabris17  
       2015-02-27 16:11:51 +08:00
    学习成本低
    hahastudio
        26
    hahastudio  
       2015-02-27 16:18:19 +08:00   ❤️ 1
    Node.js 让不会区分语言、框架的人也能用
    loading
        27
    loading  
       2015-02-27 16:19:55 +08:00
    @typcn 233,你认识雷锋吗?去过雷峰塔?
    miyuki
        28
    miyuki  
       2015-02-27 16:23:58 +08:00
    会 javascript 的可以很快,不,立即上手
    robertlyc
        29
    robertlyc  
       2015-02-27 16:24:11 +08:00
    一个回调 就抹平了性能优势

    开发效率才是优势
    otakustay
        30
    otakustay  
       2015-02-27 17:24:59 +08:00
    @esyed 同运维环境下,进行相同简单的优化,node的IO比java的nio强应该是没问题的

    我的意思就是,不要node就放那跑,而java从代码到jvm等一系列优化全用上去比。我们假设都是一个相关领域做了2-3年的人来做这事,node的IO超java是妥的
    alsotang
        31
    alsotang  
       2015-02-27 18:27:35 +08:00
    @Mirana node上1000个并发请求只要有一个挂了,剩下999个也都挂了。
    esyed
        32
    esyed  
    OP
       2015-02-27 18:54:37 +08:00
    @kleetaurus JS是门非常丑陋的语言
    esyed
        33
    esyed  
    OP
       2015-02-27 19:13:47 +08:00
    @66beta 为何地址java?
    @alsotang node这么弱啊?如何处理这种情况呢?
    @robertlyc node开发效率很低么?
    @dalang 不是说node很耗内存么?
    @scarecrow 验证想法,用A语言开发一个版本,成功后,改用B语言,这样的案例不多吧?
    @jprovim 前端上手node也不快的吧,如果说快,只是他用过JS,不是说ruby是小白的最爱么?不过这说法好像是骗人的,小白根本玩不动ruby的...
    @youxiachai 难道你不觉得JS设计很渣么?
    scarecrow
        34
    scarecrow  
       2015-02-27 19:53:16 +08:00
    @esyed 例子不少,比较知名的,twitter 当初都是使用ruby后来部分架构调整为java

    linkin 当初也使用ruby 后来转向nodejs
    joyee
        35
    joyee  
       2015-02-27 21:21:28 +08:00   ❤️ 3
    从 Ruby on Rails 转移到 Node.js 的 Linkedin 就有给出过他们转移的理由……摘录一下

    How LinkedIn used Node.js and HTML5 to build a better, faster app
    http://venturebeat.com/2011/08/16/linkedin-node/

    概括:Linkedin 的移动端服务器完全迁移到了 Node.js 上,主要是规模优势+I/O优势,用ROR的时候15台服务器,每台机子15个instance,转移到Node之后每台4个instance,并且能够处理的流量翻倍。

    Ruby on Rails vs. Node.js at LinkedIn
    http://www.infoq.com/news/2012/10/Ruby-on-Rails-Node-js-LinkedIn

    概括:这篇的数据是Node.js某些场景下快20x倍,从30台服务器缩减到3台,前后端团队可以合并提高开发效率。Linkedin的性能提升一部分是因为原来用Rails写的服务器用的技术太老(虽然当时是前沿)加设计不合理,单线程还阻塞的的Mongrel在需要跨数据中心做请求的情况下内存泄漏得跟筛子一样。另外指出拿Node.js和ROR比不太合理,一个是low-level的服务器,一个是完整的web框架
    joyee
        36
    joyee  
       2015-02-27 21:25:26 +08:00   ❤️ 2
    和Java比较的话,Paypal的经验比较有说服力,因为他们不是重写(毕竟不管换不换技术一般重构都会带来提升的),而是Java和Node同时开发一个系统,最后选择了Node

    Node.js at PayPal
    https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/
    1. 降低前后端沟通成本,方便培养全栈工程师
    2. 一开始只在原型使用 Node.js,效果很好,于是后来直接应用于生产环境
    3. 一开始 express 路由 + nconf 配置 + grunt 构建,但 express 写法太灵活缺乏一致性不适合多团队环境,造了一个 Kraken.js 帮助大型团队进行开发

    最初应用于生产环境是流量最高之一的账户概览页面,安全起见 Java 和 Node.js 两个版本同时开发。

    开发速度:
    Java 团队5人,Node 团队2人,Node 团队在延迟2个月才开始的情况下3个月内赶上 Java 团队的开发进度:
    * 在人数更少的情况下,Node开发速度是Java的两倍
    * 代码量少了33%
    * 文件数目少了40%

    性能:
    Java使用基于Spring自创的框架,Node使用自创的Kraken.js和express,dust.js以及其他开源库,3条路由,每条大约包含2~5个API请求
    * 每秒完成的请求数是Java的两倍
    * 响应时间快了35%

    这篇有更详细的介绍
    How Paypal is being revolutionized by Node.js & Lean UX
    http://www.nearform.com/nodecrunch/release-the-kracken-how-paypal-is-being-revolutionized-by-node-js-and-lean-ux/


    其他一些比较有趣的 War Story:

    How We Built eBay's First Node.js Application
    http://www.ebaytechblog.com/2013/05/17/how-we-built-ebays-first-node-js-application/#.VPBikeEc9-W

    Node.js + Cocktails: Scaling Yahoo!
    http://finance.yahoo.com/video/node-js-cocktails-scaling-yahoo-051216550.html
    esyed
        37
    esyed  
    OP
       2015-02-27 21:30:29 +08:00
    @joyee Node 团队在延迟2个月才开始的情况下3个月内赶上 Java 团队的开发进度, 是Node高手打败Java菜鸟么? 貌似Java开发体系还是很完善的,Node工具很多是渣,赶上是小概率事件吧?
    joyee
        38
    joyee  
       2015-02-27 21:55:38 +08:00
    @esyed 主要是Node确实适合快速迭代开发的模式,http://www.nearform.com/nodecrunch/release-the-kracken-how-paypal-is-being-revolutionized-by-node-js-and-lean-ux/里面就有提到Node团队3天内就用Node+bootstrap初步实现了David Marcus给他们打的草稿(用过Node的都很好想象Node干这种事情有多快……),接着进入快速迭代的阶段,不断地测试,接受反馈,改进。相比之下Java团队笨重得多,等他们搞完了controller层跑起来的时候,Node团队已经实现了最初的功能了。

    另外个人参与过J2EE项目的前端开发,这种项目如果前端业务复杂度比较高的话后端的程序员很难独自搞定前端开发,必然要有专业的前端,分开前后端团队,这样就增加了一层沟通成本,也会拖慢项目进度。而Node的好处之一也是前后端可以一个团队完成,降低沟通成本
    joyee
        39
    joyee  
       2015-02-27 22:06:40 +08:00
    @esyed 虽然Node社区确实良莠不齐,不过好用的那些确实好用,如果工程师水平足够高的话,没有好用的也能自己造。像Paypal也提到了Express不适合大团队开发,他们就在上面再搞了个Kraken.js方便大团队合作,他们还fork了dust.js,为自己的业务改进。本来他们的Java团队也是自己在Spring上面再定制了一个框架的,大公司有造轮子的能力的话,工具啊开发体系啊这些并不是大问题……
    joyee
        40
    joyee  
       2015-02-27 22:16:23 +08:00
    @esyed 还有就是,不太可能是Node.js高手 v.s. Java菜鸟,毕竟Paypal用了多少年的Java,而当时Node才诞生不到三年……又是年收入 $3.5 Billion 的 checkout 系统,更不可能交给菜鸟玩了……
    esyed
        41
    esyed  
    OP
       2015-02-27 23:09:09 +08:00
    @joyee 年收入3.5b,手续费能赚这么多?
    node是否不适合用来实现复杂业务逻辑?
    joyee
        42
    joyee  
       2015-02-27 23:17:33 +08:00
    @esyed 感觉是的,linkedin的采访也说了Node不适合处理复杂的数据,主要优势还是I/O,这个确实是强项,而其他用异步I/O模型的技术又没有Node那么热闹的社区和V8这样的挂……

    等到ES6和promise/generator的异步处理普及了可能应用场景会更广一点,不过JS里那堆坑……业务一复杂人一多难免就会踩啊踩……
    esyed
        43
    esyed  
    OP
       2015-02-27 23:21:54 +08:00
    @joyee http://www.digitaltransactions.net/news/story/3243
    3.5b是2011年的交易量吧,不是收入
    V8这样的挂.. .挂啥?
    joyee
        44
    joyee  
       2015-02-27 23:26:25 +08:00
    @esyed nearform的那篇采访说的是bear in mind that checkout is a system that generates $3.5Billion revenue for PayPal……

    V8是个黑魔法外挂的意思……XD
    joyee
        45
    joyee  
       2015-02-27 23:29:00 +08:00
    @esyed 你转的那个新闻说的是移动端的交易量……他那个Node和Java一起写的是整个checkout系统,数字应该是巧合吧……
    jun4rui
        46
    jun4rui  
       2015-02-28 11:24:22 +08:00
    Nodejs用来处理复杂的逻辑还是不行,因为javascript那个异步+回调简直就是复杂逻辑的克星啊!

    但是现在前端和取数据这一块的逻辑真的99%的网站都不复杂,而IO才是瓶颈。所以Nodejs缺点得以回避,优点得以发扬光大。
    futursolo
        47
    futursolo  
       2015-02-28 12:55:34 +08:00
    回调地狱23333
    hooluupog
        48
    hooluupog  
       2015-02-28 15:20:48 +08:00
    性能吧,感觉js引擎提升后,js一下高大上了许多。
    joyee
        49
    joyee  
       2015-03-01 08:52:23 +08:00
    @jun4rui JS ≠ 回调,并且 JS ≠ 异步。是否异步和鼓励回调,都是由 runtime 决定的,Node.js 确实是异步并且整体上鼓励回调 ,但不代表 JS 本身就是这样不能改了。浅一点来说可以用 CPS,深一点来说ES6 的 promise 和 generator 都是回调的代替方案,Node.js 上的 Promise 和 Generator 也都开始普及了(比如 Q,co/Koa)。抛开 Node.js 来说,国内的 fib.js 就把异步逻辑放在了 runtime,上层的 JS 代码用同步的方式写,下层在 runtime 里进行异步的处理,应用层的程序员也完全可以避开回调。
    XadillaX
        50
    XadillaX  
       2015-03-01 12:41:39 +08:00 via Android
    我就说一句话,我是一个被 NPM 宠坏的孩子,这让我不想去碰 ruby,python 等一样有包管理的语言。
    jun4rui
        51
    jun4rui  
       2015-03-01 12:45:28 +08:00 via Android
    @joyee 写复杂逻辑根本不是js应该做的,架构上就应该避免,否则就是扬短避长了。
    jun4rui
        52
    jun4rui  
       2015-03-01 12:48:48 +08:00 via Android
    @XadillaX 看你是前端还是后端了,前端很多工具都要用nodejs装没办法。
    XadillaX
        53
    XadillaX  
       2015-03-01 13:00:16 +08:00 via Android
    @jun4rui 我只是说包管理的机制。python 是一套一套版本来的,npm 各版本互不干扰,一个项目可以有各种版本的包,py 等只能同时用一套版本,一切换就是一套。
    XadillaX
        54
    XadillaX  
       2015-03-01 13:00:43 +08:00 via Android
    @jun4rui 另,我是后端,是前端渣,不会前端的各种东西。
    jun4rui
        55
    jun4rui  
       2015-03-01 17:42:01 +08:00 via Android
    @XadillaX 哈哈,正好,我现在主要前端
    jun4rui
        56
    jun4rui  
       2015-03-01 17:49:10 +08:00 via Android
    @XadillaX 这个对架构现实的软件我觉得不重要,可能我这里环境没这个需求。

    我这里要重建已经稀烂的Java项目,在nodejs、Python、PHP之间考虑,最后还是选择了Python,nodejs对太多的复杂逻辑写起来实在让人担心。而且框架django稳定性延续性都很棒,适合长期维护使用。

    换nodejs+express我真没这个胆量去做一个长期维护的玩意。


    但是一些短小精悍逻辑简单直接的我觉得nodejs倒是首选。

    可能还和咱们开发要求不同有关系,也许你那边确实nodejs能抗大任。
    qiukun
        57
    qiukun  
       2015-03-01 18:31:57 +08:00 via Android
    @XadillaX 那你多个node的时候得nvm吧?在这个层面隔离py 和 ruby也很六呀。你这个黑的无力。(nvm也是从rvm来
    qiukun
        58
    qiukun  
       2015-03-01 18:38:57 +08:00 via Android
    @qiukun
    @XadillaX docker够用就更好
    joyee
        59
    joyee  
       2015-03-01 19:09:47 +08:00
    @jun4rui 是的,JS确实不适合写复杂逻辑,但原因不是异步+回调,而是弱类型+语言设计本身的各种坑,多人协作容易出乱子……
    joyee
        60
    joyee  
       2015-03-01 19:12:18 +08:00
    @jun4rui 异步不一定要浮现在应用层代码,回调有很多替代方案,但语言本身的坑怎么填都填不过来……除非用 TypeScript 之类带类型检查和填了坑的编译到 JS 的语言,但是又有点隔山打牛了……
    joyee
        61
    joyee  
       2015-03-01 19:19:47 +08:00
    @jun4rui 其实看看 linkedin,ebay,paypal之类大厂的做法就知道了,他们都是用其他语言实现复杂的业务逻辑,提供接口给node来用。node主要是发挥I/O的优势起到胶水的作用,典型的就是 ebay/阿里系那样,node可以负责路由的逻辑,调用 Java 之类适合复杂逻辑的语言写的数据层,生成/返回 HTML和配套的前端CSS/JS,或者web service 的API。
    esyed
        62
    esyed  
    OP
       2015-03-01 19:20:07 +08:00
    @jun4rui node在io方面与其他语言的比较资料网上好像不多,只找到一个和.net的比较
    http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/
    @XadillaX 你现在是node程序员么?现在整日撸node? 一个项目同个包可以有不同版本,这是node_modules嵌套吧?这么多node_modules目录,太浪费空间了吧? 执行也更浪费内存吧?
    @jun4rui 为何没选ror,而是选django?
    @joyee TJ好像投奔Go了,是不是被毁掉折腾疯了?哈哈
    esyed
        63
    esyed  
    OP
       2015-03-01 19:22:55 +08:00
    @joyee paypal那个系统的业务逻辑也是用node写的吧? node调用其他语言,有人这么干过么?如何调用,哈哈有人用Node调用过其他语言么?
    joyee
        64
    joyee  
       2015-03-01 20:31:49 +08:00
    @esyed TJ现在在做分布式系统而不是 web 开发,明显go更合适嘛……而且他很明显认为generator才是node的希望,所以搞了co/koa,但现在generator还不够普及,node之前在joynet的独裁下,对V8和ES6的更新太慢(所以才闹出了io.js),失望了也很正常,不代表他再也不会回来的……

    调用其他语言的数据层,也就是一个API的事情,并不是直接开一个进程这种调用啊……何况会要专门写一个数据层的网站,这些东西明显不在一台机器上……
    joyee
        65
    joyee  
       2015-03-01 20:39:32 +08:00
    @esyed 不同版本的包更浪费内存这个是怎么推出来的……不管node_modules怎样,反正只会加载代码里实际用到的那个版本进内存啊。怕浪费空间的话,定时npm dedupe一下合并重复的依赖就可以了。
    0987363
        66
    0987363  
       2015-03-01 21:26:06 +08:00
    后端怎么没有我大c跟大go呢。
    riophae
        67
    riophae  
       2015-03-02 01:53:56 +08:00 via iPhone
    非常感谢 @joyee 的回复,很有帮助
    XadillaX
        68
    XadillaX  
       2015-03-02 08:52:14 +08:00 via Android
    @qiukun 你跟我说的不是一回事,我说的不是 node 版本,而是依赖包的版本。python 的依赖包同时只能是一个版本,比如依赖的依赖是你的依赖的话,版本万一不兼容呢?而 node 的话项目依赖是在自己文件夹下。依赖的依赖是在依赖的依赖文件夹下,依赖的依赖是你的依赖,你可以任何版本无所谓。不会出现不兼容让你头疼的时候。
    angelself
        69
    angelself  
       2015-03-02 10:59:02 +08:00
    数据挖掘总告诉我说ruby是冷门语言没几个人用的(鄙夷脸)
    感觉也没那么冷门诶~还是经常看到有人用诶~感觉是最萌的耶~=w=还是挺喜欢Ruby的
    duzhe0
        70
    duzhe0  
       2015-03-02 11:41:07 +08:00
    node.js是一个原生纯异步的web框架,异步是它和ROR最大的区别。在高并发的业务场景下,非异步框架往往都是抗不住的。
    jamlee
        71
    jamlee  
       2015-03-02 12:05:39 +08:00
    @angelself
    没听说过ruby是冷门 这个超级热门了好吧 love too
    angelself
        72
    angelself  
       2015-03-02 12:27:07 +08:00
    @jamlee ╭(╯3╰)╮就是就是。github都是的嘛
    qiukun
        73
    qiukun  
       2015-03-02 16:10:54 +08:00 via Android
    @XadillaX (算惹,
    jun4rui
        74
    jun4rui  
       2015-03-03 09:22:10 +08:00 via Android
    @duzhe0 异步没问题,因为都有异步实现的办法,左右不了语言的选择。
    fwee
        75
    fwee  
       2015-03-03 11:11:44 +08:00
    说性能的就呵呵了,用ruby的很多都是不屑用callback那种别扭方式写代码,你以为ruby没异步io(EM)?人家早几年就开始用fiber封装了 node捡起来还当个宝了
    kurten
        76
    kurten  
       2015-03-03 12:04:31 +08:00
    没有什么非用某种平台或者技术的理由,对于这个,争论来争论去没啥意义。看团队,什么熟悉用什么,或者对那个感兴趣用哪个。实在不行,自己在造个轮子又何妨?
    aksoft
        77
    aksoft  
       2015-03-03 19:43:51 +08:00   ❤️ 1
    十年经
    joyee
        78
    joyee  
       2015-03-04 01:01:42 +08:00
    @fwee 虽然有异步/非阻塞的库,但是如果社区的各种东西主流还是非异步/阻塞,要真正用上异步还是不容易,ruby和python都是这样。node这方面的优势不过就是新技术(在后端而言)的优势——没有包袱而已,相比之下node社区的主流都是各种异步的包,可以少造一点轮子。其实node本身就自带事件机制,有一定经验的人都会尽量避开callback hell,现在社区的异步处理也开始趋向promise/generator了,只是之前joynet一意孤行对ES6的支持进展太慢,所以才闹出了io.js。

    ruby和node都有自己的长处和短处,没有哪个比哪个绝对好。拿node写CRUD应用肯定也没有用ruby来得快,但在ruby做异步编程,包就不如node好找。何况最后还是得看团队熟哪个再用哪个,不然哪个的优势都不能发挥出来。
    fwee
        79
    fwee  
       2015-03-05 23:55:42 +08:00
    @joyee 那是因为你不了解
    https://github.com/postrank-labs/goliath (最近在node社区大火的generator?几年前rubyist用来开发api)
    EM.defer能很简单的使用同步库
    python界同理
    异步真心坑,没必要只因为个js来限制自己
    est
        80
    est  
       2015-03-06 09:15:33 +08:00
    @fwee Goliath 用了太多C++魔法。。。。很多正统Rubyist看不惯。

    要说纯Ruby风格的还只能算 Celluloid::IO 。

    我工作也是用Goliath。这玩意能解决大问题,但是自身也有大问题。目前正在研究Einhorn,研究出来会发 ruby-china.org
    fwee
        81
    fwee  
       2015-03-06 11:08:55 +08:00
    @est Goliath大量用Fiber,这是ruby标准库何来C++魔法?EM也没有C++的影子啊
    Celluloid::IO前几年很坑,貌似已经脱离erlang(模仿erlang的api少了不少)向akka靠拢?(没用过akka)
    很难说是ruby风格(倒是体现了ruby的表达能力)

    其实现在microservice和云计算这么火,都是container level语言无关,个人很难看好这种在语言内部实现并行/并发来解决问题的方式..
    est
        82
    est  
       2015-03-06 12:51:01 +08:00
    @fwee 没看到C++可能是因为你真的没去看过而已。。。。

    https://github.com/eventmachine/eventmachine/blob/master/ext/rubymain.cpp

    这个就是EM的核心。。。

    老文章一篇 http://www.paperplanes.de/2011/4/25/eventmachine-how-does-it-work.html
    fwee
        83
    fwee  
       2015-03-06 12:53:06 +08:00
    @est 呵呵,那用C实现的还都是C魔法了?
    est
        84
    est  
       2015-03-06 13:00:57 +08:00
    @fwee 不是,是EM用C++改变了Ruby函数调用和运行时机制,遇到edge case就坑了。
    fwee
        85
    fwee  
       2015-03-06 13:07:51 +08:00
    @est 略读了下文章没看出来
    joyee
        86
    joyee  
       2015-03-06 14:45:54 +08:00
    @fwee **能够**使用同步库是没有意义的,因为一旦某个地方阻塞住了,整个非阻塞系统的优势就被消灭了。这也是为什么python早就有twisted但是没发展起来的原因,python的标准库和主流的包都是阻塞的,放到一个非阻塞的系统里,异步的优势就没了。既然里面的计算都是要阻塞的,为什么要勉强用非阻塞+单线程(事件机制),而不用原来的阻塞+多线程的方式呢?
    joyee
        87
    joyee  
       2015-03-06 14:54:05 +08:00
    @fwee 另外generator也不是近几年才有的,1999年发布的ES4就有了,但是ES(JS)当年主要活在前端,依赖浏览器厂商的支持,实现新特性的阻力要比其他语言大得多,ES4的改进太激进了所以失败得比较惨,才有了目前浏览器里实现得比较广泛的,做了更多妥协的ES5。node活在后端,已经算是比较轻松的了,现在io.js从node.js分裂出去,也是为了能够脱离joynet的独裁,使用更新的V8,用上ES6的新特性。
    alsotang
        88
    alsotang  
       2015-03-06 17:22:12 +08:00
    @joyee 妹子我给你加个油!战死他们!
    joyee
        89
    joyee  
       2015-03-06 19:16:36 +08:00
    @alsotang 0.0 其实并没有什么好战的咩……ruby和node各有长处和短处嘛……

    最美好的就是ES6成功,node merge 回 io.js 转用新版本V8,社区转用更正常的方式处理异步。ruby社区也能有更多异步库可以选择不用担心轮子问题。嗯这样大家爱用哪个用哪个,擅长哪门语言用哪门,天下太平~~

    不过现实一般比较骨感……
    jprovim
        90
    jprovim  
       2015-06-13 17:06:48 +08:00
    @joyee 98天後, Node.js 和 io.js 他們在一起了.
    jedihy
        91
    jedihy  
       2015-07-21 22:01:05 +08:00
    回调的方式写程序很蛋疼,只针对某些应用用nodejs写会好一些。如果你要做的跟非阻塞IO无关的话,那就很蛋疼,没什么优势。
    ncwhale
        92
    ncwhale  
       2016-03-18 09:43:15 +08:00
    @jedihy 递 Promise 喵……
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1408 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 23:46 · PVG 07:46 · LAX 16:46 · JFK 19:46
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.