你都有 LLM 了，为什么还纠结 Ruby 擅不擅长。

我前两天刚让 LLM 把一个 PHP 项目用 C++ 重写了一遍，性能提升百倍，只花了几块钱。

更没戏。AI 对 Python、JavaScript 补全最好。

老哥用的那个大模型？我最近也在考虑重构公司一个历史比较久的项目，试了大部分都感觉差点意思。

有 AI 帮忙了，熟悉不熟悉问题不大了，我有些应用甚至使用 Python 来写了。

楼上都没看内容啊，主题讨论的是“Ruby 写 AI 应用有没有戏”

我最近在写一个 AI 聊天应用，遇到一个问题是要处理流式响应，在 Rails 里为了不阻塞请求需要用线程处理，成本较高。对异步生态的需求比以前更迫切了。

是不是 ruby 3+ 已经支持的很好了？

看了啊，问题是 Ruby 写什么应用都没有优势了，就算写 AI 应用又有什么优势呢。

倒是 AI 出现以前，用 Ruby 写东西那是多快好省，对一些别的语言和环境可以降维打击。现在 AI 出来了，你把写 Ruby 的时间拿去做规划然后写点 prompt，一个香喷喷的 C++ 程序就出炉了。比如我上面说的重写的那个程序，其实是编译 DSL 到二进制的一个工具，本来 PHP 或者 Ruby 去处理 DSL 可以很方便地做字符串处理啊正则表达式啊之类。现在我让 AI 帮我从头到尾生成一套基于 std::string 手动解析的工具链也就是 1 美元的事。

Ruby的string#strip是不是很方便？

C++ 里要怎么 strip 呢？你得

std::string trimmedText = text;
trimmedText.erase(trimmedText.begin(), std::ranges::find_if(trimmedText, [](const unsigned char ch) { return !std::isspace(ch); }));
trimmedText.erase(std::find_if(trimmedText.rbegin(), trimmedText.rend(), [](const unsigned char ch) { return !std::isspace(ch); }).base(), trimmedText.end());

看着是不是很蛋疼？但现在有 AI 了，AI 帮我写，我只要告诉 AI 帮我写一个 strip 就行了。这段 C++ 我一个字都看不懂，但我只需要封装进方法里写完测试我就不用管了

我比较吝啬，还用着 2.5 flash，毕竟便宜。舍得花钱的话 claude 和 2.5 pro 都挺好。

大学生可以白嫖 Gemimi2.5 Pro 15 个月，Gemimi 昨天又更新了，现在能力又反超 Claude 了，现在感觉 Gemimi 更不更新就看 Claude 更不更

写这种可以不用读懂不用管。但是要拿来写业务，不还是得需要阅读需要维护，也全部 prompt 给 AI 操弄 C++ 吗？

好奇既然是重新实现了，为什么不选择 Go 或者 rust 这种语言。

为什么要一定要流式，放个菊花转一转也可以吧。 :)

顺便说一下，表情包用不了了。

个人觉得其实是对 Ruby 社区不太有利的局面

AI 的加持使得语言之间的学习和使用的难度大幅度降低了，也就是语言的 DX 的区别大幅度降低（这里说的是写语言本身的 DX，不考虑框架，编辑器对开发实际难度的区别），这让 Ruby 和 Rails 的优势区间大幅度降低

DX（Developer Experience）请写全。都是小学词汇，放个缩写真的很难猜。

我个人觉得清晰 简洁 易读还挺重要的。写其他语言，逻辑一复杂就容易弄出很长/很多代码（也可能功力不够），看着浑身不舒服。

所以现在一行提示词可能就能出来很多行 Ruby 的效果，但生成之后的维护体验，也应该算是“DX”的范畴吧？

当然也许其他人对这也无甚所谓吧，又不是不能跑。

实际上在复杂逻辑上，Ruby 反而不一定清晰简洁吧

比如在什么情况下呢？

比如涉及到复杂的逻辑流程或者科学计算

复杂逻辑流程不是很明白。

科学计算确实是，也只有 Python 或者 Matlab 这类有生态。（不过我想讨论的主要还是平时的业务场景了，科研或者 AI 本来 Ruby 也无法为之。）

我觉得，如果各位还只是纠结在 Ruby 语言的层面，就已经输了。 道理也很简单，其他语言做的事情 Ruby 做不了，Ruby 能做的事情其他语言（特指 Python、TypeScript 和 Golang）都能做。

Ruby 的优势是优雅，而业务最根本的需求是低研发成本、高运行效率；Ruby 曾经也有低研发成本的优势，但现在这个优势被 AI 干掉了。

是啊。其实没什么好说的，能用就多用，不能用也没办法。

说下自己的理解和感受

1. LLM 的核心机制是大量的数据训练和概率计算，最终还是要靠 C/C++ 和 CUDA 这种东西来完成，python 也是要以来 Pytorch 和 Pandas 这种库来完成的
2. Ruby 目前而言缺少 Torch 和 Pandas 这种，计算库和 dataframe 的库
3. LLM 外围和语言没太大关系，重点是 SDK 实现，Ruby 可以考虑RubyLLM

