之前的同事用的全 coffee 写的 Node

#2 楼 @lgn21st 这位公子，说的也是我顾虑的问题所在，不过使用同一个语言的意义不在于 Mide set，而在于有相同的书写方式和代码的重用. 异步和回调本身是好的，也很符合我们显示世界的以大部分场景。比如你妈妈叫你回家吃饭。一个大型系统基本都是消息驱动。消息驱动回调是少不了的. 用异步去解决同步问题是一个构建在异步系统上必须解决的问题。这个问题并不是什么大问题。实现 wait 机制就好. 可参见 Erlang 的同步实现

#3 楼 @lilijreey 相同的书写方式和代码重用是销售说给市场听的，作为严肃的开发者千万不要轻易相信，如果为了追求相同的书写方式，那是舍本逐末，能通过语言和框架，结合你在具体场景中的 mind set 才是重点。

用异步去解决问题其实是无奈，从内核支持 IO 异步带来的并发性能优势我承认，但是核心问题在于大量的业务场景，以及业务逻辑代码并不是异步的，但是却要你用异步的方式 ＋ 奇技淫巧来处理。没错必须用异步来解决，但是造成这个问题的原因是因为你别无选择。

请别扯 Erlang，完全不一样的东西好么。

还不一定是丢了西瓜捡了芝麻呢！

你只看到了 Ruby on Rails 的弱项，看 Node.js 强的地方，却没有反过来看各自的优缺点，并结合自己的业务来看那个更适合你。

关于异步，你的业务真的需要么？

想当然是最可怕的。

#6 楼 @rei 哈哈。我有感受到。ROR 对比 Node 的优势太多了，最大的就是成熟，靠谱。看到问题才能进步嘛

#4 楼 @lgn21st 这个同步的问题要用异步解决，感觉到很蛋疼。这个问题的本质不是异步的问题.而是 Node 没有提供一个高层的同步机制。使得在 Node 的中写同步代 IO 码和异步 IO 代码一样简单。这个是问题的原因。为什么说 Erlang，就是因为 Erlang 底层所有的 IO 都是异步的。但是对上面都用了同步的方式提供并且默认是同步的。这样就不会让程序员在业务罗辑的层面去解决非业务罗辑的功能。Erlang 我算是国内资深的开发了。所以不是胡扯的。

#8 楼 @lilijreey 呵呵，那么你为什么不直接用 Erlang？

#9 楼 @lgn21st Erlang 有 erlang 的坑，最重要的问题是用 erlang 所有的东西都要自己写，RoR/Node 有大量包。可以偷懒.哈哈 Erlang 对文本的处理没有这两个语言方便。不过 Erlang 有 Erlang 的优势。嘿嘿

这帖子很牛，牛的不是内容，而是把各种大佬全部召唤出来了.....

#10 楼 @lilijreey 既然熟悉 erlang, 为啥不用 elixir，上手很快吧。Node 回调太蛋疼了

Node 在开发网站方面的确是落后于 Rails 的便捷，不过可以做一些功能单一的东西，这句是真的：

CoffeeScript 是明日黄花，直接用 ES6 ＋ Babel 吧。

除了并发优势外，NodeJS 在互联网应用场景并没有优势，劣势倒是很多：

• 生态成熟度低，很多通用场景都要自己造轮子
• 代码可靠性相对低，经常踩坑
• Javascript 从程序语言设计角度来说，是一个既不适合工业化，又不能让开发者写得开心的语言

曾经因为前后端能用同一种语言，几年前给某创业者推荐尝试 NodeJS，后来该创业者踩了 1 年的坑后，回到了 Ruby。

有些东西不是看起来好就是好的，当然 NodeJS 社区的营销能力的确胜过 Ruby 社区。

你听说过 Go 语言吗？

可以参考 Airbnb，Twitter 等 Rails 只负责前端展示，逻辑都交给后端的 NodeJS 或者 Scala。

莫名其妙，写终端模拟器你想要 rails 给你什么库？再说谁告诉你 ruby 的 io 是阻塞的？建议你放弃思考，直接请人来帮你写。

#18 楼 @nong 这些 µs 果然惊艳！

最近刚开源的一个 koa 项目，基本上按着 rails 的思维去写，不得不吐槽 koa 资料太少了，要开发效率和成熟方案还是得 rails. kails 基本上实现了 rails 框架的一些基本功能，一切都要自己搞啊，方案调研都花了我好几天，感觉又可以搞好几篇博客了

已实现的功能：

• MVC
• Database (postgres), ORM(sequelize)
• migration(sequelize-cli)
• assets compile(webpack)
• Session with redis
• Password with bcrypt
• Testing (mocha)
• Lint (eslint)
• middleware
• ES6 欢迎拍砖

