2026-06-04
作者以 std::function 被新标准组件取代为例，揭示了 C++ 标准库中大量功能（如 std::auto_ptr、GC 接口等）被正式废弃或重写的现状。文章将这些“撤回”行为分为正式废弃、非正式规避以及因 ABI 限制无法修复的缺陷三个层级。特别提到 C++ 标准库容器在极端负载下的 P99 延迟远高于 Rust，根源在于为了维持 ABI 兼容而无法优化的陈旧设计。
社区讨论普遍对 C++ 标准库的沉重负担表示反思，对比了 Rust 相对稳定且现代的演进历程。核心观点认为 C++ 的编译慢和安全性差很大程度上源于标准库的头文件膨胀和设计缺陷，而非语言本身。同时，讨论也指出由于缺乏破坏性移动和生命周期标注等底层特性，C++ 很难在不破坏兼容性的前提下实现同等安全的 API。
Jujutsu v0.42.0 正式发布，核心改进包括 jj git fetch 现在能根据 Change ID 生成演进历史，使本地修订版能自动变基到远程重写的父级。性能上，该版本切换到了 mimalloc 内存分配器以提升多线程效率。此外，新版本增强了 Shell 补全对自定义别名的支持，并允许 jj show 同时查看多个修订版。
社区讨论主要集中在 Change ID 的演进机制，用户普遍认为这能简化 fetch 后的操作流程，但也讨论了 GitHub 等平台对这些元数据的保留情况。部分用户对切换到 mimalloc 的必要性表示好奇，认为 jj 本身运行极快，但最终认可了“更快即更好”的优化方向。
作者针对 Charity Majors 关于“不读代码发布”的设想提出异议，指出代码审查的本质是分散责任风险，避免个人承担系统崩溃或安全漏洞的全部压力。他强调审查是团队成员熟悉代码库、降低“公交系数”以及传承工程文化的重要途径。作者认为，若被要求在不阅读的情况下批准代码，应要求发起者提供书面的免责声明以保障自身安全。
讨论呈现多元观点。部分用户支持作者，认为阅读代码能建立团队所有权，防止因开发者不在场而无法维护；另有观点认为在拥有形式化证明和自动化基准测试的理想未来，逐行阅读可能被更高效的验证取代；还有评论者激烈反驳“分担责任”论点，坚持认为开发者应对自己的代码负专业责任。