暂时没法理解，暂时觉得怪怪的

@Rei

这个说明看过，刚阅读了一下它附带的文章，关于 Monolith 的思想，我觉得，这是一种很小公司，自己就想一个人单干，然后自己想让自己变得壮观，不想用别的工具，不想复杂，不想残酷，只想用自己手头的巨石把它用好并且为自己扩展更大。

我觉得，这是最典型的 Geek 思想。这是找不到工作的：

https://ruby-china.org/topics/34079

如果这块巨石作为自己的爱好，自己去创业，自己谋生，作为自己的全部，是很理想主义的。但是哪个公司不愿意长大？（其实我想说，要是公司发财了，业务变得越来越大，必须得开始逐渐拆分项目，拆分工程，如果你还是遮遮掩掩地不敢放手，老板可能会马上换方案）

Perl 开发者总是觉得自己能抬起全部，what about Java developers？and nowa-Javascript developers，人家还会跟你抢饭碗。

其实同样的例子，Linux Kernel，早期几乎掌握在 Linus 本人手上，GPL 不一定是非常好的东西，它不容纳厂商私藏，有时候，我们不能认为私藏是一件坏事，人家厂商就不喜欢你知道人家硬件设计怎么了。

作为人际沟通，你要想人脉广，最基本的就是你得容纳各种性格的人。

所以 FreeBSD 才会被用在 PlayStation macOS 作为 System 的其中的 layer。

TED 访谈上，Linus 就嘲讽自己“我跟人接触要有一道 buffer 的”，我并不认为这是非常美好的一件事。

但是后来他能与人接触，还是容纳了别人的驱动程序，说明他还是进步了，但是这就不是 Monolith 了。

谢谢老人们的意见，让我对 Rails 更加理解，那我更清楚它的定位了

看了一下，此 webpacker 非彼 webpack，而是被 Ruby 一层层包得好复杂呀，我自己的前端 lib 是独立写的，强烈建议不要揉在一起，尤其如果公司有独立的前端开发，前端的同事可能会觉得自己受约束。（反正不讨论别人，要是我的话我一定让他后端别抢我的逻辑）。

感觉他挺辛苦的，维护那么多文档

Perl 不是书面 OOP 语言，而是非常独特的一种思想的语言，首先它是 C 那种模块式的，然后 Object 其实是 package 模拟的，当然你可以用 Moose 带上了很多 has 之类的 关键字 DSL，不好解释，但是你可以想象一下用 IE 年代的 JavaScript 进行 OOP 的感受。 它每一个变量本身就是 Scalar，是一种“多元体”，跟 PHP 的 Scalar 基本一样。它每个变量都为不同的数据类型开辟了空间，详情看 perltut 等等 man 文档 perldoc。

Catalyst 太大了，而且很多模块用了 C 实现，有些 Linux 发行版没有装一些模块，编译不过，我开始的时候自己也不会解决（上大一的时候），直到后来熟悉了 Linux C 之后，终于明白它少了依赖 lib，testing 不过，装上了终于通过了。东西很大，执行效率一般。

适合企业级使用，成本也很高。

所以要用的话，我还是用 Dancer。

看到你的头像，跟 cpan 某个贡献者的似乎一样的，你该不会就是那个人吧？

呃，Agile Web Development with Rails，看了一下历史订单，改过来了

YES，我说的是 DIY，马上改一下，改好了

撒，我怎么知道呢，我站在我的观点看，我是觉得，这样有利于展示吧。

我和我的 tutor 也有不喜欢的地方，他喜欢快准狠，减肥药一样的，我喜欢把东西描述得很清晰，但他觉得啰嗦。

就像 ObjC，长长一堆，一个简单的 variable 写出文章出来 还代码即注释，其实我挺喜欢的，这样很文学气质。但是有些人就不喜欢这样，他觉得又长又臭，耽误时间。

我喜欢抽象一点，他喜欢浓缩一点，所以我喜欢用 Ruby / ObjC，他喜欢用 C++。

然后当然也有非常庞大的那种，啰嗦得不得啰嗦的风格的，“写出 spark“ （引自 Delton 某个地方他提到的）的 Java 复杂型抽象。

我不敢点评了，免得引来麻烦。

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

我表达的是：他们就应该 DRY，这样子大家可以了解原理。

