主要观点：

• C 多年来是计算界的“通用语”，Rust 理论上可实现语言互操作性但有障碍，构建流畅语言互操作应是 Rust 目标。
• 语言互操作用例分为“最小公分母”（LCD）和“深度互操作”，LCD 主要是单向调用 Rust，需处理简单类型、回调等，还需解决打包上传等问题；深度互操作用于特定语言深度调用，现有 crate 多支持双向交互。
• 与所有语言互操作很重要，C 和 C++尤其关键，目前 Rust 与 C 互操作性尚可，与 C++是大问题。
• 应采取“可扩展编译器”路径实现互操作，将过程宏更深入集成到编译器，以解决现有过程宏的限制。
• 不需要 Rust 传教任务组，应专注于让 Rust 与其他语言良好配合。

关键信息：

• 构建“可扩展编译器”可让 crate 作者创建 Rust 与其他语言的桥接，如投资于“可扩展编译器”可实现丝绸般流畅的语言互操作。
• LCD 用例要求从简单类型快速满足生成更符合语言习惯的包装器等需求，还需解决打包、下载大小等问题。
• 类似“serde”的工具可定义通用 API 并交由后端处理具体语言工作，语言特定细节在 crates.io 上。
• 深度互操作用于在特定语言中深入调用，现有 crate 多支持双向交互，如 cxx 是混合模式。
• 可扩展编译器可让宏更深入地检查类型、生成按需代码等，需控制稳定化表面积。

重要细节：

• 文中提到 uniffi、diplomat 等支持 LCD 用例的库，bindgen、duchess 等专注于深度互操作用例的 crate，以及 pyo3、npapi-rs、neon 等双向交互的 crate。
• 提到 Cxx 以特定方式支持双向 Rust-C++互操，是 LCD 和深度互操的混合。
• 指出 Rust 增量编译系统适合“可扩展编译器”愿景，过程宏可作为函数执行并记录程序状态变化。
• 提及“diagnostics 工具属性命名空间”等很酷的东西，还推荐了[Rust vs Go，“Why they’re better together”]这篇文章。