Qwen3.8: 从 0 到 1 用 Rust 重写 Mooncake: Suncake
内容提要
本文介绍作者用Rust重写Mooncake存储模块为Suncake项目，通过Qoder和Qwen3.8从零开发，仅用37个提交完成。相比C++版，性能提升显著：墙钟时间约为C++的52%，get尾部延迟改善数百倍，线程数从266降至21。作者认为Rust的async/await更适合IO密集型应用，并指出项目零单测等弱点。
延伸解读
Rust 重写的核心优势：类型系统与异步模型
作者认为 Rust 更适合 IO 密集型应用，因为其类型系统和 borrow checker 能显式表达意图，减少 AI 编程中的猜测。对比 C++，Rust 编译通过后内存安全更有保障，而 C++ 的隐式错误（如迭代器失效）难以察觉。性能对比显示，suncake 在 get 尾部延迟上比 C++ 快数百倍，线程数从 266 降至 21，关键在于异步化 IO 编排，避免线程被单个传输占住。
AI 辅助开发的实践与局限
项目仅用 37 个提交完成，全程由 Qoder 和 Qwen3.8 驱动，人工只输入一个 prompt。AI 在规划、执行和验证中表现出色，但作者也承认存在弱点：零单元测试、clippy 未清零、2Q 驱逐算法仍为降级形态。这反映了 AI 编程在快速迭代时可能牺牲代码质量，需人工权衡取舍。
性能对比的启示：中位数 vs 尾部延迟
A/B 测试显示，put 和 get 中位数两者平手或 C++ 略好，但 get 尾部延迟差异巨大（p99 差 339 倍）。这说明高并发下，同步占住 RPC 线程会导致尾部延迟恶化，而异步化能显著提升稳定性。线程数翻倍反而更差，表明资源利用效率比单纯增加线程更重要。
Q&A
为什么作者选择用 Rust 重写 Mooncake 存储模块？
作者认为 Rust 更适合 AI vibe coding 和 IO 密集型应用，因为 Rust 能显式表达意图（如 enum、match、Result、trait），且类型系统和 borrow checker 能直接保证内存安全，减少隐式错误。相比之下，C++ 编译通过不代表内存安全，容易隐藏悬空指针等问题。
Suncake 项目相比 C++ 版 Mooncake 在性能上有哪些提升？
Suncake 的墙钟时间约为 C++ 版的 52%（M1: 108.8s vs 209.2s；M2: 81.9s vs 156.6s）。get 尾部延迟改善数百倍（p99 从 34045ms 降至 82ms，max 从 68114ms 降至 153ms），线程数从 266 降至 21。
Suncake 项目是如何从零开始构建的？
作者使用 Qoder 和 Qwen3.8 模型，仅输入一个 prompt 指定功能范围、API 兼容性和架构要求，然后 Qoder 在 plan mode 中分析代码库并生成 spec，随后按 M1、M2、M3 三个里程碑逐步实现，每个里程碑都有硬性验收标准。整个项目从 2026-09-03 到 09-05 共 37 个提交完成。
Suncake 项目有哪些技术弱点？
根据 kimi-k3 的评估，Suncake 存在三个弱点：clippy 未清零（有一个已升级为 hard error 的 dead API）、全仓零单元测试（回归保障依赖 smoke example 和 Python e2e）、以及 2Q 驱逐仍是 ADR-004 中自认的降级形态尚未收敛。
为什么 Suncake 的 get 尾部延迟远优于 C++ 版？
因为 C++ 版中 RPC 线程同步占住直到跨 client 传输结束才释放，而 Suncake 使用 Rust 的 async/await 将 IO 编排全部异步化，worker 不会被单个传输占住，从而在高并发下尾部延迟显著改善。
Suncake 项目的代码规模和安全性如何？
Suncake 包含 11 个 crate，生产代码约 2.26 万行，7 个 smoke example 约 8.4k 行，文档和 ADR 约 4 千行。生产代码中 0 个 unwrap()，expect 仅 3 处，unsafe 约 80 处，全部集中在 FFI/裸内存位置，并配有 SAFETY 注释。
