抱歉，我 get 不到你的

那么显然你完全没了解 Rails，甚至不了解 Web 开发，不过你的恶意观点是对的。

Anyway，在这里玩得开心就好

你不用跟我介绍这些框架，PHP 我写过四五年，你也不用反向怀疑，因为你根本没了解过历史。

我把话放这 Web MVC full-stack framework 是 Rails 发明出来的领域，你看到标榜 Web MVC 的框架都是受 Rails 影响的。

我这样说吧，所谓的 Web MVC full-stack framework 就是 Rails 开创的，CI 也深受 Rails 的影响

亲... PHP 的几个流行框架，Symphony、Laravel 都是 Inspired by Rails... 何况还有 CakePHP 这种精仿... 你 可别忽悠我，我 10 年那会做外包对 CakePHP 是源码级精通

Rails 的做法一直是主流的 Web 架构风格... 大前端也就是去年才开始的，你到底有多少工作经验啊...

全栈框架当然要做前端（这才是只有 dead framework 才会做的事），何况 Rails 从 6 年前就开始抓前端了，曾经 Sprockets（Assets pipeline）无比先进，但是前端更愿意用自己那套，而且技术上也超越 Sprockets 了，那么与时俱进而已

等我手头忙完介绍下吧

时间问题，主要是 sprockes 4 开发很不顺利，不过 即使在未来，前端不复杂的项目用 ap 还是很好的，无脑配置，依赖简单，webpack 的配置真是复杂

顺带一提，看似 Rails 提供了各种全家桶大杂烩，但其实所有组件都是可选并且是可替换（而且确实有可替代品）的。

Ruby 谈什么构建？编译前端 assets 发生在部署时候的。

其次，跟前后端渲染有什么关系？Webpack 是个用来做前端资源打包的，Rails 的 Omakase 的思想就是为开发时候一定会遇到的场景提供一套预制好的逻辑自洽的方案出来，所以在重前端的今天，Rails 提出了 Webpacker 来把前端工具链（这里 Rails 选择了 Webpack）集成进来。

另外有三个值得注意的点：

• Rails 6.0 前端 Assets 管理将完全拥抱前端工具链，也就是说，Webpacker 将成为 Rails 全家桶的正式成员（现在还是可选组件）
• Webpack 4.0 相比现在的 3.0 又（为什么是又。。。）要大改
• Webpacker 的开发过程受到 Webpack 几次大改版的影响，早期的设计并不好，大概是 9 月 3.0 发布，才能说是走上正轨了，所以早年对 webpacker 的看法需要重新纠正一下

我现在用自己调整过的 webpacker 替代 assets pipeline 用，其实 Webpacker 根本就不复杂，他就做了四件事：

• 提供了一组 helper 方便你在 Rails 的 view 里引用 webpack 的资源（和 assets pipeline 的对应）
• 包装了 webpack 和 yarn 的工具链到 bin，这里就是把传入的参数传递给真正的命令前做了一个依赖的检查（比如 Node 版本够不够呀，如果没装要怎么装呀）、还有传递执行环境的工作
• 把 webpack 的编译过程集成进 assets pipeline 中去（我魔改了这块使得他可以独立运作，不再依附于 Sprockets，为啥依附？自然是 Assets pipeline 还是 Rails 的默认前端 assets 管理方案）
• 提供了开箱即用的配置（比如 vue、angular 模板，又比如通过 YAML 分离了一部分 webpack 的配置）

如果你觉得 webpacker 复杂，那其实是 webpack 复杂，er 根本就是个中转代理而已

webpacker 还是面向全栈开发的，所以他把自己的目录深植于 app 目录，如果你的团队的成员要身兼前后端开发的职责，因为交互复杂需要引入前后端分离或者需要使用新的前端技术的时候，webpacker 是一个非常好，而且非常容易被接受的方案

但是，如果你的团队分工明确，恐怕 webpacker 就未必适合你团队了，但这并不是说 webpacker 不适合这种场景，而是前后端代码在一个仓库会牵扯到一个工程管理问题。

webpack 配置好复杂。。。 另外稍作配置，完全替代 sprockets 没有问题，我自己这么用三个月了，编译速度提高，时髦值也上去了，不过最近很忙，没啥精力整理分享

webpacker 就是 webpack 呀，只是预先做好了和 Rails 集成的配置而已

你想说的是 DIY Do-It-Yourself，而不是 DRY Don't-Repeat-Yourself 吧

这种风格的核心原理是 obj.instance_exec(&block) 你 google 搜 Ruby DSL 就能看到很多风格 DSL 是怎么做的了

那么你不知道就怎么说 但是他们又不喜欢 DRY ?

我不难为你了，这个 thread 留给大家评判吧

应该是 Rails app 没读到，你可以验证下

具体的原因很难解释，比如 Cap 部署时会把命令运行在 非登录、非交互 的环境下，对环境变量的使用的规则就会比较特殊。

通用的简单的方法我建议你用 dotenv-rails 来把环境变量注入到 Rails app 去

我想说 Rubinius，它 DRY 了一堆 Ruby implementation of Ruby，虽然这样效率有堪商榷，但是代码很利于学习。

那到底他们喜不喜欢 DRY 呢？

问题是你一直在评价 Ruby 啊，我主要否定你在 Ruby 上的看法，Ruby 的事，我比你懂多了吧，而你恰恰这里臆断的东西太多。

而且，你谈到

估计是 Rubyist 过于浮躁，总想着出名吧。

这是我作为 Rubyist 不可以接受的。

再说 Java 还有别的语言、技术，你怎么知道我就不懂 Java 呢？你怎么知道我不会点别的呢？就说你搞 iOS，国内唐巧虾神喵大，国外那个 Chris，我和他们谈笑风生

