Scarf已弃用Haskell

# 经历7年生产环境后，Scarf 不得不忍痛告别 Haskell 来源：https://avi.press/posts/2026-07-10-after-7-years-in-production-scarf-has-reluctantly-moved-away-from-haskell.html Avi Press (https://avi.press/index.html) | 2026年7月10日 --- ## 免责声明 这篇文章写得很艰难。我几乎放弃了执笔的念头，因为我更愿意建设与推广，而不是批评。但希望这篇文字能对 Haskell 未来的讨论起到建设性作用。我必须强调，我并非从外部批评 Haskell。我足够在乎它，才愿意坦诚说出 Scarf (https://about.scarf.sh/) 为何不得不离开它，希望能促使社区认真对待这些反馈。 --- ## 我的经历 过去16年里，我一直是 Haskell 的狂热粉丝。它无疑是我生命中最重要的一门编程语言。学习它让我成为了更优秀的程序员。我为之倡导过、建立了一家以它为基础的公司，并同时担任 Haskell 基金会和 Haskell.org 委员会的成员。 对于 Haskell 需要改进的地方，我也一向坦诚。 自从 Scarf 上线以来，我们的后端一直用 Haskell 构建。驱动应用的主 API 使用了 Servant、Beam（基于 PostgreSQL）等库。我们还基于 WAI 为 Scarf Gateway 构建了一个高性能的 Haskell 服务，它直接位于大量开源软件包流量的下载路径中。这些系统有真实的运行时间要求、合同约定的 SLA，而我们在生产环境中已经成功运行了多年。 我们让 Haskell 经历了一次严肃的生产环境考验，它的许多承诺都兑现了：代码可靠、类型系统捕获了真实 bug、语言迫使我们认真思考如何建模领域。高性能代码通常也很容易实现。 但代价同样真实。最大的两项是编译时间和生态系统的摩擦。我们花费了大量时间优化构建、缓存、Nix、开发者环境、CI 以及围绕一个严肃 Haskell 代码库所需的所有其他工具链。很长一段时间里，这些是可行的。我们的团队对语言和工具了如指掌，知道哪里是危险边缘，大多情况下也能忍受。 然后，AI 改变了权衡。 LLM 现在非常擅长写代码。它们当然不完美，但已经足够好到改变了软件开发的成本结构。 过去，我认为错误只能在两个地方被捕获：编译时或运行时。现在有了第三个地方：代码生成时。模型常常能在编译器看到代码之前就避免错误。而且随着模型越来越好，编译时捕获每个可能问题的相对价值正在改变。 这并非说类型安全已经变得毫无价值。但类型检查的成本现在重要得多了。如果 LLM 能在几分钟内给出一个可工作的实现，而你的编译步骤却要花上数倍于此的时间，那么你的语言和构建系统就成了开发循环中的瓶颈。 关键指标是：你的整个开发反馈周期需要多久，其中有多少时间花在了等待编译器上？如果人类花一小时写代码，长时间的编译循环虽烦人但尚可容忍。如果 一个AI代理能在几分钟内草拟出一个合理的变更，然后却要花 15 分钟等待项目从冷启动构建完成，那么编译器就从一个小痛点变成了那项工作的主要成本。 当你并行使用多个编码代理时，这种情况就变得难以忍受了。 如果你一次只做一件事，也许你付一次冷构建成本就能继续下去。但越来越多的情况是，我不想那样工作。我想开多个工作树，分叉出不同的工作线，让代理去尝试，审查结果，然后保留有用的东西。在那种世界里，冷启动时间极其重要。如果每个新工作树都需要一次漫长的 Haskell 构建，或者需要仔细的缓存设置，或者消耗大量内存，那么每一项新的工作线都必须先交一笔税。如果我想让五个代理并行探索五个分支，这笔税就会成倍增加。 Haskell 社区里人们经常谈论缓存、Nix、远程构建器等工具。这些工具有帮助。我们也用过。但缓存永远不完美，而为了让它在感受上足够好而付出的努力本身就是问题的一部分。在实践中，并行 AI 辅助开发需要廉价、可随意丢弃的执行环境。我希望能说：分叉这个，尝试变更，运行测试，展示结果。我们的 Haskell 环境对于这种工作风格来说不够便宜。 如果一切都被缓存了，你做一个微小改动，通常能得到非常快的编译。有时循环只需 20 秒，感觉很好。但那是最佳情况，而你不能围绕最佳情况来优化整个系统。你的改动越深入构建计划的核心部分，这种叙事就越不成立。在代理密集的工作流中，你最终会更多地关心冷启动情况、平均情况和更深层改动情况。为了使完美缓存情况可靠发生而投入的工程努力本身也是税的一部分。 这变得越来越痛苦。 --- ## 我们如何迁移 在 Scarf，我们开始将所有新的 API 工作改用 Python。我们部署了一个 Python API 服务器，与 Haskell 的服务器并列，将请求路由到正确的位置，并在接触到现有功能时逐渐将其迁移过去。新的 API 路由进入 Python，现有的 Haskell 代码继续运行，随着时间的推移，新服务器会成为主要路径，而我们的 Haskell 足迹将会缩小。 这种方法让我们在没有突然切换风险的情况下进行迁移。这也意味着我们需要重新实现一些核心功能：认证、数据库访问、共享模型、部署镜像、测试和运维胶水。过去，这种设置工作会显得很昂贵。有了 LLM，它们并不差——将现有代码移植到新语言对于今天的模型来说相当直接。 我们在开发循环中省下的等待和挣扎时间，现在被重新分配用于交付更多功能，同时进行更全面的测试。AI 很擅长写大量测试。你仍然需要盯着它，因为它绝对会写出垃圾和假测试，但循环足够快，这种权衡比我几年前预期的要好得多。 结果很难用单个指标来量化。PR 吞吐量并没有明显上升。提交量是杂乱无章的。代码行数是糟糕的代理。部署数量是模糊的，因为它包括预览、基础设施和其他干扰。但生产力的变化体现在我们现在能用高投入、最少监督甚至完全自动交付的内容形态上。从客户电话 → 提交工单 → 打开 PR → PR 审查和迭代 → 合并 → 部署，我们有时能在结束客户电话之前就让 bug 修复上线。抵制这种生产力已经不再是一个选项。 到目前为止，我们在切换中没有损失太多。我们放弃的类型安全还没有以任何具体方式被注意到，尤其是考虑到我们的测试覆盖率从未如此出色。现在，当 bug 确实出现时，我们可以以前所未有的速度热修复——修复现在只需一条 Slack 消息。我们的工程团队因生产力提升和可利用的全新技术前沿而更加充满活力。我们在过去的开发者工具链上花费的时间显著减少。 --- ## Haskell 生态系统的问题 Haskell 正处于真正的危险之中。 AI 会一直存在。那些善用它的人和生态系统将比不善用者发展得更快。我不再认为这还需要明说。一个熟练的 AI 驱动工程师现在可以在几天内完成过去需要数周甚至数月的工作。 我也想明确我是在什么位置说这些话的。我并非身处 Haskell 世界之外向它扔石头。我通过我在 Haskell 基金会的角色(s)直接参与语言领导工作。我确实有一些能力提供帮助，而且我会继续在力所能及的地方帮忙。同时，我的业余时间严重受到运营 Scarf 的现实限制。我尽力不袖手旁观，但我的能力确实有限，无法单方面改变这些动态。 Haskell 世界里也有许多人看到了相同的经济变化，并希望 Haskell 加快步伐以适应它们。但总体而言，Haskell 工具链和生态系统的进展并未达到我认为需要的程度。 然而，当 AI 在 Haskell 空间中被提及时，对话往往更关注限制而非赋能。我理解人们为何担忧。应该有规范，应该有披露。要求人们说明代码是否由 AI 辅助、使用了哪些模型、如何审查，这是合理的。 但有一个强大的群体持“不要使用 LLM”甚至“我们不希望支持涉及 LLM 的工作流”的立场，我认为这站在了历史的错误一边。我预测这将对语言的生态系统不利。 一个支持 AI 的 Haskell 生态系统会问不同的问题：如何让 Haskell 更容易被 AI代理用好？如何将更多高质量的 Haskell 示例纳入模型训练数据？如何扩展审查？如何让库文档充满可复制粘贴的、现实的示例，而不仅仅是漂亮的类型？如何让项目启动更快？如何让错误消息更友好于 AI代理？如何减少冷构建时间？如何让常见的工业模式对试图帮助的模型来说是显而易见的？ Haskell 本应异常适合 AI 驱动的工程师和代理。如果编译器能帮助代理快速收敛，类型安全对 LLM 生成代码来说可以是一个巨大优势。但这和优化语言给人手写代码不是一回事。代理有不同的瓶颈。它们生成代码很便宜，被阻塞时却很昂贵。它们受益于快速反馈、清晰的示例、低设置摩擦和有助于快速修复代码的错误。 Greg Brockman 关于 Rust 是代理的完美语言、回复中提到 Haskell 的推文截图。(https://x.com/gdb/status/2007228511363444905) 如果 Haskell 想在 AI 时代表现出色，它需要刻意优化以适应那个世界。 我希望 Haskell 成长。我希望它变得重要。我希望 Haskell 擅长的东西——正确性、可维护性、组合式设计、原则性抽象——成为下一个软件时代的一部分。 但这些必须成为优先事项。从我目前看到的情况来看，包括 Scarf 自己对开源生态系统趋势的观察，与其他地方正在发生的事情相比，Haskell 的增长充其量只能说是温和的。我目前无法分享所有底层数字，但方向上的故事并不难看到：许多开发者生态系统在 AI 时代正在加速，而 Haskell 感觉并不在其中之一。 这种停滞的机会成本从未如此之高。 答案是让 Haskell 成为它自己最好的版本，以适应我们正在实际进入的世界。这意味着认真对待 AI 作为生态系统的一流用户。这意味着关心构建时间、上手体验、文档、示例、工具、代理工作流和市场推广，胜过关心类型系统研究。这意味着重新分配社区精力，甚至放弃当前的工作领域。这意味着为 Haskell 基金会找到筹集足够资金以资助和协调更多技术工作的途径。 我知道依赖类型之类的新语言特性很有趣，也有它们的用例。但工业界的 Haskell 用户多年来一直在抱怨编译时间和生态系统摩擦。在 AI 时代，这些已经远远超出了单纯的烦扰，变成了与语言生态系统的根本性错位。 在 Scarf，我们碰到了那堵墙。我们仍然尊重 Haskell。我们仍然在生产环境中运行 Haskell。但对于新产品开发，我们已经转向了 Python，因为它让我们能够更快地利用最新的 AI 工具，这些工具彻底改变了我们交付软件的方式和速度。 我希望事情有所不同，但这样的迁移对于我们情况的清晰合理的前进方向。我希望 Haskell 社区以应有的紧迫感来对待这一时刻。