“用 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 开发的实际表现会怎样？
同一个数据库，交给 AI 从头写六遍
一项名为 「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 的论文《No Resource, No Benchmarks, No Problem?》于 2026 年 6 月发布，研究了模型如何学习代码资源极少的编程语言。
论文统计的时间点是 2025 年 7 月 2 日：MoonBit 约有 400 个公开 GitHub 仓库，Gleam 约有 2,900 个，前者约为后者的 1/7。论文讨论中还以 Rust 约百万级的 GitHub 仓库规模作为背景对照。公开仓库数可以反映可获取代码资源的差距，但不等于任何模型实际使用的训练 token 数。
更直接的对照出现在研究构建的微调数据集里：MoonBit 只有 0.5M tokens，Gleam 为 3.6M tokens，同样约为 1/7。 尽管数据更少，两个 Qwen 模型分别微调后，MoonBit 在三个基准上的 pass@1 都更高：
这里的 1/7 对应微调数据量；论文的继续预训练数据则为 MoonBit 13.7M、Gleam 28.3M tokens，口径不同。
提供少量代码示例或检索文档时，MoonBit 的提升幅度通常也更大。论文作者认为，这可能与它已有代码资源较少、语言设计面向 AI 有关；实验尚未证明其中的因果关系，MoonBit 也并非在所有设置下都领先。
这项研究测的是函数生成，数据库实验测的是持续数小时的工程开发，分数不能直接横比。不过，两者都说明：语料少，并不必然意味着模型写不好这门语言。
少约 12% 的源码 tokens，质量接近 Rust
根据公开原始数据重绘；每种语言三次运行取均值。
这里统计的是 tokens，不是代码行数。Rust 平均为 13,298 行，MoonBit 为 13,842 行，后者反而略多。行数受格式化和换行习惯影响，token 数更接近模型实际需要处理的文本量。
双方隐藏测试通过率相差约 0.7 个百分点，折合每次构建平均不到两个测试。每种语言只有三次运行，还不足以据此分出质量高下。
为什么更紧凑？从错误处理到内存管理
MoonBit 的优势并非只出现在某一个阶段。九个开发阶段中，有八个阶段的平均输出 token 数低于 Rust；写文件阶段基本持平。
连接与子查询阶段的输出比值约为 0.76，索引、视图与事务阶段约为 0.85。结合实际代码，论文提出了三个可能的原因。
自动内存管理，省去借用和生命周期标注。
Rust 通过所有权规则管理内存，并由编译器检查这些规则，这是其安全性和系统编程能力的重要基础。相应地，实现过程中可能需要表达借用、可变借用、生命周期和共享所有权关系。
这个数据库任务是单线程的，主要工作是处理数据结构。MoonBit 使用自动内存管理，AI 无需在实现中编写同类的借用和生命周期标注。
错误处理更简洁，减少重复代码
Rust 通常通过 Result 表达可能失败的操作，并在调用处使用 ? 传播错误。MoonBit 则可以在函数签名中使用 raise 声明可能抛出的错误，减少调用处的重复标记。
在论文抽查的一组实现中，MoonBit 的 SQLite 文件读取器估算 token 数比 Rust 少约 39%。这一差异包含错误处理、借用和生命周期等多方面的表达，不能全部归因于 raise。
这里采用“非注释代码字符数除以 4”的简化估算，与前文整个项目使用 tokenizer 统计的口径不同，结果也仅代表这个组件。
反馈足够快，频繁检查就有了价值
MoonBit 在实验中也暴露出一些问题：编译检查失败的比例为 13.0%，约为 Rust 的 2.25 倍，这主要是因为MoonBit语料相对很少，而且一些语言特性还在修改，预计1.0之后类似的问题会大为减少。
研究者逐次分析后发现，MoonBit 约一半的失败来自尚未写完就检查代码、重构引发的连锁修改、新增枚举分支等通用开发问题。它的语言指南鼓励每次编辑后检查，智能体也确实更频繁地调用了 moon check。
在实验使用的机器和工程上，MoonBit 的完整类型检查耗时约 0.2 秒，Rust 的干净 cargo check 约为 0.8—1.1 秒。检查够快，智能体就可以改一点、查一次。
语言相关的错误则集中在少数模式中：把 using 当成变量名，把 Rust 的 let (mut a, b) 写法带入 MoonBit，猜测不存在的 API，以及错误效果标注问题。按照作者的归因估算，相比 Rust，这类额外错误平均每次构建增加约 11 次 API 调用、0.43 美元成本。
还有一个工具链细节：智能体经常用 tail 截取编译器输出，较长的警告信息有时会把真正的错误挤出截取范围，导致再次调用工具。
错误信息能否被完整读到、API 能否查到，都会影响下一轮修改。工具链的这些细节，同样值得改进。
成本几乎持平，AI 何时停手影响更大
MoonBit 的平均成本略低，但六次运行并不支持“MoonBit 一定更省钱”的结论。
按均值，MoonBit 成本约为 Rust 的 0.94 倍；按中位数，这个比值却变成约 1.12 倍。Rust 的三次成本从 35.29 美元到 59.12 美元，运行之间的波动大于两种语言均值之间的差距。
原始材料给出的结论是：两种语言在开发成本上基本持平。
一个影响成本的因素是：可见测试已经全部通过，智能体还在继续做差分测试、性能分析和边界情况处理。
研究将各阶段首次“全绿”前后的输入量汇总后发现，47%—82% 的输入 tokens 消耗在可见测试通过之后。 这些工作可能提升程序质量，但也说明，智能体的停止策略会显著影响账单。
如果只看首次通过可见测试之前的输入量，MoonBit 平均约为 Rust 的 1.09 倍，也没有出现单方面领先。
所以，比较 AI 开发成本时，还得约定任务何时算完成。多做一轮排查，就可能改变两种语言的成本排名。
需要说明的是，这项实验只使用了一个 AI 模型，Rust 和 MoonBit 各进行了三次独立开发，任务也仅限于不使用第三方库的单线程数据库引擎。
程序的运行速度和内存占用各有差异。在十项受控微基准测试中，以 Rust 的耗时为基准，MoonBit 的耗时比取几何平均后约为 1.25，也就是总体上需要多花约 25% 的时间。而在一次索引工作负载测试中，MoonBit 的峰值内存占用（RSS）为 170 MB，Rust 为 601 MB。
这些数据反映了本次实验中的表现，但由于样本较少、任务范围有限，不能据此判断两种语言在其他工程场景中的优劣。
补齐生态，MoonBit Hackathon 火热进行中
生态仍是 MoonBit 需要补齐的短板，也是 MoonBit 接下来重要的工作。
截至发稿，Mooncakes 官方统计已有 27,108 个包（packages）。以年初约 2,500 个包为基数，目前包数量约为年初的 10.8 倍。
2026 MoonBit 黑客松正在进行中。 欢迎开发者用 MoonBit 和 AI 编程工具，来一起构建生态！
你可以开发通用工具库、协议与基础组件，也可以尝试数据处理、数据库、AI 应用、CLI、解释器和其他开发者工具。原创项目、成熟生态库的 MoonBit 移植，以及已有项目的实质改进，都可以参与。
项目不必很大。把一个常用的库移植过来，或把自己一直想用的小工具做出来，都可以成为起点。
参考资料：
MoonBit 与 Rust 的 AI 编程对照实验：开源仓库、设计及结果：
https://github.com/bobzhang/minisql-moonbit-vs-rust
实验论文：Agent-Friendly by Design（预印本）：
https://github.com/bobzhang/minisql-moonbit-vs-rust/blob/main/paper/moonbit-agent-friendly.pdf
Mirek Rusin：用 MoonBit 开发 bitsql 的实践分享：
https://x.com/mirek_rusin/status/2107879666002403468
Cargo 团队：构建产物磁盘占用的优化实验：
https://blog.rust-lang.org/inside-rust/2026/08/18/reducing-target-dir-size-on-nightly/
Rust 官方：2025 年编译器性能调查结果：
https://blog.rust-lang.org/2025/09/10/rust-compiler-performance-survey-2025-results/
独立研究：No Resource, No Benchmarks, No Problem?
https://arxiv.org/html/2606.16827v1
Mooncakes 官方包仓库与生态统计：
https://mooncakes.io/
2026 MoonBit 黑客松官网：赛程、报名与奖励：
https://moonbitlang.github.io/Hackathon2026/
