这篇文章讨论了在Rust中实现双向链表等循环引用数据结构的挑战。作者认为双向链表虽然教学演示中常用，但并不适合现代硬件，实际应用场景有限。这个问题实际上代表了所有涉及循环引用的数据结构（如编译器模块、游戏对象或图形）在Rust中的实现难题。文章暗示需要寻找更现代的解决方案来处理这类问题。

Rust中的内存竞技场管理

核心争议

在程序员群体中，"如何用Rust实现双向链表"这个问题总能引发激烈争论。这个问题表面看似不公平——毕竟现代硬件架构中双向链表已非优选方案（Linux内核使用它更多是历史遗留问题）。但实质上，它代表了所有涉及循环引用的数据结构面临的共同挑战，比如编译器模块互引用、游戏对象容器关系或GUI组件层级等场景。

Rust的内存管理哲学

Rust通过类型系统将C++的所有权/RAII模式制度化，以此确保内存安全。但循环引用会破坏类型系统对所有权关系的追踪能力。对此，开发者可以采用"竞技场（arena）"模式：预先分配对象数组，通过整数句柄（handle）而非指针进行引用。这本质上是在硬件指针机制之上重建了一套地址空间系统。

安全优势

虽然这种模式看似回归了手动内存管理，但与C语言相比具有关键优势： 1. 确定性：句柄错误会稳定复现，不会出现传统内存错误因地址空间随机化（ASLR）导致的不可预测崩溃 2. 安全性边界： - 竞技场受数组边界检查保护，攻击者无法通过句柄漏洞实现任意内存覆盖 - 最多导致服务拒绝（DoS），极难形成远程代码执行（RCE）漏洞 - 这对浏览器等安全敏感程序尤为重要（注：Rust正是由浏览器厂商Mozilla创建）

现代软件的现实

当今除了个人脚本工具，绝大多数软件（包括嵌入式设备）都需要应对潜在的攻击输入。竞技场模式虽然牺牲了部分自动化管理能力，但保留了Rust最核心的安全特性——这正是推动开发者从C++转向Rust的根本动力。

（配图说明：原文中的金属建筑空场景图未直接关联技术内容，故在改写中省略）

以下是评论内容的总结：

1. 关于Arena内存管理的争议

• 支持观点：Arena分配能减少内存碎片，通过索引（handles）提供比指针更安全的访问方式，且能避免"use after free"等问题。

  • 引用："Even though it seems like 'giving up' and going back to C, it's still way better." (IshKebab)
  • 引用："Handles are deterministic... handle bugs won't allow an attacker to overwrite arbitrary memory" (mwkaufma引用的支持观点)

• 反对观点：Arena仍存在越界访问相邻数据的风险，且可能丧失Rust的内存安全优势。

  • 引用："Just because you're in-bounds of the arena, doesn't mean you're not stomping on in-bounds neighboring data" (mwkaufma)
  • 引用："The more generally you use 'arenas' the more they are subject to the same kinds of issues as other manual memory management systems" (jmull)

2. 双向链表的使用争议

• 批评观点：双向链表是过时的数据结构，现代硬件上效率低下，仅因教学需求保留。

  • 引用："doubly linked lists are approximately useless and never used" (IshKebab)
  • 引用："The last time I used one was in the nineties" (wasmperson引用原文)

• 辩护观点：在需要侵入式数据结构、低分配开销的场景（如内核开发）中仍有价值。

  • 引用："a doubly linked list is what you reach for when you're looking for an intrusive data structure with fast append and fast delete" (prngl)
  • 引用："the Linux kernel uses them... to minimize allocations" (prngl)

3. Rust语言设计的讨论

• 改进建议：

  • 应原生支持循环引用解决方案（Someone）
  • 急需稳定自定义分配器API（lenkite）
  • 建议通过Cargo限制unsafe代码等特性（echelon）

• 文化争议：

  • Rust的学习曲线和约束可能限制开发者群体（procaryote）
  • Rust属于"C++阵营"，难以吸引坚持C风格的开发者（prngl）

4. 早期绑定与晚期绑定的权衡

• 早期绑定（如Arena）更易调试但灵活性低，晚期绑定反之（crq-yml）
• Rust允许"简单粗暴"的解决方案，但未将其设为默认（crq-yml）

5. 其他

• 对Linux内核是否测试替代链表结构的疑问（asplake）
• 调侃性评论："I think I will love FORTRAN again" (oflebbe)

（注：所有评论均无评分数据，故未体现认可度差异）