如果仅仅是 Stream 响应的话，也可以直接扔 Job 运行，异步执行 ActionCable 推送到 UI 也可以，这样不用手动新增 Thread；

如果没有 ActiveJob 框架就简单丢 Concurrent::Async 代码也简洁，虽然底层还是用的 Thread；

另一个 Ractor 库的代码风格用起来还是不太顺手；

用 active job + action cable 实现过一版，如果用 solid cable 会产生很多数据库写入，又不想增加 redis 依赖，所以没用这个方案。

SSE 还有一个好处是终止操作比较好做，客户端断开 SSE，服务端也停止处理就行了。如果是后台 job 就需要跟踪 job id。

我感兴趣 async gem 能不能解决，打算在功能开发完之后再研究。

如果你用 ruby 创建了一个有趣的东西，那么 ruby 这个语言就会被带动，反之其他的语言被带动。

如果相比于其他语言，ruby 更容易让我能创造有趣的东西，那么就会用 ruby，反之就会用别的语言。

solid cable 如果基于 pg 的话，用的是 pg 的 notify/listen 功能应该就没有大量 IO 写入的问题吧？不过 pg 这个 notify 有 message body 长度限制这个另外的问题。

一来 go 和 rust 我不会，二来现代化的 C++ 并没有太多内存问题需要用到 go 和 rust 来改进。平时直接用对象的值，然后函数调用可以直接用对象引用，基本不需要碰指针。实际上项目里只有很少数的地方为了减少向前引用而使用了共享指针，其他地方都是引用。剩下的就靠 CLion 帮我做进一步优化了。

如果我懂 go 或者 rust 的话，确实会考虑用这两个语言来写。

这种能拆出来写的模块，当然是写上测试用例然后就不管了咯。

如果这个对象走起来像鸭子，叫起来像鸭子，他是不是 AI 造出来的又有什么关系呢。

我 9 楼的意思就是这样的，写出来不用管的东西当然无所谓。“但是要拿来写业务”就有所谓了。

也期待生成工具发展到习得我的所有习惯，跑出来令人愉悦无可挑剔的代码，这样也是一种真正的解放了 ...

实际业务确实没办法，不过这也是用 AI 的一个好处，可以先 architect，让他自己和自己博弈一圈，找出最合适的架构，然后再往里填。实际看起来通常要比我自己手写设计架构质量更好一些。我现在已经脱离自己动手的阶段了，要写东西也是把脑子里构思好的要求丢给 AI 让他帮我填内容，不符合要求就再鞭打 AI 让他重写，写到我满意为止。

我感觉这位说的很对，估计现在大部分人都是这么弄的。

目前这个时代占便宜的编程体系，更适合那些原本用来开发游戏的生态。AI 时代对 Python 非常友好，主要是 LLM 的底层驱动是 C/C++，而最大伴侣的就是 Python。之前风光的 js，在 llm 时代也没那么风光了。对 Ruby 的话，就更加不怎么友好了，但这并不是针对 ruby 的。

Ruby 的优势之一就是语法精炼，开发速度快。现在 AI 时代，开发速度快慢跟大模型精准度有关。目前的很多反馈是 Go 这样的比较直白并且静态类型的语言用 AI 输出错误率比较低。Ruby 本来也已经很少人用了，现在 AI 时代，“对开发者友好”的优势荡然无存。

Ruby 引以为傲的元编程会也逐渐消失，现在不需要“生成代码的代码”了，只要用自然语言去写 prompt 就够了。Ruby on Rails 引以为傲的一键生成项目目录，约定优于配置等概念，在 AI Console 编程时代已经即将要被淘汰了。

Go 性能强悍且部署方便，Java 也越来越成熟稳定，Ruby 相比下来没什么必须理由去选择了。TIOBE Index 排名已经 20 开外，大概率会在时代的洪流中逐渐消失。

目前还是编程领域过度阶段，目前来看还处于各方混战的时候，AI 编程远没有定型，还有很大的发展空间。我认为很可能会在某个时间，某一个语言会像 Javascript 统治客户端一样，成为 AI 编程领域的主流语言。

ruby 对开发者友好的特性在 AI 时代反而成了负担，monkey type 难以正确推导，而 ruby 又是强类型的语言。简而言之完犊子了。

近十年来 ruby 语言乏善可陈，可用性不强，即将/已经走入垃圾时间。对程序员而言早日转型才有前途。

我前面说的太客气了，可能只有少数几个人能看懂，那么今天我提另一个依据，也是 @arth 引发我想到的。

顺便，大部分人不愧是惯性思维，典型的“金锄头”。大家都忽略了一个问题，LLM 生成式的原理。

神经网络也好，Transformer 的自注意力机制也罢，这都不是这个问题的重点，而重点是一个很简单的问题：

LLM 需要先训练，才能够生成；LLM 的生成，只不过是 Token 出现的概率，而绝非任何意义上的逻辑推导。

