Fable 将 Pylint 转换为 Rust

原文 ↗ Hacker News 讨论 ↗

项目与核心主张

  • Pylint 的 Rust 重写版旨在实现：
    • 与 Pylint 字节级完全一致的输出。
    • 与 Pylint 相同的 bug 和崩溃信息。
    • 在真实代码库上获得非常大的速度提升（15–2300×，中位数约 85×）。

验证与正确性

  • 几位评论者怀疑，真正做到逐字节一致在现实中是否可验证。
  • 仓库中的一个 harness 脚本会在选定项目上测试 prylint 与 Pylint，但有人指出：
    • 测试只能覆盖已观察到的行为，不能覆盖所有边缘情况。
    • 即使在测试中行为完全一致，也不能保证全局行为一致，尤其是在插件存在的情况下。
  • 有人认为“相同的崩溃、相同的 bug”这一说法，像是自动复制而不是谨慎设计的迹象。

性能讨论

  • 头条所称的 2328× 加速来自 Black 仓库中一个涉及 duplicate-code 的病理性目录；这一问题后来在 Pylint 本身中也被优化了。
  • 有人认为，这种巨大的加速很可能反映了修复算法病理性问题，而这些问题在 Python 中也本可以被修复。
  • 另一些人回应说，重大提速往往来自消除不必要的工作，而编译器/代码检查器充满这类机会。

与 Ruff 和 Pylint 的比较

  • 多条评论都问：“为什么不直接用 Ruff？”
    • 反驳观点：
      • Ruff 目前还没有覆盖所有 Pylint 检查；许多项目会同时运行多个 linter。
      • Pylint 仍然提供更深入或不同的检查，在更严格的环境中很重要。
  • Prylint 似乎在内部复用了 Ruff 的代码，这被一些人批评为把现有工作重新包装了一遍。

信任、维护与社区

  • 人们担心：
    • 该项目很大程度上是 LLM 生成的，而几乎没有人类所有者。
    • 长期维护能力存疑，因为许多过去“AI 移植”的项目很快就停滞了。
    • 在生产代码上运行未经验证的自动生成工具存在风险。
  • 也有人认为，只有正确性和测试重要；创建方式是次要的。

开发者体验与工作流

  • 很多人觉得当前的 Pylint 对大型代码库或 pre-commit hooks 来说太慢；即使每个文件约 2 秒，也被认为会严重影响交互式工作。
  • 更快、基于 Rust 的工具很有吸引力，尤其适用于 CI，以及避免使用其他 Python 解释器。

LLM 辅助代码转换与更广泛的影响

  • 多位参与者描述了类似的 LLM 驱动移植（例如将 Python 工具和 C 库迁移到其他语言），使用 agent “swarm”、自动化编译/测试/修复循环以及 fuzzing。
  • 有人预见：
    • 系统性地进行语言到语言迁移会成为 LLM 的一个强项。
    • 开源项目会承受压力，因为 AI 让克隆和重写变得廉价。
    • 程序员价值会从手写代码转向系统设计和验证。