Artichoke Ruby 项目收尾

# 收尾 Artichoke Ruby 源码：https://hyperbo.la/w/winding-down-artichoke-ruby/ 2025 年 11 月 3 日，我将 Artichoke Ruby（https://github.com/artichoke/artichoke）归档；在 2025 年 11 月的剩余时间里，我还归档了 @artichoke（https://github.com/artichoke）GitHub 组织下的大多数其他仓库。这件事早就该做了，但我长期抗拒，因为关停它感觉像是承认 Hacker News 评论者是对的——大多数替代性 Ruby VM 最终都会耗尽动力（https://news.ycombinator.com/item?id=20608046）——而我还没有准备好让 Artichoke 成为那个模式中的又一个数据点。 ## 我为什么启动 Artichoke Artichoke 并非始于一个“修复 Ruby”的宏大计划。它始于一个玩具。我想建造一台鲁布·戈德堡机器：一个 Monaco 编辑器界面，让你编写 Ruby 代码，让该 Ruby 生成 SCSS，然后通过 Tokio HTTP 服务器动态地重新样式化页面。为此，我使用了 `mrusty` crate 对 mruby 的绑定。这些绑定能用，但粗糙且偶尔崩溃。（公平地说：它们在做一件困难的事。）事情一件接一件，我没有去构建那个 UI 玩具，而是开始对 mruby 进行“绞杀榕式”改造——逐步用 Rust 实现替换它的各个部分。Martin Fowler 对绞杀榕模式（https://martinfowler.com/bliki/StranglerFigApplication.html）的描述很好地概括了这个想法。这个过程变成了“氧化” mruby。它始终是探索性的。我从未相信 Artichoke 能与 CRuby、JRuby 或 TruffleRuby 竞争。我想看看自己能把这件事推到多远。最初的意图仍然记录在项目的 VISION.md（https://github.com/artichoke/artichoke/blob/trunk/VISION.md）中。 当它让我感到真实的那一刻，是我实现了 `Regexp`——mruby 没有的东西——然后在 RubyConf 2019 上谈论了它（https://www.youtube.com/watch?v=QMni48MBqFw）。站在那个舞台上谈论一个由 Rust 支撑的 Ruby 实现，让这个实验变得切实可感。 ## 我构建了什么 六年里，Artichoke 变得远比它理应达到的程度更真实。我为几件事感到自豪。 ### 一个纯 Rust 实现、符合规范的 `String` Artichoke 发布了一个完全符合规范的 `String` 实现，100% 用 Rust 编写，构建在 `bstr` crate 之上。这项工作反过来回馈了 Rust 生态系统，我很感激 Andrew Gallant 在 `bstr`（https://burntsushi.net/bstr/）的公告帖子中提到我。编写 `String` 迫使我理解 Ruby 的编码语义、字节与字符边界、字素假设，以及 MRI 在边界情况下的微妙行为。这是基础性工作。 ### 一个模块化、面向能力的 VM 架构 Artichoke 在很大程度上依赖 Cargo features 和 crate 模块化。该架构有意地分离了： - VM 形态的关注点（`artichoke-*`） - 核心数据结构（`spinoso-*`） - VM 内部与胶水层（`mezzaluna-*`） - 纯工具（`scolapasta-*`） 这个结构记录在 `ARCHITECTURE.md` 中，并受到诸如 matklad 关于记录仓库架构的文章（https://matklad.github.io/2021/02/06/ARCHITECTURE.md.html）等思路的影响。目标是松耦合。你可以只凭你想要的 capability 来组装一个解释器。原生功能是 trait 驱动且可组合的。 ### 理解 GIL 存在的原因 项目中最有教育意义的弧线之一是解开一个早期架构捷径：将解释器状态包装在 `Rc<RefCell<...>>` 中。PR #442（https://github.com/artichoke/artichoke/pull/442）试图解构庞大的 `State` 结构体，但那个早期决定已经感染了整个代码库。它从未按原样编译，最终产生了数十个小规模重构。PR #670（https://github.com/artichoke/artichoke/pull/670）完成了对 `Rc<RefCell<...>>` 的移除，并使解释器围绕显式的 `&mut Artichoke` 借用重新对齐。那次迁移迫使几乎所有解释器 API 都接受 `&mut self`，并彻底重构了代码库的结构。借用检查器使可变性边界变得异常清晰。mruby 到处传递 `&mut Interp` 的设计，反映了动态语言运行时中可变性存在于何处，以及堆在哪里。经历这个过程让我明白了为什么 YARV 和 CPython 会收敛到某种 GIL 形态：在解释器中，别名化和共享可变状态在其他方式下极难建模。 Ruby 这门语言与 C 和 POSIX 假设紧密耦合。数组希望是连续缓冲区。对核心结构进行超级特化（例如像 Scala 的 map 那样优化空/单/双元素情况）的尝试，感觉与 MRI 对世界的建模方式不一致。Artichoke 最终顺应了那个现实，而不是与之对抗。 ### 教育意义 Artichoke 迫使我深入学习 Rust：unsafe 代码、FFI 边界、指针生命周期、trait 设计、运行时架构、压力下的借用语义。这些教育本身就让这个实验值得。 ## 我为什么收尾 没有戏剧性的原因；我只是没有时间了。随着年龄增长，我的重心转向了工作和家庭。OpenAI 以最好的方式要求很高，而维护一个语言运行时——即使是一个实验性的——的机会成本变得太高了。 快乐也发生了微妙的变化。Artichoke 的很多魔力来自“手工”推动自己学习 Rust。我实现了这一点。我现在在 unsafe Rust、底层设计和 FFI 方面有深厚经验。这个基础让我在使用编码 agent 和现代工具时很高效——但这也意味着最初那种“我能搞清楚这个吗？”的火花已经减弱了。 还有兼容性苦役的现实。Artichoke 的 mspec 和 ruby/spec 以 MRI 2.6.3 为目标。跟上上游 Ruby 是无休止的工作。更新 spec 版本、协调行为变化、追逐边缘情况——永无止境。而且如果没有真正的用户群（或培养用户群的意愿），就没有令人信服的理由来承担这个负担。 我知道它结束时，是在完成 `String` 后三年，我都没有开始实现 `Hash`——下一个要氧化的核心类。 ## 接下来会发生什么 Artichoke 已归档，但没有被抹去。仓库保持公开。架构文档完好。代码仍然可以被研究、fork 或嵌入。我不打算恢复积极开发。对于旧的更新和项目历史，推文仍然在 @artichokeruby（https://x.com/artichokeruby）上。 如果你在生产环境中依赖 Artichoke，你应该规划一条迁移到 CRuby 或其他积极维护实现的路径。Artichoke 将不会收到兼容性更新、新功能或安全补丁。它是完整的，因为它完成了它为自己设定的目标。 ## 谢谢你 归档并不让我觉得是失败。Artichoke 对我来说实现了它的目的。它推动了边界。它迫使我成长。它留下了我引以为豪的产物。而且不再审视每个月 Dependabot PR 的感觉也很好。🤖 感谢每一位提交 issue、发送补丁、提出问题，或者只是相信用 Rust 构建 Ruby 实现值得一试的人。特别感谢我的共同维护者： - choznerol：GitHub（https://github.com/choznerol），@choznerol（https://x.com/choznerol） - b-n：GitHub（https://github.com/b-n），@NZchicken（https://x.com/NZchicken） 如果有什么是我希望读者从中得到的，那就是：去构建东西。即使是奇怪的东西。即使是可能不会永远持续的东西。构建的行为会改变你。