所以也应当明白，LLM 才不是 Ruby/Python/Nodejs、Go、C/C++、Rust 等语言的解释器或编译器，在 LLM 眼里，这些代码内容与任何形式的文本都是同一回事。显然在训练数据集中，一定包含了数量不等的英文、法文、德文、日文、汉字以及对应各类编程语言的程序代码。

现在以 Ruby、Python、Java、C/C++、Golang 五种语言为例，问题来了：

• 公开的 Ruby 项目、Python 项目、Java 项目、C/C++ 项目、Golang 项目、JavaScript 项目都有多少，Ruby 项目多吗？Ruby 的代码行数多吗 ？ - 想必各位有自知之明
• 既然如此，那么参与训练的 Ruby 代码、Python 代码、Java 代码、C/C++ 代码、Golang 代码、JavaScript 代码都各有多少，其中 Ruby 代码多吗？ - 想必各位有自知之明
• 既然如此，对于 LLM 来说，生成 Ruby 代码、Python 代码、Java 代码、C/C++ 代码、Golang 代码、JavaScript 代码，那种代码的正确率更高？- 想必各位有自知之明

还有些 Ruby 特有的问题：

• Ruby 语料中含量最大的是哪个版本，Ruby 现在是哪个版本，这些版本跨度之间有多少内容是不能直接拿来用的？
• Ruby DLS 写的太好了，以至于 Rails 里有些代码就像一句完整的英文，只是多了些特有的“标点符号”，LLM 能识别和理解到哪种程度？
• Ruby 高级语法和元编程太灵活了，但这些代码含量相对又少，LLM 能理解到哪种程度？

既然如此，在 LLM 时代，Ruby 还有戏吗？ - 不能说立刻马上没有，喜欢就去用，率真一点，不过也要费劲一点。

Token 的统计频率固然重要。但对于 LLM，知识是可以在各个语种间迁移的，如果 ruby 足够友好，可能 LLM 对于 Ruby 的理解会非常好。

提出一个关键点，难道各位就不能用 ruby 写 解决方案么，python 的 AI 赛道（Pythrch）、工作流 赛道已经很牛了，这个趋势已经是不可逆的了，那么 ruby 的语言特性是什么呢？ 最近我学了国内几乎 90% 的 AI 解决方案平台，几乎没有任何一个平台可以完全满足一个企业的要求，都需要有外部的 API 集成才可以，但是也不是很完美，那么 ruby 在其中可以做哪些，我觉得这是后面的机会，不要基于已经很完善的的东西再去做一遍

能，但是没必要了。同样的代码，我用 Ruby 写也是两三天，我用 C++ 写也是两三天，后者性能可以做到前者的十倍甚至百倍，写 C++ 的人更多更好找。谁还会费劲巴拉呢。

Ruby 的语言特性就是对人类写代码友好，但现在不怎么需要人类写代码了。

别说语言了，就连语言特性都要淘汰了。比如之前我优化一个 C 代码，里面用 sscanf 扫描文件，一个文件要扫描几十万几百万次。后来我让 AI 花了几分钟把 sscanf 那几行代码用 strncmp 和 strtol strtof 重写了一下，性能直接提升 20-40 倍（实测性能）。CPU 密集型代码里连 sscanf 这样的便民函数都要淘汰了，更别说 Ruby 这样的脚本类语言了。

Ruby 代码的理解其实基本上没大问题，写也是可以正常写的，架构应该也可以，拿来给现有系统二改是够用的。主要是写船新的系统性价比太低了。

我的结论正好相反。我觉得 Ruby 反而更有戏。Ruby 语言简洁不啰嗦。用过这些模型的人都知道 token 是有限制的。ruby 一行代码，C++ 要 3 行代码，搞几个简单的功能确实没啥区别，但项目大了以后，非常的吃 token，费用成本大肆增加。这些大模型也是有 token 限制的好吧。一个很啰嗦的语言更加清晰的体验出成本的不同（token 的数量是别人好几倍）。现在模型都能直接调用代码分析结果了，模型自身肯定是调用脚本语言更简单，js, ruby, 或者 python 这些。未来肯定更倾向于模型方便调用的语言。

值得说一下，我已经在一些 AI 工作流平台，搭建一些免费插件，目前表现的非常稳定，而且速度也不慢，我倒是觉得如果有认为速度慢啥的，考虑一下数据表，缓存 代码逻辑结构，减少垃圾代码 可以解决 80% 的问题

RubyLLM 作者：异步 Ruby 是 AI 应用的未来（而且它已经到来）

https://paolino.me/async-ruby-is-the-future/

你都说未来了，未来 token 成本只会继续下降，token 上限只会继续上升……

Gemini 现在已经跑 1M 上下文了，我觉得再怎么也轮不到为了 token 限制而去换语言。而且真的到了 token 费用敏感的时候，就该去自建了。

没戏

你的观点其实放在另一个层面也是成立的。服务器的性能这几年也发展了很多啊，但不还是很多人因为性能问题不选 Ruby，服务器的性能成本也只会继续下降，这么看也没啥毛病。

但不可否认的就是大模型不太可能调用要编译的语言来处理任务。JS，Python 其实可能更有前景