Will Crichton：让 Rust 更容易理解

Brown University 助理教授 Will Crichton 介绍了他多年来关于如何让新手和专家都能使用 Rust 的研究。他认为 Rust 将系统编程中高效、可预测的资源使用，与函数式编程中富有表现力的抽象和正确性结合起来。

Crichton 重视 Rust，因为关键基础设施长期依赖 C 和 C++ 等系统语言，而它们的复杂性使大规模代码的内存和线程安全难以保障。他也不喜欢一种神话：认为系统编程只属于少数能力特别出众的人。

Rust 依然很复杂：学习者可能既要理解指针和内存布局，也要理解高阶函数和代数数据类型等概念。调查和研究表明，复杂性是采用 Rust 的主要障碍。他的目标不是削弱语言能力，而是帮助人们学习它并在复杂代码库中有效工作。

Crichton 希望开发工具以人为中心的设计和认知理论为基础，并通过真实结果检验。他介绍了三个开源项目：面向学习者的所有权可视化、trait 调试和用于理解复杂代码的程序切片。

他从内存安全讲起。在一个 C++ 示例中，指针指向向量中的一个元素。添加另一个元素导致向量重新分配内存，使该指针指向无效内存；解引用它可能读到无效数据。

等价的 Rust 程序会在编译时被拒绝。指向该元素的不可变或共享引用，与向向量 push 所需的可变、独占借用发生冲突。所有权和借用是 Rust 安全保障的核心，但开发者经常认为它们难以学习。

研究人员提出，若将所有权教成一串不断增加的禁令，学习者就容易形成过于零散的心智模型。他们希望建立一个建设性模型，让人们逐行推理编译器追踪的状态，也能用来理解成功编译的程序。

他们的权限模型为变量赋予读取、写入和所有权权限。初始化向量会授予全部三种权限。创建不可变引用需要读取权限，并在引用的活跃生命周期内移除向量的写入和所有权权限；引用及通过它访问的数据各自拥有不同的权限。

引用不再使用后，向量重新获得写入和所有权权限，因而可以在后面执行 push。可视化工具让这些原本不可见的变化显现出来。团队将该模型形式化为借用检查器的扩展，并构建 Aquascope 自动生成图示。

Crichton 将 Aquascope 与主要关注生命周期线的图示作对比。团队的研究促使他们强调借用如何改变权限、权限如何附着在变量上，以及如何扩展到字段。这种差异源于对学习者困难所在的不同假设。

为调查这一问题，研究人员从 Stack Overflow 收集常见的所有权问题，要求 36 位 Rust 开发者推理其中的代码。参与者常常无法解释编译器阻止了什么内存安全问题，或者在编译器拒绝有效程序时认为自己错了。

团队将编译时权限图与展示抽象运行时栈和堆状态的工具结合起来，并把两者嵌入 Rust Book 分支中改写的所有权章节。Crichton 说，仅有可视化并不构成完整的教学方法。

公开的书中包含源自早期研究的选择题。阅读新章节的读者平均得分比阅读原章节的读者高 9 个百分点。Crichton 将其称为学习效果改善的有限初步证据，并表示三年间约有 15 万人使用过这本书。

他认为，以人为中心的编程科学应从观察到的困难出发，评估的内容也应超出用户是否表示喜欢某个工具。关键问题是工具能否改善诸如正确回答问题这样的结果。

第二个项目 Argus 帮助开发者理解 trait 错误。Crichton 用简化的 ToString 示例介绍 trait：trait 规定一个函数，某个类型可以实现它，而泛型实现也可以要求其组成类型实现该 trait。

一个泛型打印函数要求每个元素实现该 trait。编译器的 trait 求解器会检查类型对的实现，再检查其组成类型的要求。如果其中一个组成类型缺少实现，诊断信息就会指出失败的约束并提供上下文。

好的诊断会尝试指出问题、提供上下文并建议修复方式。但即使是很小的例子，错误信息也可能超过一屏。一个 Diesel SQL 示例捕获了错误的表插入操作，却产生了极长的诊断信息，其中还提示完整类型名已写入文件。

Crichton 将这视为信息可视化问题。Argus 从编译器提取 trait 推断树，让开发者以交互方式探索，按需显示细节。自顶向下视图从原始约束开始追踪要求；自底向上视图则从失败的叶节点开始。

他演示了一个 Bevy 游戏框架示例，其中开发者忘记为资源添加必要的包装。编译器捕获了无效系统，但难以从多个可能的实现中选出开发者原本想要的那个，因此给出又长又不够有用的错误。

Argus 的自底向上视图列出可能的失败原因，包括问题类型缺少 SystemParam 实现。用户可以检查其他失败项、悬停查看限定路径、跳转到定义，或沿自顶向下的推断继续探索。目标是在不一次显示所有信息的情况下暴露有用细节。