我之前尝试研究过做一个 web terminal，Rails 没有找到现成的开源项目，Node.js 有。 Node.js 的 web terminal 实现相当简洁，几个 IO 对象 pipe 一下：UI <-> Socket <-> pty Rails 当时还没有 5.0，因此做 web socket 还挺吃力 所以在 web terminal 这个场景上，Node.js 是完胜 Rails，不得不服。 但因为这个场景的优势，就完全放弃 Rails 去拥抱 Node.js，就一叶障目了，普通 web 场景，很多还是 Rails 高效。

作为一个开发者，应该多学几种语言、框架，在特定场景下选择最合适的技术。

#18 楼 @nong 我也挺看好 Elixir 的。Ruby 可以从 Elixir 中吸收很多，比如轻量级的进程实现（像 golang 的 channel）可以解决并发程序的开发困难。 我们最近几个项目已经换用 Elixir + Phoenix 来做了，过程和结果都很不错。

爱用什么用什么，用过才知道的感觉也不错。

后端就不要用什么 nodejs 了，那些看起来很美的东西都是忽悠你的。js 这种天生弱智的语言，就没法做后端。在浏览器上应用广泛，也是因为历史原因，再加上也确实没有更好的选择了，才造成今天的怪胎。想无阻塞高并发？elixir/phoenix 啊，beam 平台分分钟灭掉 node。说 golang 也牛逼？你用 golang 写个稳定可靠部署后不用管可水平扩展的分布式框架我看看？elixir+phoenix+OTP，你不再需要别的了。现在唯一的缺点就是轮子不太多，慢慢发展建设吧。现在这时候了，还考虑用 node 做后端，确实需要换换思维了。

前端开发 2 年多 js 写了不少，我只想说 nodejs 单线程的，做项目如果不在意用户量和稳定性的就用吧。

#24 楼 @seamon 轮子不多，不想用，不用怎么造轮子啊

#18 楼 @nong crystal 也是 us 啊，速度杠杠

#27 楼 @small_fish__ 请问 crystal 做 web 开发用什么框架？我找了一下没找到

Crystal +1，这个时候就是强势植入 Crystal 的最佳场景了，如 Ruby 般顺滑，如 C 一般的性能。还是内部 async 的，光 这里 体现出来的 WebSockets 可能性就够 ActionCable 狂流口水的。

上次吵了半天之后我已经对 Ruby 能不能成功转型不抱希望了，与其想改变那么多人，大热的天还不如我自己求变，换个地方玩就好了

为什么要把大好的时光浪费在这些东西上面呢？有空可以多看看国外真正做技术的公司在做什么，Node 这种垃圾只有一些垃圾社区会用。当然也有人会说亚马逊、阿里也用 node，人家只是为了方便招人罢了，用 node 做做不重要的微服务。真正解决问题的是用稳定的语言加上优秀的解决方案（算法等），而不是选择一门新奇的语言，通过某个片面的特性来提升效果。

没想到问个小小的问题怎么多好心人来解答。哈哈个人不看好 elixir+phoenix. Elixir/phoenix两年前就看过源码. Elixir 改良了 Erlang 的一些语法弱项。但是都是不痛不痒的语法。Eralng 做 web 性能肯定没的说。我做大型 MMO 后台就是用 erlnag 写的框架。Nodejs 其实我 一直不看好，前几年刚出来就不看好。主要是我这个功能不想自己写。想用别人的，发现没有现成的 Gem 包，Node 到时有几个. 这两个在看 Node 的项目代码。准备一直到 Ruby 上。So Easy. 不过这几天还真心觉得如果要和 Erlang 这种面向并发的语言比.Ruby,Pyhton，什么的都是小白。如果想彻底支持并发，最后都会发展成 Erlang 这种类型。不过 Erlang 以及领先 20 年了

#29 楼 @defmacro 要不一起把 Crystal 带起来？最新的 kemal 不支持 crystal 0.18 吧。

#32 楼 @small_fish__ 我觉得可以试试，带不带的起来就要看天了。虽然我现在个人兴趣在 Rust，不过 Crystal 作为一门 work language 还是非常不错的，基本上 Ruby 我想吐槽的地方都避免了

看了这么多评论，只觉得现在 Ruby 社区已经有法西斯主义的倾向了。

强调 Ruby / Rails 优于一切和强调 Node.js 优于一切有什么不同么？

用不同的工具干不同的事情，用最快最适合的办法搞定最急需的事情，这才是一个 Senior 该干的事情吧。

#34 楼 @howiehu 那条回复有强调 Ruby / Rails 优于一切？

#35 楼 @huacnlee 没有人去说这句话，但是回复中充满了“A 语言/框架比 B 语言/框架要好”的表达。

#36 楼 @howiehu 是你自己的理解有些问题吧

#36 楼 @howiehu

Ruby & Rails 最好 Ruby & Rails 足够好

