> 选择技术的方式似乎不太妥当。

这是为政府选择技术的一种非常明智的方式。

拥有一个酷炫的概念验证，其关键人物依赖度为1，与拥有一个无数政府机构可以依赖的解决方案(用于数百万美元的数十年软件项目)是完全不同的两件事。

他们不能仅仅因为你个人维护“菲尔的不可思议垃圾收集器”而依赖它，直到政府项目的生命周期结束。也许你认为他们可以，但要向政府提供这样的保证需要付出更多努力。

他们将TRACTOR列在已资助的项目中(关键是，它尚未被列为推荐解决方案)。申请Fil-C的资金，如果获得批准，它也可能会被列在那里。

TRACTOR 方法对实验性项目也有更高的容忍度，因为它是将 C 转换为 Rust 的一次性转换。它只需要工作一次，而不需要连续工作几十年。Rust-lang 组织旨在提供认真的长期支持，早已不再依赖单个开发人员。

有道理。但也许那篇帖子已经四年了，这反而强化了Fil-C的价值主张。尽管人们可能希望摆脱他们的C代码库，但及时完成这一转变所需的资源往往并不容易获得。

说得好，兄弟！ 🙂

嗯，我理解的情况是，目前有许多供应商/提供商/发行版/仓库可以分发您的内存安全构建版本，但目前仍在分发不安全的构建版本？

我好奇像 Tor 项目 [1] 这样的组织是否会更愿意“官方”分发 Fil-C 构建版本，毕竟安全性是他们产品的核心。(我指的是他们的“洋葱路由器”[2]，而非(必然)整个浏览器。)

我设想一旦某些组织开始正式发布Fil-C构建版本，采用率可能会加速。

另外，你是否与Ladybird浏览器团队沟通过？他们似乎对Fil-C表现出兴趣。

[1] https://www.torproject.org/

[2] https://gitlab.torproject.org/tpo/core/tor

> 你创建了一种比 C 语言慢 20-50% 且带有垃圾回收器的语言。这并非人们使用 C 语言的初衷。

谁说的？

大多数用C语言编写的软件并不注重性能。我的shell即使慢4倍我也不在乎。

我使用的绝大多数图形界面软件也是如此，包括浏览器。

> 你有一个更精细的ASAN。

Fil-C和ASAN的区别在于Fil-C是内存安全的，而ASAN不是。

这与“精细”无关。

> 这并没有推翻整个叙述。

叙述是C不是内存安全的语言。这个叙述是错误的。

如果叙述是“C只有在愿意付出性能代价时才是内存安全的”，那随它去吧。但这不是人们所说的

> 对于运行无法修复的遗留 C 代码，已经存在开销更低的解决方案。它们不够精确，但这要么对安全性无关紧要(例如存在正确的沙箱边界)，要么性能至关重要，人们愿意接受不完整的强化措施，尽管存在风险。

不，没有。Fil-C 是 C 代码中唯一的内存安全解决方案。

Hwasan、mte 等都不是内存安全的。Asan 也不是内存安全的(而且可能也不便宜)。不知道你还在考虑什么。

> 已经有了 CHERI，它采用了类似的指针标记方法

Cheri 和 Fil-C 均不使用指针标记。两者均采用指针能力机制。Fil-C 的能力机制更安全(实际上可防止内存释放后使用)。

Fil-C 比 Cheri 更快，因为我可以在高性能通用硬件上运行 Fil-C。在我 x86 系统中，Fil-C 的运行速度比最快的 Cheri 机器快几个数量级

据我所知，Go中的切片并非原子更新，因此其组件可能发生数据竞争，导致潜在的未定义行为(UB)。

值得一提的是，根据我在这里阅读的内容(例如[0])，这种情况尚未在非演示环境中被利用，但谁知道第一个此类漏洞何时会出现。

[0]: https://news.ycombinator.com/item?id=42043939

Tor 希望迁移到 Rust，他们对 C 代码库并不满意。他们希望扩展多线程的使用，而 C 对于此而言过于脆弱。

https://blog.torproject.org/announcing-arti/

你创建了一种比C语言慢20-50%且带有垃圾回收器的语言。

这并非人们使用C语言的初衷。你将其包装成“内存安全的C语言”，但实际上它拥有更精细的ASAN机制。这虽有价值，但并未彻底颠覆现有叙事。

对于运行无法修复的遗留C代码，已经存在开销更低的解决方案。它们不够精确，但这要么对安全性无关紧要(例如存在正确的沙箱边界)，要么性能至关重要，人们愿意接受不完整的强化措施，尽管存在风险。

对于新开发，当较慢的GC语言适用时，已有大量更方便且不易崩溃的语言可供选择。

已经存在采用类似指针标记方法的 CHERI 技术，但他们选择在硬件层面实现，因为他们清楚软件模拟会让解决方案失去吸引力。

Go语言有什么问题？

> 这是政府选择技术的一种非常明智的方式。

不，这不是，因为政府有足够的资源来组建团队重新创建一个类似 Fil-C 的项目，甚至只需为 Fil-C 增加人力。

仅需一名开发者在业余时间花费 1.5 年即可实现 C 语言的内存安全，这表明原帖的论点是错误的。问题不在于人们不使用内存安全语言，而在于没有人资助仅为实现 C 语言的内存安全。