突然想到一个问题，现在大家都在玩 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 能不能解决，打算在功能开发完之后再研究。