其实上面你的帖子提到 JIT 的时候，我想说 Rubinius，它 DRY 了一堆 Ruby implementation of Ruby，虽然这样效率有堪商榷，但是代码很利于学习。

好啦好啦好啦，我不敢乱发帖子了，我会很乖的，我不臆断好了吧。

其实每个人都一样，每个人都有自己擅长的、观察到的方面，同时也有观察不到，没有了解的地方。

你在 27 楼回复

搜了下 Jazelle 这玩意不就是 JIT 么？

我只是不打算纠结下去，所以

你上知乎找 R 大讨论两个实现去

每个人都有自己视觉范围的圈子，不能随便去否定别人说别人 Java 某些东西就不好了，或者 Ruby 什么 facility 不好。

我并不是没有用 rack，在 15 年的时候，我用的是 Plack / PSGI，这玩意跟 rack 一毛一样。

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

恨不得重新发明一门语言，然后重新从 Base Object 开始去实现。

那时候真心没办法，对 IO 还不够了解，Ruby 才刚接触，GIL 理解程度肯定就是刚上手，然后我换了职业找到了一位比较燥的 tutor，做了相关的东西后，学到了很多新的东西。

顺便在社区很久都没帖子了，卖个萌而已。

噢，那路或多，我还真感谢那位在 GIL 帮我跳出 obj marking 坑的前辈

好啦好啦，你是在辩证 YARV 也不差，可以，这点我没有否定 YARV

无论 Hotspot 和 YARV，都是先把这些序列化用的代码转一个个指令，执行的时候基本上就是流水线处理这批东西，所以还是屏蔽了原本垂直方式直接对 buffer 的处理。

我觉得不应该我来和你讨论，你上知乎找 R 大讨论两个实现去，话说：

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

只要有运行时、虚拟机的语言，心脏都是动态的，Java 你可以随时在 reflect 的时候动态注入一些 attribute 和 method，ObjC 也如此，只是你在后面调用这些东西的时候，由于它静态的，没办法通过编译，要不然它就不静态了。

你想说这个？

JS 跟 C++ 一样能处理字节流，就是很麻烦，转成 Array 处理 uint，Perl PHP Python Ruby 用 pack 来包数据，而且 PHP 的 pack 也是转 Array，Ruby 这里社区有一个帖子不也是 [] 运算符处理二进制其中序列某 byte，另外它的转换产出我记得也是个 Array。

https://ruby-china.org/topics/34437

只要你熟悉其中一个工具就够了，能做的功能基本上都能做，JS 只是受浏览器兼容制约，不同的浏览器对 ECMA 实现程度不一。反正吧，fill 一下 shim 一下，各种风格爱好的人也参差不齐。

而且不能评价。因为不同的人有不同的价值观、趋向，所以不要下结论，喜欢用什么就用什么，就像商店那么多衣服，总不可能说买某一件才是最理智啥的，每个人有不同的判断观点，自己喜欢某一件就好。

我在发表的观点里面有陈述：

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

所以如果是做大数据、业务系统等方向的，还是选择 Java 好一些，如果公司有硬件方向需求的，比如 GPU 调用、一些设备调用的，就用 C++ （GPU 一般就是图形，这用在。。。我想说什么你们应该猜得到）。

一般的情况下，你对硬件没有啥要求，你又不去频繁读写 fd，不去做 USB device IO，C++ 就发挥不了优势，templete for Object pool 委托，也就是上面他说的对象池，实际上并不是万能的，其实现代的方法应该是 dynamic pointers，但是据我所知，基本上 C++ 开发他们都不喜欢用这种，而是几乎尽可能静态、语法 scope，也就是限定在某个地方用，需要别的地方稍微调用一下的就引用（refenrece），因为这样效率高。

我说的 new delete 只是一个方面，实际上系统调用还有很多，Linux API 书有多厚就有多少，Java 好处明显就是你不用去关心 System implementations，更不用把这些行为 behavior 的代码写到你的源码文件中，因为它已经帮你 wrapping 好了，你只需要把 Java 的这些对平台抽象的 API 接起来。

所以，不仅仅是 GC，从【系统实现抽象】方面也是一个优势。

.net 刚出现的时候，不是声称要做一套与系统无关的抽象平台吗？就这么回事～

