FujoOS / Loment 开发访谈 · 第一弹

因为痛点不在 Rust。立项时列了十个具体的痛点，其中七个是同一件事：同一个接口被 N 种语言各写一遍。同一个操作码表躺在 spec.json、内核的 syscall.rs 和另一个实现的头文件里；同一个 64 字节节点布局写在打包器、内核常量和新文档三处。

换掉内核语言不解决这个，只会让 N 变成 N+1。真正缺的是一个接口层：平台定义“怎么在它上面写东西”，语言只是外壳。Windows 就是这么做的——先有稳定的接口面，再让语言和工具去消费它。

两层意思，都指向同一件事：不依赖宿主。

内核里自带一套工具链——汇编器、链接器、C 子集编译器，全链产出 ELF64。它已经构建并运行过自己的 hello。这不是演示：如果内核里的东西必须靠宿主上的工具链才能编译，那这个系统就还没站起来。

Loment 走到了同一层：编译器能编译自身，三阶段产物的 IR 逐字节相同（1002385 B）。也就是说，Loment 的编译器已经是一段能独立跑的 ELF，可以编译自己的单元，再用自己的产物链一次，结果还是逐字节相同。

所以「FujoOS 上跑一个 Loment 程序」，不需要你先在自己机器上装一套交叉工具链。

这是这个项目第一次有了「母语」。

在此之前，FUAI 的能力域是内核里的一组机制——用 C 或者别的语言手写去调用它。有了 Loment，能力域变成语法的一部分：capability 声明、guard 语句、编译期边界检查、运行期 trap、审计计数。同一条声明，既生成运行期的域表，也生成内核读得懂的形式对象。

区别在这里：内核第一次能「读懂」一段程序被允许做什么，而不是只能相信它说自己要做什么。这是整条 FUAI 主张能不能落地的地方。

能跑通，但还没发布——这两件事要分开说。

能跑的：写、转译、编译、运行、导出形式对象，端到端闭环；25 个示例；系统调用层 46/46 覆盖；工具链齐了——格式化器、语言服务、包管理器、文档生成器、DWARF 语句级行表，增量构建从冷 82.6 ms 到热 9.0 ms。

没发布的：100 个里程碑完成 87 个（另有 8 项部分完成），0.1.4 Alpha2 已经完成（冻结面见 docs/158），但发布与外部审计还没过。上手文档我们写了，标的是 Beta，就是这个意思。

三件，按依赖排。

一、把自举收尾，然后去 Python 化。自举本身已经相当完整：parser 全语料 42/42 逐字符一致，检查器规则等价 63/63，而且现在能不用任何解释器把自己重建出来——起点是一份固化的种子，clang 加 sh 就够。剩下的是工具链上那三个还没重写的（文档生成、语言服务、包管理），格式化器已经改完且与 Python 版逐字节相同。

二、内核侧接入。A1–A4 的运行时断言、能力域与内核域模型对齐、撤销语义由内核真正实施。现在那张断言表还停在产物层，没有进内核。

三、网络。让 Loment 的第一个真应用是网络，而不是又一个玩具样例——它同时提供字节级的精确契约和能力边界，是这门语言最合适的压力面。

面向开发者的第一个版本，计划 9.20。