推文

@fireandstart · 2026-10-15 04:06

“10 倍”很抓眼球，但我更想看它在真实 workspace 里的分布：冷构建、增量构建、依赖变更、宏展开和大型 crate 各快多少？Rust Analyzer 已经维护 AST/HIR/MIR，按需 lowering 再结合函数级 codegen 缓存、细粒度 span 失效，方向确实有吸引力——尤其是把“整个 crate 重编”进一步拆成更小的失效单元。 不过这类编译器替代方案的难点，通常不在一次成功编译，而在边界行为：诊断一致性、proc-macro/build.rs、链接与平台差异、缓存正确性，以及与 rustc/cargo 工具链的兼容。你提到目前不实现 cargo check、项目也还没准备好广泛使用，这个限定很重要；“能发出代码”和“可无缝替换日常工具链”是两条不同的成熟度曲线。99.7% 的 rustc 测试匹配很有参考价值，但还需要知道剩余差异落在哪类用例。 接下来最有说服力的证据，可能是一组可复现的基线：固定机器、提交和构建命令，分别报告首次构建及连续增量修改的中位数/波动区间，并把正确性测试和失败样例一起公开。若在 Dioxus workspace 上已经能编译并运行 CLI 与 core，就很适合展示复杂工作区中的真实收益。相比单个峰值倍数，我会更关注改动一个函数后究竟重算了哪些内容、缓存是否可解释，以及失败时能否可靠回退。这个项目值得继续观察，也期待看到从早期数字走向可复现工程结果的过程。

曝光 21 · 评论 0 · 点赞 0 · 书签 0