还有的就是，脚本语言都是动态的，它们的代码基本是靠上下文、具有一定强度的衔接，我不记得怎么表达了，假设 Ruby Perl 都是这个对象依赖另一个对象的某个方法，然后直接就调过去，如果另一个对象没这个东西，大不了也就是终止运行，就是错误没有静态语言那种首先声明好大家该怎么协调，然后再进行通讯的法则好。

所以才会诞生 Crystal language，像 PHP 开发往往习惯性各种灵活的反射而数据结构变得很模糊，几乎只有写的那个人自己知道那个 scalar 是什么。

JavaScript 的分流 TypeScript 也是为了实现这一种严格类型系统，确定类型。我觉得最大的好处还是方便查阅，别的开发者看到这个东西，就知道你这个 interface 接上我的 class 需要什么 data。

别森气，我只是提点想法

我当然知道 C++ 对象池，但是开发效率肯定没有 Java 从头到尾你不用担心这些的情况下更安心处理逻辑那样高，就像 ARC 引入了 ObjC 之后，你就可以从代码上少出现那种逻辑，更明了地去处理业务逻辑。

蜀黍别生气～ 我知道我的东西也不见得不玩具。但是起码我不会这么做（笑），我目前还没有把它公开呀。

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

再换位思考下，你之前写 iOS 为啥要用 Cocoa 不学学 Facebook 从 CoreGraphics 绘制写起来？

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

内存级数据序列化

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

我在这个帖子 #18 楼回复了：

https://ruby-china.org/topics/34188

LZ 可以试一下加入 C++ 做几年服务端开发，你就知道原因了。

很多 Rubyist 搬弄概念，作为 C++ 开发者、Java 稍微偏向 IO 实现的开发者是很清楚的，因为他们经常要用到直接的 IO 去传输二进制，用自定义的协议，就连 Android 也有 Parcelable，那是为了解决 Activity <=> Activity 等消息传递的 IO Buffer Object。然后怎么 IO 比较快，做了一段时间之后，我发现他们嘴巴根本几乎不提什么 EventMachine，也不会提 libevent，他们更倾向于直接用系统的 API。

如果不想去考虑 IO 模型，可以直接用现成的而且实现得比较好的——Goroutine，或者 Erlang。

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

Ruby 本身就有一层 VM 对 struct 抽象成了 Object，而且 VM 还没有实现到 Hotspot 那种层面的指令级内存操作支持。加上一些损耗，效率怎么都比不上的，但是我倒是不理解他们还要往这方面跑。

写写 DEMO 告诉大家，噢是这个原理，还是不错的，可以学习一下，但是他们又不喜欢 DRY。你们去看看 midori 有几行代码自己写的 IO，连模型都是用人家的模块引入进来实现的，然后就把别人模块（比如 EventMachine，那是别人用 C 先写好的模型，然后 Ruby 加了外壳包装）的概念搬到自己这里介绍。

所以我才说有炒作之嫌，就是实际上是玩具，性能任何一个游戏服务器都比不上，先别说游戏级的，就普通的服务器框架比如腾讯的 Tars 都不如，不对，应该说根本提不上嘴，不足挂齿，说出来作者都有强烈羞耻感才对。

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

RoR 好歹是踏踏实实做他正在做的事情，哪怕 Twitter 不要它。但是 Ruby 在慢查询、一般条件需求的情况下，它在很认真的做事。

吾认为，Elixir 不能和 Ruby 相提并论，Ruby 早期发明的时候参照了 Python，难不成 Python programmers 整天嘴边搭着 Ruby？

心态很重要，你到底想要什么，想做什么。

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

所以如果是做大数据、业务系统等方向的，还是选择 Java 好一些，如果公司有硬件方向需求的，比如 GPU 调用、一些设备调用的，就用 C++ （GPU 一般就是图形，这用在。。。我想说什么你们应该猜得到）。

请原谅我的言辞。

这是样书吗，我上个月就看到有预定消息。挺想要这么本书的，Agile Web 看着很烧脑，吃得不够干净。

已入：

https://ruby-china.org/topics/34484

Thank you for your translation.

吐槽：

1. 帖子跟实时通讯没有半毛钱关系
2. midori 还不如用最简单的 select IO，高效点用 system API，比如 epoll，不知道是不是作者不会自己写，然后就用了别人的各种 libevent。就一个脚手架服务器，跟 puma 没有任何可比性，应该说，根本提不上，思想差太远。
3. 多路复用是 IO 模型之一，不需要刻意用一些名词来掩盖它原本非常基础的本质。还 EventMachine，我再也不相信了。有时间多看看 C++ 的一些实现比如 asio，或者 Go 的 routine。