一项用户研究发现，使用 Argus 的开发者定位 trait 错误原因的速度约为只使用编译器诊断信息时的三倍。Crichton 表示，库开发者的早期反馈令人鼓舞，这款免费开源工具可与 VS Code 集成。

第三个项目是程序切片。当开发者试图理解复杂函数的某一部分时，可能希望过滤掉与某个值无关的代码。Crichton 演示了一个 URL 解析器：选择 path 变量后，工具淡化不能影响它的代码，并突出显示可能影响它的代码。

切片既可以显示影响所选值的较早代码，也可以显示该值可能影响的后续代码。在示例中，它还让人注意到对 path 的一次意外修改。Crichton 说，研究参与者很快理解了这种交互，而工具移除后他们会想念它。

切片依赖于对别名和修改的理解。在他的 Python 示例中，把列表中的字符串赋给变量并向该变量追加内容，不会更新列表元素；直接修改元素则会。切片工具必须理解哪些值可能引用同一数据，以及哪些操作会改变它们。

黑盒函数让静态分析更加困难：函数定义可能无法获取，因为它用另一种语言编写、位于闭源库中，或来自高阶调用。挑战在于穿过这些调用计算切片，找出真实依赖，同时避免引入虚假的依赖。

Rust 的所有权类型提供了额外信息。在一个向量示例中，get_mut 返回指向元素的可变引用；修改该引用会影响向量。签名中共享的生命周期帮助分析推断可能存在的别名，而可变引用表明可能发生修改，无须检查函数体。

Crichton 区分了可靠性与精确度：前者指找到真实依赖，后者指报告的依赖确实存在。团队证明了其形式化安全 Rust 子集上的可靠性，但内部可变性等特性可能让工具遗漏依赖。在这些情况下，它可能淡化本应保留可见的代码。

为估计精确度，研究人员在 40 万行真实 Rust 代码上，将模块化分析与允许检查函数定义的版本进行比较。在这项比较中，两者有 94% 的情况给出相同答案；例如，可变引用通常确实对应一次修改。

谈到 AI 智能体，Crichton 更愿意思考如何增强程序员，而不只是替代他们。只要人仍有自主权、需要理解软件，工具就必须以适合人类认知的方式传达程序行为。

他认为编程语言理论能够帮助构建可靠性有精确定义的工具，包括明确知道它们在哪些情况下成功或失败。他也认为学习者工具值得重视，即使所有权图这样的可视化无法扩展到数百行代码。

可能的误解远多于正确心智模型。Crichton 希望出现能够建模这些误解、并在具体上下文中提供信息的工具，与通常面向专家设计的调试和可视化工具并行发展。

一位听众询问异步 Rust，尤其是异步 trait 与生命周期之间的交互。Crichton 说，他引用的调查显示，异步已经超过所有权成为最难的话题。团队已开始研究异步系统的用途，以及各种机制如何与取消操作等目标联系起来。

例如，不同运行时对父函数返回时已生成任务的处理方式不同：任务可能继续运行、被取消，或者被等待完成。Crichton 希望梳理 Rust、Swift、Kotlin 等系统的设计空间，让学习者知道应该提出哪些问题。

谈到动态语言和渐进类型时，Crichton 指出学术理论与 TypeScript 等实用系统之间存在差距。承受交付压力的开发者可以用 Any 绕过类型检查，可能逐渐积累技术债；严格系统则可能减缓功能交付速度。

他希望获得更好的证据，理解类型系统设计、开发者生产力与实际缺陷之间的关系。这些问题很难在受控条件下研究，但他认为它们是重要的未来研究方向，而非已经定论的争议。

被问及这些工具能否帮助 AI 智能体时，他建议可以用文本暴露 trait 推断树等编译器内部信息，供模型使用。反过来，助手也可以用更丰富的图示和实验向人解释概念，而不只依赖文本和代码片段。

一位听众问，如何帮助人们摆脱每当 Rust 借用检查器报错就克隆数据等变通做法。Crichton 举例说，开发者可能克隆一个对象并修改副本，然后丢弃它，使原对象保持不变。因此，变通方法可能改变程序的预期行为。

他认为尽早教授所有权很有价值，因为它贯穿 Rust。设计一门更简单、能逐步过渡到所有权的语言可能有用，但很难定义：例如，通过 drop 确定性地释放互斥锁，并不能直接转化为垃圾回收。他对定义更清晰的渐进方法感兴趣。

最后，有人问 Crichton 哪些语言工具能帮助可视化研究人员。他批评广泛使用的 VS Code 在代码叠加显示方面的限制，并将其与更灵活的 CodeMirror 对比。Argus 可以使用单独的面板，切片工具可以淡化代码，但更丰富的可视化往往需要维护成本高昂的编辑器分支。

他呼吁建立一个更易扩展的平台来支持可视化和代码装饰，让研究人员能够分发工具，也让开发者不必维护彼此不兼容的独立编辑器。他感谢听众，结束了演讲。