我的 style 明显就是喜欢重复制造齿轮，你会发现我的代码中很多冗余的实现，实际上很多余，很没必要，实际我是故意这么写的，我就不用社区包，我就希望我把整个世界重新写完。

你刚刚不还提 他们又不喜欢 DRY。 你这个 style，DRY 么？

你既然认同自己 还不够了解、才刚接触 那就 少臆断，不懂的可以多提问

你看看你自己从来这边到现在的回复，对技术的评价都是个啥，我在跟你的邮件里也指出了这个问题，你现在才承认

那是因为你对 GIL 一知半解，GIL 对应用的影响本来是面试题里死记硬背的东西

我没有辩证 YARV 不差，我只是在回答你的问题：

【指令级内存操作】我指的是 Jazelle 可以通过指令集级别去进行优化中间代码，Ruby 好像没这个玩意吧，YARV 能跟它比吗。

另，我有 R 大微信，之前教育过你 GIL 的那个曾是 R 大的室友，其实我们都是认识的。

搜了下 Jazelle 这玩意不就是 JIT 么？不过是输出专有硬件的指令集去，Java machine、Lisp machine 都是有特定历史原因的产物，这些东西有多少是做到大规模应用的？

另，说到 JIT，Ruby 其实也有 JIT 的实现 IBM 给做的，本坛也有介绍 Ruby + OMR JIT 简介

另外 mRuby 的 JIT 就要完成了，这就是官方的了

首先，你不要回避我的问题啊，我列了那么多条呢。

你说的开发效率我不谈，这个东西没有可以对标的案例量化。

【指令级内存操作】我指的是 Jazelle 可以通过指令集级别去进行优化中间代码，Ruby 好像没这个玩意吧，YARV 能跟它比吗。

你这个 好像 用得点睛，答案是有，YARV 好歹也是个虚拟机，就算你不愿意在 Google 上多找找资料你也得知道常见如尾递归优化吧，本坛有很多论坛讨论 比如 https://ruby-china.org/topics/5351

其次，字节码层面已经很难做复杂的优化了，但是 Ruby 暴露了自己的 Parser http://ruby-doc.org/stdlib-2.4.2/libdoc/ripper/rdoc/Ripper.html 导出的是 sexp 风格的 AST，在此基础上可以做的文章就多多了

另外 Ruby 本身强大的动态特性导致他绝大多数应用不需要在字节码、AST 层面执行，而 Java 不在这个层面很多事情非常难搞，比如 DI，即使对标的 C# 在 .Net 平台上也用不上 Spring 这样的框架。

我最近确实在学习 OpenGL，正在做一个图形库，想取代 cocos（其实我又跑去招惹另一帮人了），所以很少在 ruby 社区卖萌了，噢对了，MooTive 部分控件确实有用 Core Graphics API draw 的。

跟我说的没有关系，我也不关心你在做什么

我想表达的是 struct 很轻，但是如果你把 IO 的 buffer 解析序列化成 Ruby Object 的时候，损耗很大。而且很依赖 C，还不如从头到尾用 C 写。

隐藏内存的语言对象模型都轻不起来，你一直在讲 Java，那好，Java 把 IO buffer 解序列化，损耗就不大，那么 Java 的反序列化性能优化怎么做的？JS、PHP、C# 、C++ 常见的语言里有多少不大的？

Ruby 广泛运用在 iOS 的工具链上，于是乎据我所知，像美团这种不依赖 Ruby 的公司，内部也有 Ruby 团队，用于内部工具链、CI 的建设

因为他们经常要用到直接的 IO 去传输二进制，用自定义的协议

IO 传输协议跟 EventMachine、libevent 有什么关系？

但是大家认真看一下这些语言有一个优势——他们可以直接内存级数据序列化

跟语言有什么关系？什么叫内存级数据序列化？

而且 VM 还没有实现到 Hotspot 那种层面的指令级内存操作支持

什么叫 指令级内存操作？

写写 DEMO 告诉大家，噢是这个原理，还是不错的，可以学习一下，但是他们又不喜欢 DRY。

你当初不这么说的啊...

你给公司用 DEMO？你公司心得多大？DRY 是什么的缩写来着...你讲讲你的代码哪里体现 DRY 了？

你们去看看 midori 有几行代码自己写的 IO

不造轮子，这不就是 DRY？再换位思考下，你之前写 iOS 为啥要用 Cocoa 不学学 Facebook 从 CoreGraphics 绘制写起来？

所以我才说有炒作之嫌，就是实际上是玩具，性能任何一个游戏服务器都比不上

还真别说...10 - 12 年那会用 Ruby 写页游的多了去了... 那时候 Ruby 的性能比现在差多了，所以性能还是比得上某些游戏服务器的。

此外，是不是玩具看得是性能？

吾认为，Elixir 不能和 Ruby 相提并论，Ruby 早期发明的时候参照了 Python

错，Ruby 受 Lisp 影响很大，你为什么不多读读书呢... Matz 写过很多关于 Ruby 设计的书和博文出来，国内也引进过几本

其实 C++ 在某些方面并不比 Java 高效，大量的 new delete 等系统调用很耗，还不如 JVM 有对象池、GC 高效利用，在你开发大规模业务型程序的时候，你会发现 java 优势的明显。

难道 Java 的 new delete 的消耗就小？Java 还没值类型呢。C++ 不可以有对象池？不可以有 GC？

rails 本身也埋了很多点 搜 instruments 可以被利用来做监控 具体看看 newrelic-amp sentry-raven 的实现就好

应用层看看 raven-sentry 就好了，解释器层段错误，那你得靠 Ruby 之外的东西监控了

走 SMTP 嘛，SendCloud 也是，跟配置邮件客户端的方式一样的