这是对 John Viega 的"C isn't a Hangover; Rust isn't a Hangover Cure"（原始 Medium 链接）的回复。

上下文：作者几个月前阅读了该文章，已在 Twitter（有时称为 X）上做出回应，认为平台不适合长篇评论，所以希望写一篇更有条理、易理解且更好的回应。John 的文章探讨了使用 Rust 的一些担忧，包括是否是正确选择、内存安全重要性、适合团队的语言以及依赖使用等方面。

关于依赖被视为不安全的观点：

• John 认为代码审查比写代码更难，依赖来自任何人且可能被贡献，越多依赖信任圈越大，易成为单点故障，应只信任自己写的代码。作者不同意，认为对于技术上不复杂的代码，代码审查错过的可能只是导致 DoS 的小错误；对于避免未来的妥协，可以使用不删除撤回依赖的包服务、提交锁文件、供应商依赖等方式。
• John 认为 Rust 容易引入外部依赖，导致依赖管理困难，核心 Rust 库也大量使用第三方依赖，而 C 更安全，因为 C 标准库不广泛。作者强烈反对，认为在 C++中也需要注意内存安全问题，且在 C/C++中管理依赖的体验糟糕，Rust 有很多工具可用于监控和管理依赖。
• John 认为用 C 编写代码更能保证安全性，而 Rust 依赖管理困难。作者认为用 C 编写代码也有隐藏的问题，如常见数据结构可能有 bug，而 Rust 使依赖管理更方便，不应因依赖管理困难而放弃使用依赖。

关于 Rust“电池不自带”的观点：

• John 认为像 Go 和 Python 有广泛的标准库且语言维护者负责更好，Rust 应负责标准库。作者同意有电池自带更简单，但 Rust 从其他语言的错误中吸取教训，不将不合适的东西放入标准库，且标准库的 API 相对固定，而 Rust 语言在不断变化，稳定 API 更改可能影响兼容性。

关于其他语言的包管理：

• Python 和 Go 的包管理存在问题，如 Python 的 pip 依赖默认全局导致冲突、版本冲突问题、原生依赖神秘、缺乏强锁文件等；Go 早期依赖管理混乱，没有锁文件、版本等，后来有了改进。而 Rust 的 Cargo 包管理器从一开始就设计良好，相比其他语言更优秀。

关于依赖爆炸的例子：

• 作者以一个 Xbox 360 特定文件系统的 CLI 应用为例，展示其Cargo.toml中的 10 个直接依赖最终导致 102 个依赖，通过cargo deps-list和cargo depgraph展示依赖图。
• 作者介绍了自己的“嗅探测试”流程，包括搜索相关主题、查看 crates.io 页面、检查使用统计、版本、依赖者等，以判断依赖的可靠性。
• 作者认为虽然有些依赖可能不是严格必要的，但使用它们可以提高应用的整体质量和开发体验，避免花费时间在简单的功能实现上。同时也提到要警惕依赖膨胀，判断依赖的合理性。
• 作者认为不应过于担心依赖带来的安全风险，而应根据个人或团队的需求选择最方便的方式。

总结：作者认为 Rust 在依赖管理方面具有优势，虽然依赖可能带来一些问题，但通过合适的方式可以管理和降低风险。相比之下，C 在依赖管理方面的劣势明显，不应因依赖问题而选择 C 而放弃 Rust。同时，作者也强调要根据实际情况权衡各种因素，选择最适合的方式来完成工程任务。