Ruby 的性能还是适合用来写点简单的东西，但是没必要浮夸。你拿 C 写一下 IO rw，跟 Ruby 原生写一下，你会发现 C 都完成了，Ruby 还在等待，为何，因为 Ruby 一般把 IO 都写到（可以认为是 append / insert after / push_back）String buffer，对象消息损耗了一点。加上频繁的 GC，就很慢了。

感觉你们社区涉嫌炒作，拿一些很简单的概念、小 gem 进行包装宣传，我已转 C++ & Tars。

怎么说呢，其实 TEXT EDITORs 基本上都是喜欢写脚本的人发起的早期运动，他们觉得 IDE 给的东西太不明智，因为早期 IDE 只能给语法分析的提示，对于语义二层以上分析基本上当初早期的时候还是没有的，所以写着比较尴尬，毕竟动态的语言，你根本没法确定 a is A，b is B，而且还要是 currently is A and currently is B in this scope。复杂分析起来。。。还有点倾向于人工智能了。

所以，我觉得 AI 未来在这语法分析领域一定很有用途。。。AI 作为助手帮你分析这些你写的语法结构、逻辑，甚至你的思想。

扯太远了不好意思

我之前也碰到这个问题，实际上是它的插件有 bug，打开 develop 模式就看到一堆 console 调用失败了，应该是 robocop 等插件没配好或者没正确、良好对接上，另外，你前面语法错了，后面语法继续写都是没法提示的。这个问题不知道修复没，反正很久没用它了（因为碰到这个问题）。其实正确配置后，是可以 parse 到你写的东西而且给予良好的语义提示的。

赞二楼的回复

顺便路过

别介意～

我没有别的意思，用什么无所谓，所有语言几乎都能解决同一个问题，就是运行速度（执行效率）、开发效率、平台特征等等比较而已，无论是哪个工具，存在即合理。

“也许你是看不惯我贴了自己 Blog 的外链吧”，我没看到呀，现在才反应过来。我不介意，不过我看了原文，对比了一下，感觉你是不是把原文的东西改了一些？

嗯，文中说了半天很基础的并行方案，到最后还是叫人家去用 Erlang 了。。。

其实我是能理解的，因为我尝试过越过 GIL，后来发现这样还不如直接用别的语言来得快。

这样的文章很灰色，也能加精。。。真的好吗？

文中说的竞争的情况主要在 IO，然而 IO 是不由 GIL 堵塞的，在我另一个 @luikore 的讨论帖子中有陈述。另外就是，GIL 解决的是线程安全，保证这个时间只有一个线程去处理现场。竞争问题，我的观点是：它只是打乱了 Thread 们的执行规律，按照 priority 优先级执行。也许你对资源还没操作完，就已经下一个 Thread 开始执行了。

这时候加锁会有帮助，让你把资源锁起来，先做完特定步骤后在让别的资源用，但是这样就堵塞了，因为在你锁住的时候，你把别人堵塞了就有点串行的味道了。

无论怎么说，Ruby 还是有它挺有用处的地方，在 IO 密集的应用还是有优势的，但是我觉得 IO 密集的程序。。。反正我是碰不到，而且 GIL 本身已经有点减速的效果了，就算应对 IO 密集，也轮不到 Ruby 去处理。

反正我个人觉得 MRI 是 Ruby 中规中矩的实现语言，其实它的语法糖还是挺好用的，重点是很舒适，特别喜欢。站在这点，你跟我比较它的并行、效率，我觉得牺牲这些去获得更高的使用体验也无所谓。

另外还有一个问题，就是我坚持用 pthread 再注册能不能绕开 GIL？

谢谢，我看这些在很多网站都找不到资源，也不知道怎么解决，不过你倒是帮我解决了这个问题，再次谢谢～

其实当时我已经意识到没有 mark 那个变量，然后尝试各种手动删除，但是翻了半天没找到方案。

LZ fork 是指 Thread or Process？

另外，在后端开发的编程观念里，业务逻辑用多线程是没有意义的（除非异步 IO，先返回后存储，或者除非你写服务器）。

在一般场景中，因为你要 response 客户端，但是你开线程去执行的逻辑可能 request 已经 response 了，而 result 没拿到，结果 response 了没有 result 的结果。