moonbit 使用体验

前段时间（2025年9月），我在业余时间开始使用 moonbit port luv-sic 仓库里写的一些代码，比在之上进行进一步的功能开发。陆陆续续花了大概有三到四周，整体感觉不是很好，在此先抛出结论， moonbit 不适合前端领域的程序员使用

原因

写 moonbit 主要是我实在是厌烦前端工具链的破碎、分散，每一次起新项目我都头大，希望用一用这种统一工具链的现代语言来开发，丰满我的武器库，外加我相信国人的技术力，觉得是一个值得投资的项目

过程

我这次的编写任务为用 moonbit 开发 cli 工具，但 moonbit 的 low level 和各方面的安全处理都让我的开发举步维艰，任何一次简单的数据读写都得做类型转换和错误处理，繁琐的操作无时无刻不在打断本应流畅的编写思维，而其所谓安全性保障于我而言只是一个谎言，我在不停的欺骗编译器我的每个步骤都非常安全，只因我的预期场景是出错崩了就行。或许对 Rust 程序员这都是非常熟悉的内容，但我是一名 TS 程序员，我很自由，我不需要关注这些细节，所以我开发的很痛苦。我觉得想要使用 moonbit 进行业务开发，就得基于社区提供的框架实现，否则我们这种其他领域的程序员会不断冲撞、妥协，最终落下一地鸡毛

moonbit 支持的 trait 特性是一直在我脑海里游走的概念，多年以前在我学习 rust 的时候觉得 trait 是个很好的功能，它能支持方法为数据结构复用，但开发了多年 TS 以及强迫自己真正用 trait 写代码之后，我觉得在 DX 维度这个特性实现的不好用

hongbo 说过不会支持 algebraic effects，我想这是一个巨大的战略失误。我很享受用 moonbit 写 test，写完一个功能直接在下一行开始写 test，最终一个命令启动测试的感觉让我很舒服，如果有 AE，那么就能在执行入口区分出 test 和 real, 让代码更加干净，而不是在里面编写 if env === 'test' 这种恶心的东西

moonbit 整体追求简单，所以我能很快的忽略掉技术细节，查看、学习社区代码，这倒是一件好事情。因为 moonbit 的文档差了，看文档不如看代码。有趣的是，此事也同样发生在 nix 社区，哈哈

未来

从人的角度来看，我不是 moonbit 的目标用户，我用得不爽，那么从 AI 的角度呢？

moonbit 现在以 AI 为卖点，宣称能用 moonbit 的一体化工具链 + 定制 AI 适配能够让 AI 直接 port 其他语言的 lib 到 moonbit。我在入坑后也的确发现他们每周都在定量 port，效率确实高，测试也都能通过，但质量就不好说，至少他们的 async 库还是手写的

不过我相信的是语言 + AI 这件事情一定可行，就看 moonbit 怎么捣鼓出来真正能用的东西了