在基础系统中采用 Rust 的理由

范围：FreeBSD 中“基础系统”的含义

• 包括内核、libc（与内核紧密相关）、核心工具、dtrace，以及构建 base 所需的编译器。
• 作为一个单一的整体（通过二进制补丁）交付和更新，区别于“ports”和第三方软件包。
• 项目文化整体倾向于精简的 base；Perl 之类的语言已被移除；LLVM 工具链如今是主要的“臃肿部分”。

在基础系统中引入 Rust 的动机

• 希望 FreeBSD 能有稳定的 Rust 目标平台，并更好地集成系统工具（例如 jails、ZFS 管理）。
• 核心开发者能够接触到 FreeBSD 特定的 Rust 代码，被视为有价值的指导来源。
• 更容易创建捆绑基于 Rust 的管理实用工具的自定义 ISO。
• 有人希望 Rust 在 base 中取代 C++，并将 OpenSSL 移出到 ports，改用 Rust 的 TLS 库为诸如 fetch 之类的工具提供支持。

Rust 与 C/C++：安全性和语言特性

• 通过所有权/借用机制和借用检查器，对内存安全和数据竞争提供更强的静态保证。
• 破坏性移动，以及对“被借用”与“已拥有”对象的清晰处理，避免了许多 use-after-free 和迭代器失效错误，而这些在 C/C++ 中往往留给运行时或未定义行为处理。
• 现代工具链（Cargo）、更丰富的标准库概念，以及高级类型/迭代器/单子式模式受到称赞；同时也承认学习曲线陡峭。
• 关于这与 C++ 中的 RAII 到底有多大差异存在争论，但普遍共识是 Rust 让生命周期和并发方面的错误难得多。

平台和工具链方面的担忧

• Rust 的一级支持范围较窄；FreeBSD 支持更多架构，不过该列表正在缩减。
• 人们怀疑 FreeBSD 是否有资源或兴趣将 FreeBSD 目标平台推进到 Rust 一级支持。
• 建议：对长期尾部平台使用 GCC Rust 前端或生成 C 的编译器（例如 mrustc），但其实用性受到质疑。
• 有人认为无法跟上现代工具链的旧架构早已在“借来的时间”里运行；也有人认为 BSD 才是这类硬件的最后阵地。

构建、体积和集成问题

• 担心如果把 Rust 放进 base，会让已经很重的 LLVM 中心构建时间翻倍。
• 讨论在 buildworld 之后为依赖 Rust 的组件增加一个额外构建阶段，和/或将工具链与 world 解耦。
• 在保持 base 最小化与深度集成 Rust 之间存在张力。

安全性、可靠性和测试

• 多条评论将 60–70% 的严重漏洞归因于内存不安全，并将 Rust 视为部分补救。
• 也有人强调，大规模攻击大多仍是“基础”问题，而 Rust 并不能解决所有安全问题。
• 争论语言选择与测试/QA 纪律究竟哪个更重要；几位评论者认为语言保证能直接降低测试负担并减少某些类别的 bug。
• 也有人担心内核/低层 Rust 仍会充满 unsafe 并增加复杂性，从而削弱在安全 OS 核心中被珍视的简洁性。

Mocking、测试策略和开发者体验

• 例子：一个 FUSE 文件系统测试套件使用大量 mocking，被认为在 C 中实际上几乎不可行，但在 C++/Rust 中可管理。
• 反对意见是，不管语言如何，mocking 本身往往就是一种糟糕的测试策略。
• 总体上对 Rust 的工具链和测试基础设施评价很高，不过在 Rust 中使用 mocking 也并非普遍受欢迎。

生态、理念和社区影响

• 对比：FreeBSD/Go 被视为保守且稳定；Linux/Rust 被视为快速变化且灵活。
• 一些人担心 base 中引入 Rust 会造成分裂并带来不稳定，类比为一种“emacs vs vi”式的分歧。
• 也有人认为选择性引入（非内核组件、新守护进程）是一条合理路径，不会立刻取代 C，但会扩展可选项。