突然想到一个问题，现在大家都在玩 ChatGPT、Claude 这些，Ruby 是不是又有机会了？ 以前大家老说 Ruby 慢，数据处理不行，所以都跑去用 Python。确实，numpy、pandas 这些库 Ruby 没有，机器学习更是被 Python 统治了。 但现在不一样了吧？大部分 AI 能力都是调 API，本地基本不需要跑什么重计算。我们主要在写的其实就是：
- 调用各种 LLM 的 API
- 处理返回的 JSON 数据
- 搞搞 Web 界面
- 写些业务逻辑
这些活儿 Ruby 不是挺擅长的吗？尤其是 Rails，搭个 AI 工具的后台贼快。
你都有 LLM 了，为什么还纠结 Ruby 擅不擅长。
我前两天刚让 LLM 把一个 PHP 项目用 C++ 重写了一遍，性能提升百倍，只花了几块钱。
楼上都没看内容啊，主题讨论的是“Ruby 写 AI 应用有没有戏”
我最近在写一个 AI 聊天应用，遇到一个问题是要处理流式响应，在 Rails 里为了不阻塞请求需要用线程处理，成本较高。对异步生态的需求比以前更迫切了。
Rei
回复
看了啊，问题是 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++ 我一个字都看不懂，但我只需要封装进方法里写完测试我就不用管了
msg7086
回复
大学生可以白嫖 Gemimi2.5 Pro 15 个月，Gemimi 昨天又更新了，现在能力又反超 Claude 了，现在感觉 Gemimi 更不更新就看 Claude 更不更
个人觉得其实是对 Ruby 社区不太有利的局面
AI 的加持使得语言之间的学习和使用的难度大幅度降低了，也就是语言的 DX 的区别大幅度降低（这里说的是写语言本身的 DX，不考虑框架，编辑器对开发实际难度的区别），这让 Ruby 和 Rails 的优势区间大幅度降低
xstmjh
回复
我个人觉得清晰 简洁 易读还挺重要的。写其他语言，逻辑一复杂就容易弄出很长/很多代码（也可能功力不够），看着浑身不舒服。
所以现在一行提示词可能就能出来很多行 Ruby 的效果，但生成之后的维护体验，也应该算是“DX”的范畴吧？
当然也许其他人对这也无甚所谓吧，又不是不能跑。
rubyfan1
回复
复杂逻辑流程不是很明白。
科学计算确实是，也只有 Python 或者 Matlab 这类有生态。（不过我想讨论的主要还是平时的业务场景了，科研或者 AI 本来 Ruby 也无法为之。）
我觉得，如果各位还只是纠结在 Ruby 语言的层面，就已经输了。 道理也很简单，其他语言做的事情 Ruby 做不了，Ruby 能做的事情其他语言（特指 Python、TypeScript 和 Golang）都能做。
Ruby 的优势是优雅，而业务最根本的需求是低研发成本、高运行效率；Ruby 曾经也有低研发成本的优势，但现在这个优势被 AI 干掉了。
同样的逻辑，AI 生成的 Ruby 代码少，方便 review，这就是 Ruby 的优势。
编程语言是写给人看的，如果有一天 AI 直接生成机器码不用 review，那么就不需要编程语言了。
说下自己的理解和感受
- LLM 的核心机制是大量的数据训练和概率计算，最终还是要靠 C/C++ 和 CUDA 这种东西来完成，python 也是要以来 Pytorch 和 Pandas 这种库来完成的
- Ruby 目前而言缺少 Torch 和 Pandas 这种，计算库和 dataframe 的库
- LLM 外围和语言没太大关系，重点是 SDK 实现，Ruby 可以考虑RubyLLM
Rei
回复
如果仅仅是 Stream 响应的话，也可以直接扔 Job 运行，异步执行 ActionCable 推送到 UI 也可以，这样不用手动新增 Thread；
如果没有 ActiveJob 框架就简单丢 Concurrent::Async 代码也简洁，虽然底层还是用的 Thread；
另一个 Ractor 库的代码风格用起来还是不太顺手；
as181920
回复
用 active job + action cable 实现过一版，如果用 solid cable 会产生很多数据库写入，又不想增加 redis 依赖，所以没用这个方案。
SSE 还有一个好处是终止操作比较好做，客户端断开 SSE，服务端也停止处理就行了。如果是后台 job 就需要跟踪 job id。
我感兴趣 async gem 能不能解决，打算在功能开发完之后再研究。
Rei
回复
solid cable 如果基于 pg 的话，用的是 pg 的 notify/listen 功能应该就没有大量 IO 写入的问题吧？不过 pg 这个 notify 有 message body 长度限制这个另外的问题。
benzhang
回复
一来 go 和 rust 我不会，二来现代化的 C++ 并没有太多内存问题需要用到 go 和 rust 来改进。平时直接用对象的值，然后函数调用可以直接用对象引用，基本不需要碰指针。实际上项目里只有很少数的地方为了减少向前引用而使用了共享指针，其他地方都是引用。剩下的就靠 CLion 帮我做进一步优化了。
如果我懂 go 或者 rust 的话，确实会考虑用这两个语言来写。
zhandao
回复
这种能拆出来写的模块，当然是写上测试用例然后就不管了咯。
如果这个对象走起来像鸭子，叫起来像鸭子，他是不是 AI 造出来的又有什么关系呢。
msg7086
回复
我 9 楼的意思就是这样的，写出来不用管的东西当然无所谓。“但是要拿来写业务”就有所谓了。
也期待生成工具发展到习得我的所有习惯，跑出来令人愉悦无可挑剔的代码，这样也是一种真正的解放了 ...
zhandao
回复
实际业务确实没办法，不过这也是用 AI 的一个好处，可以先 architect，让他自己和自己博弈一圈，找出最合适的架构，然后再往里填。实际看起来通常要比我自己手写设计架构质量更好一些。我现在已经脱离自己动手的阶段了，要写东西也是把脑子里构思好的要求丢给 AI 让他帮我填内容，不符合要求就再鞭打 AI 让他重写，写到我满意为止。
目前这个时代占便宜的编程体系，更适合那些原本用来开发游戏的生态。AI 时代对 Python 非常友好，主要是 LLM 的底层驱动是 C/C++，而最大伴侣的就是 Python。之前风光的 js，在 llm 时代也没那么风光了。对 Ruby 的话，就更加不怎么友好了，但这并不是针对 ruby 的。