Scarf 公司宣布弃用 Haskell 技术栈

背景

Scarf 是一家为开源软件提供下载分析、网关和商业化基础设施的公司，其后端核心系统基于 Haskell 构建并运作了 7 年。创始人 Avi Press 是一位拥有 16 年经验的 Haskell 忠实拥护者，曾担任 Haskell Foundation 董事会成员和 Haskell.org 委员会成员。在 Scarf 的生产环境中，Haskell 支撑了关键 API（基于 Servant、Beam 和 PostgreSQL）、高性能网关服务（基于 WAI）等高可靠性系统，并成功满足了合同约定的 SLA（服务等级协议）。然而，在 AI 编程能力大幅提升的背景下，Scarf 团队经过权衡，最终决定将新开发工作迁移到 Python，并逐步缩减 Haskell 代码库的规模。

核心内容

对 Haskell 的正面评价

Avi Press 强调，Haskell 是“他生命中最重要的编程语言”，学习它让他成为更好的程序员。在生产环境中，Haskell 确实兑现了许多承诺：代码可靠，类型系统捕获了真实 bug，语言迫使他们认真建模领域逻辑，高性能代码也基本能直接实现。团队对 Haskell 的工具链和生态有深入理解，多年来一直能够应对其挑战。

代价：编译时间与生态摩擦

尽管 Haskell 在类型安全和可靠性上表现优异，但代价同样显著——最突出的是编译时间和生态系统摩擦。团队花费了大量时间优化构建、缓存、Nix、开发者环境、CI 等配套工具。在一段时间内，这些代价是可接受的，因为团队熟悉语言和工具，知道如何避开锋利的边缘。

AI 改变了权衡

LLM 现在非常擅长写代码，虽然不完美，但已经足够好到改变软件开发的“经济学”。传统上，错误只在编译时或运行时被捕获；现在出现了第三个捕获时机：代码生成时。模型在编译器看到代码之前就能避免很多错误。随着模型能力提升，编译时捕获所有问题的相对价值在下降。

关键指标变成了：整个开发反馈循环需要多久？其中等待编译器的时间占比多少？ 如果人类花一小时写代码，漫长的编译只是烦人但可忍受；但如果 AI agent 能在几分钟内生成一个可行的修改，却要花费 15 分钟从冷启动构建项目，那么编译器就从“小痛点”变成了主导成本。

当并行使用多个 coding agent 时，这个问题变得不可忍受。Avi Press 希望同时启动多个工作树（worktree），让不同 agent 尝试不同分支，然后审查结果、保留有用的改动。每个新工作树都需要一次冷构建，如果 Haskell 构建时间很长、缓存设置复杂、内存消耗大，那么每一条新工作线都要交一笔“税”。并行 5 个 agent 探索 5 个分支，这笔税就乘以 5。虽然缓存、Nix、远程构建器等工具有所帮助，但缓存从不完美，让缓存工作“足够好”所需的工程努力本身就是问题的一部分。AI 辅助的并行开发需要低成本、可丢弃的执行上下文，而 Haskell 环境对那种工作模式来说还不够便宜。

迁移方式

Scarf 没有采取一次性大切换，而是采用渐进式迁移：所有新 API 工作开始用 Python 编写，在 Haskell API 旁边部署一个 Python API 服务器，通过路由将请求导向正确服务。现有 Haskell 代码继续运行，随着时间推移，新服务器成为主路径，Haskell 足迹逐渐缩小。这种策略避免了激进切换的风险，但需要重新实现核心组件（认证、数据库访问、共享模型、部署镜像、测试、运维胶水）。过去这种迁移设置工作会很昂贵，但在 LLM 帮助下，将现有代码移植到新语言非常直接。

迁移效果

团队从等待和对抗工具链中节省下来的时间，被重新分配用于交付更多功能并进行更全面的测试。AI 擅长写测试，尽管仍需要人类检查（因为可能会生成垃圾或伪造测试），但反馈循环足够快，效果远超预期。生产率的变化难以用单一指标衡量——PR 吞吐量没有明显上升，提交量有噪音，代码行数不是好代理，部署计数混杂着预览等噪音——但团队能够以更高精度、更少监督、甚至全自动地交付功能。从客户电话 -> 创建 ticket -> PR 打开 -> 审查迭代 -> 合并 -> 部署，有时客户还没挂断电话，bug 修复已经上线。这种生产率提升让人无法拒绝。

Haskell 生态的健康状况

Avi Press 明确指出：Haskell 正处于真正的危险之中。AI 已经到来，使用好 AI 的人和生态会比不用的快得多。一个熟练的 AI 赋能工程师现在可以用几天完成过去几周甚至几个月的工作。他作为 Haskell 生态的核心成员，真诚地希望社区认真对待这些反馈。

关键要点

• 经过 7 年生产验证，Scarf 承认 Haskell 在类型安全、可靠性、高性能方面表现优秀，但编译时间和生态摩擦是持续成本。
• AI（LLM）改变了开发的经济学：代码生成时就能降低错误率，使得编译时类型检查的相对价值下降。
• 在 AI 驱动的并行开发模式（多个 agent 同时工作）下，冷启动编译时间成为主导瓶颈，Haskell 的工具链和缓存策略无法满足“低成本、可丢弃执行上下文”的需求。
• Scarf 的迁移策略是渐进式：新 API 用 Python 实现，与旧 Haskell 服务并存，逐步缩减 Haskell 代码。
• LLM 显著降低了迁移和移植代码的成本，使得切换语言变得可行且高效。
• 迁移后，团队将节省的时间用于更全面的测试和更快的 bug 修复，生产率提升明显，且没有明显损失类型安全性（测试覆盖率达到历史最高）。
• Avi Press 警告 Haskell 生态面临真实威胁：AI 正在让其他语言和工具链的开发速度远超 Haskell，Haskell 社区需要重视这些反馈以避免落后。

意义与影响

1. 对 Haskell 社区的启示：这篇来自生态核心成员的坦诚反思，可能促使 Haskell 社区更重视工具链的现代化（特别是编译速度和缓存效率），否则在 AI 辅助开发的时代，Haskell 可能失去更多用户和项目。

2. 对 AI 与编程语言关系的思考：AI 不仅改变了编写代码的方式，还改变了选择编程语言的权衡标准。传统上对“类型安全”的强调，在 AI 能生成更加正确代码时，其机会成本（编译时间）被放大。未来可能会有更多团队在语言选择上更看重“AI 友好性”和“开发迭代速度”而非纯静态类型优势。

3. 对软件工程实践的启示：Scarf 的迁移案例展示了利用 AI 辅助进行渐进式语言迁移的可行性——AI 可以大大降低重写和移植的成本，使团队能更灵活地适应新的技术栈。

4. 对创业公司技术决策的参考：当生产系统的技术债和工具链摩擦开始阻碍并行 AI 开发时，及时切换到更高效的工具链可能比固守原有技术更符合商业利益。Scarf 的案例表明，即使是在 Haskell 基金会内部有深厚根基的公司，也必须在现实生产力压力下做出艰难选择。