瞎扯淡 Ruby 在 LLM 时代还有戏吗?

rubyfan1 · 2025年06月06日 · 最后由 Rei 回复于 2025年06月17日 · 1050 次阅读

突然想到一个问题,现在大家都在玩 ChatGPT、Claude 这些,Ruby 是不是又有机会了? 以前大家老说 Ruby 慢,数据处理不行,所以都跑去用 Python。确实,numpy、pandas 这些库 Ruby 没有,机器学习更是被 Python 统治了。 但现在不一样了吧?大部分 AI 能力都是调 API,本地基本不需要跑什么重计算。我们主要在写的其实就是:

  • 调用各种 LLM 的 API
  • 处理返回的 JSON 数据
  • 搞搞 Web 界面
  • 写些业务逻辑

这些活儿 Ruby 不是挺擅长的吗?尤其是 Rails,搭个 AI 工具的后台贼快。

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

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

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

msg7086 回复

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

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

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

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

Rei 回复

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

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++ 我一个字都看不懂,但我只需要封装进方法里写完测试我就不用管了😏

greatghoul 回复

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

msg7086 回复

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

msg7086 回复

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

msg7086 回复

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

11 楼 已删除
Rei 回复

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

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

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

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

xstmjh 回复

DX(Developer Experience)请写全。都是小学词汇,放个缩写真的很难猜。

xstmjh 回复

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

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

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

zhandao 回复

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

rubyfan1 回复

比如在什么情况下呢?

zhandao 回复

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

rubyfan1 回复

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

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

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

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

a0nqm 回复

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

同样的逻辑,AI 生成的 Ruby 代码少,方便 review,这就是 Ruby 的优势。

编程语言是写给人看的,如果有一天 AI 直接生成机器码不用 review,那么就不需要编程语言了。

说下自己的理解和感受

  1. LLM 的核心机制是大量的数据训练和概率计算,最终还是要靠 C/C++ 和 CUDA 这种东西来完成,python 也是要以来 Pytorch 和 Pandas 这种库来完成的
  2. Ruby 目前而言缺少 Torch 和 Pandas 这种,计算库和 dataframe 的库
  3. 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 能不能解决,打算在功能开发完之后再研究。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号