现在已经不存在所谓的 callback hell, async/await 写起来也足够优雅，Node 在生产环境使用完全没有问题，前后端同一种语言带来的好处是明显的，ES6/ES6 写起来已经很舒服，可以不用 coffee.

@lgn21st 同意，脱离业务场景谈这些都是扯。。。不在于 rails 到底比谁强，而在于用的人到底会不会用。

同意 @kevinyu 的观点，关键看使用的人会不会用。在“某些”地方 Node 比 rails 好用 100 倍。

#2 楼 @lgn21st

别说话，等 async 出来之后你就不吐槽 callback 了，还好

#17 楼 @nong 拿一个不熟悉的 node 来跟你熟悉的 rails 比，不合适吧？一周 node 连个登录都搞不出来，笑死了

#42 楼 @i5ting 早就通过 babel 用上了，generator 执行器 + 语法糖，这样的东西还不值得吐槽，我就呵呵了。

#44 楼 @lgn21st 这个可能有误解，babel的async是通过generator实行的，但真正的async/await是v8实现的，是参考c#等，还是非常不错的，目前v8 5.1+ 支持了 async，不过 node 支持还需要点时间

#45 楼 @i5ting 这个我就奇怪了，好吧就按照你说的，拿一个现在还不能用，但是未来也许能用的东西来证明这个东西不值得吐槽，是这个意思么？

准确地说，婚姻中永久性冲突比例是 69% 。一份长达 4 年的跟踪调查结果显示，情侣总爱因为同样的问题争论不休，比如：穿上了新衣服、改了发型、胖了或痩了几斤、多了或少了几条皱纹，好像问题存在的时间不是 4 年而是 4 分钟一样，总是陷入重复的拌嘴状态。 你以为老了就会好吗？ 心理学家丹·怀尔（Dan Wile）在《蜜月之后》一书中写道：当你选择一位长期生活伴侣时，你难免会选择一套特殊的无法解决的问题，你也许会同这些问题斗上 10 年、20 年甚至 50 年。

Rails 能带来稳定的收入，和一定的心理优越， 变量或类起名时候的，在约定下尽量的优雅 这是非常棒的体验。

至于其他方面，现金流稳定的话，也许“快”等等，从来都不重要。

不过，在 ruby in domain 的论坛，说 ruby 优，别的有缺点，是 法西斯 倾向万分不妥

作为合格的 法西斯

1. bin id
2. remove Node.js

在 ruby in domain 的论坛，尊重 ruby 是有个人修养的体现，重度尊重是有行业智慧的体现，而讨论 Node.js 是 open 的体现，也是宣传和繁荣的智慧。

着眼中长期利益的 web 技术站，似乎还是 Ruby on Rails

仅待她如伴侣...

似乎又有写一篇公众号的冲动...

坛子里的码农追求的可不是稳定的收入，而是快速增长的收入。坛子里也有老板，深刻知道现在 Ruby 招人有多难。

尊重 Ruby 也不等于不能指出 Ruby 的局限性。说到 Ruby 的优点，优雅和让程序员快乐并不是让项目优秀的必要条件。反而 Ruby 的动态特性造成很多 bug 只有上线后才能找到，超过 100% 的测试覆盖率也不能保证。

#48 楼 @nouse node 招人更难

根据适合的业务场景选择适合的语言，不要跟钱过不去。 我手上的一个项目说白了就是帮别人挂直播频道的在线人数，现在直播那么火。 前端的管理界面、设置界面用的是 rails，这个没话说，确实快捷方便。 后面的具体挂人数的这个东西，node 实在太给力了，1 核 2G 内存的配置的 VPS，轻松做到 5 万人在线，也就是保持 5 万个长连接。 要是用 ruby 早就内存爆炸了。

ES7 里面的 await，async 确实能让回调写起来方便很多，语义也更简洁明了，其他语言特性也都在演进，没如上所说那样不堪。ES7 虽说是未来版本，但目前 Babel 支持良好，ES6 发布之前，多少公司不照样使用 Babel 跑着 ES6.

从开发便利，社区成熟度，Ruby／Rails 无可挑剔，至少无人可敌，但是你要真想从性能方面来比，随便把当前游戏行业，直播行业拉出来溜溜，绝对是 Java／Node 完爆。

另外，不要把不熟当作槽点，你两天没把 Login 功能搞定，就吐槽 Nodejs，那如果换过来，你先入 Nodejs，后入 Ruby／Rails，也两天没搞定，你是不是也跑到 Node 社区把 Ruby／Rails 吐个遍。。。。。

我也觉得社区法西斯主义越来越强，观点略同的拉到一派把观点不同的当作敌对。

Ruby／Node 我都喜欢，这么说不是怕你来喷和稀泥，心性如此，不同场景，做不同选择。

是呀，express 直接看文档就好。rails 看教程都不懂。。。

竟然是一个坟贴，我是说怎么还在纠结异步流程控制问题