“用 Rust 开发了十多天还没完成的工作，换成 MoonBit，几个小时就完成了。”（译自原帖） 今年 10 月 8 日，首席工程师、开源开发者 Mirek Rusin 在 X 上分享了开发数据库项目的经历：他先尝试了 TypeScript + SQLite，随后改用 Rust + DuckDB，最终转向 MoonBit。需要说明的是，“十多天”指的是项目开发时间。由于三次尝试采用的技术栈不同，他对项目的理解也在逐步加深，因此也不能直接据此推算 MoonBit 与 Rust 的开发效率差距。 Mirek Rusin（@mirek_rusin）的原帖截图。https://x.com/mirek_rusin/status/2107879666002403468 这个项目名为 bitsql，是一款用于应用测试和 CI 的内存型 SQL Server 模拟器。项目网站还提供了浏览器演示：通过将 MoonBit 代码编译为 JavaScript，数据库执行器可以直接在网页中运行。 AI 生成代码很快，但等待编译、排查错误、重新运行测试，仍然需要时间。不同语言对 AI 开发效率的影响，也逐渐体现在这一轮轮修改与验证中。 AI 写代码，也得等编译器 Rust 的两项突出痛点：编译等待与磁盘占用 Rust 的编译等待与磁盘占用，是开发者经常遇到的两类问题。Rust 包管理与构建工具 Cargo 团队在官方博客中援引 2025 年 Rust 年度调查指出，构建产物占用磁盘过大，是仅次于编译速度的第二大常见问题。 而在另一项专门关注编译性能的官方调查中，超过 3,700 名受访者提供了反馈。其中，55% 的受访者表示，在自己最受构建时间困扰的项目中，修改代码后重新构建需要等待超过 10 秒。主要瓶颈包括依赖 crate 的重新编译、链接，以及单 crate 的增量构建。 对编程智能体来说，改完代码只是完成了一步。它还要等待编译和测试结果，再决定怎么改下一轮。每轮多等几秒，反复执行几百次，等待就会累积。 磁盘也容易吃紧。依赖库产物、调试信息、增量编译缓存和重复的元数据，都会留在构建目录中。Cargo 团队的实测显示，编译 Cargo 自身时，开启增量编译与调试信息的 dev 配置，target 目录在其优化前配置下达到 3,151 MiB，约 3.08 GiB。 如果多个智能体在各自的工作目录里构建，缓存又无法共享，同一套依赖还可能占用多份空间。Rust 团队正在通过减少重复元数据等方式改善这些问题。 如果我们换一种编程语言，AI 开发的实际表现会怎样？ 同 一个数据库，交给 A I 从头写六遍 一项名为 「 minisql-moonbit-vs-rust 」的公开实验让同一个编程智能体，分别用 Rust 和 MoonBit 从零开发 SQLite 兼容数据库引擎：从 SQL 解析、查询执行，做到事务、窗口函数和数据库文件读写。 两种语言各跑三次。 结果是： MoonBit 的最终源码 token 数少约 12%，累计输出 token 数也少约 12%，隐藏测试通过率和开发成本则接近 Rust。 MoonBit 在这次实验中写出了更紧凑的代码，质量、成本和运行性能则需要分别比较。 按项目记录，实验使用 Claude Opus 5.5 ，通过 Claude Code 运行，推理强度设为 high。Rust 与 MoonBit 各进行三次独立构建，每次完成九个开发阶段，最终产物约为 1.3 万行代码。 九个开发阶段覆盖了以下功能： 其中的文件读写需要按 SQLite 的公开规范，处理页结构、B-tree、变长整数和记录编码。 489 个测试用例的预期结果由 SQLite 3.53 生成，其中 242 个隐藏测试始终不对智能体开放。 可见测试用于开发反馈，隐藏测试用于最终评估。 为了让比较尽量落在语言与工具链本身，双方使用相同规格、测试、模型、提示词结构和工具，并成对并发运行。智能体编写的引擎仅允许使用标准库，禁止第三方包和自行引入 FFI；双方起始工程提供接口一致的固定 I/O 层，MoonBit 一侧底层包含预置的 C stub，不允许智能体修改。 每个阶段启动新的会话，AI 需要重新阅读已有代码。这部分开销也计入实验。 语料远少于 Rust，MoonBit 仍交出接近的成绩 MoonBit 的公开代码资源远少于 Rust，却已经能在上万行的工程里做到质量和成本接近。这比单看“少了 12% tokens”更值得关注。 2025年只有 Gleam 约 1/7 的数据，成绩反而更好 独立研究也观察到了类似现象。Alessandro Giagnorio、Alberto Martin-Lopez 和 Gabriele Bavota 的论文《》于 2026