2026 年 7 月 10 日，Avi Press 发表了一篇让 Haskell 社区难以平静的文章：他创立的软件分析公司 Scarf 在将 Haskell 用于生产环境七年后，决定逐步迁移到 Python。这篇文章在 Hacker News 上获得了 147 分和 189 条评论，在 Lobsters 上也引发了激烈讨论。更值得关注的是，Press 本人是 Haskell 基金会董事会成员，也是 Haskell.org 委员会的参与者——发表这篇文章的人是一个深度投入者在进行自身技术选择的艰难复盘。
Haskell 在生产环境中兑现了哪些承诺
在文章中，Press 首先肯定了 Haskell 带来的价值。Scarf 的后端系统——包括基于 Servant 和 Beam 的主 API、直接承载大量开源包下载流量的 Scarf Gateway（基于 WAI）——在 Haskell 上运行了多年，满足了合同约定的 SLA 要求。类型系统确实捕获了真实 bug，语言的设计迫使团队审慎地建模领域逻辑，高性能代码的编写也相对直接。
但代价同样真实。最大的两个痛点是编译时间和生态系统摩擦。团队投入了大量精力来优化构建、缓存、Nix 环境、开发者工具链和 CI 流水线。在很长一段时间内，这些都是可控的：团队对语言和工具链很熟悉，清楚踩坑位置，能够忍受这些开销。
真正改变计算方式的，是 AI 辅助开发的兴起。
编译时间如何从纸割变成瓶颈
Press 的核心论点并不复杂。在人手写代码的时代，开发者花一小时写一段逻辑，编译器花几分钟检查——这个比例是勉强可接受的。但当 LLM 能在几分钟内生成一个可工作的实现，编译步骤却依然需要十几分钟时，编译就从开发流程中的一个摩擦点变成了主导成本。
他在文章中给出了一个清晰的工程判断：关键的指标不再是编译时间本身，而是编译时间在完整反馈闭环中所占的比例。「如果一个 agent 能在几分钟内草拟出一个看起来合理的修改，然后再花 15 分钟等冷构建完成，编译器就从纸割变成了那个工作线程的主要时间消耗者。」
更致命的是并行化场景。在 AI 辅助的模式下，理想的工作方式是同时启动多个 agent，各自探索不同分支，分别尝试、运行测试、返回结果。五个并行的 agent 分支意味着五倍的构建税。Nix 缓存、远程构建器等工具有帮助，但从不完美，而为让缓存可靠运作所付出的工程努力本身也是税的一部分。
这让 Haskell 在 AI 驱动的开发工作流中处于结构性劣势。
迁移策略与初步效果
Scarf 选择了渐进式迁移而非大爆炸重写。团队部署了 Python API 服务器与 Haskell 服务并列运行，按路由逐步迁移功能。新 API 路由走 Python，已有 Haskell 代码继续运行，Haskell 的覆盖范围随时间缩小。
LLM 在迁移中扮演了关键角色。认证、数据库访问、模型、部署镜像、测试和运维胶水代码的重新实现，在 LLM 的辅助下变得比过去轻得多。「用今天的模型把已有代码移植到另一种语言，出奇地直接，」Press 写道。
关于迁移的实际效果，Press 表示类型安全方面的损失「尚未以任何具体方式显现」，而测试覆盖率达到了历史最高水平。修复 bug 的速度也加快到了一个前所未有的程度——修复「实际上只需要一条 Slack 消息」。
争议中的不同声音
这不是一个没有争议的决定，社区的反驳同样有力。
类型系统是 LLM 护栏，而非开销。 在 Hacker News 的高赞评论中，Scala/Rust 资深用户 noelwelsh 表达了完全相反的观点：「我无法想象在没有优质类型系统的语言中工作，来捕获 LLM 产生的所有垃圾。我原本以为人们会从类型系统薄弱的语言向表达力更强的语言迁移，因为 LLM 降低了使用后者的成本。」这个观点的核心是：类型系统对 LLM 生成代码起到了即时反馈的作用——编译器拒绝错误输出，迫使 agent 快速收敛到正确的解决方案。在这个框架里，编译时间是 LLM 工作流中最有效的质检环节。
编译慢的原因可能不在语言本身。 多位 Haskell 社区成员指出，Scarf 使用的 Beam ORM 库在社区中以编译缓慢而闻名，这可能是实际瓶颈，而不是 GHC 本身。有开发者提到自己 120 万行的 Haskell 代码库冷构建不到三分钟，暗示问题可通过架构调整解决，而非语言层面不可修复。
Python 并非唯一的替代选项。 不少评论者对 Haskell→Python 的跨度感到意外。社区成员提出的中间方案包括：OCaml（编译快且保持类型安全）、Go（简单、亚秒级构建、足够强大的类型）和 TypeScript（带有可选类型检查的 Python 替代品）。Hacker News 用户 crux 总结道：「agents 需要快速编译以求有效，但也需要强类型系统和狭窄护栏来约束输出。这两点在 Rust（和 OCaml）中都能获得。」
在 Lobsters 上，一些评论更加尖锐，将文章归结为「AI 驱动下的幻觉」或「被魔法盒迷惑」。但也有人指出，工业界用户对编译时间和生态系统摩擦的抱怨已经持续多年，AI 只是让这些长期未解决的问题从「可以忍受」变成了「不可接受」。
对函数式编程工业应用的启示
Scarf 的转向对函数式编程（FP）在工业界的前景提出了一个值得认真对待的问题：在 AI 主导开发节奏的时代，语言和工具链的反馈速度是否已经成为一个生存级指标？
这并不是说 FP 的核心优势——类型驱动的可靠性、组合式设计、数学化的抽象能力——不再重要。而是说，如果这些优势的获取成本在 AI 时代变得不成比例地高，它们就可能被边缘化。正如 Press 在文章中提到的，Haskell 社区在讨论 AI 时「往往更关注限制而非赋能」：讨论规范、披露要求、甚至抵制 LLM 参与的工作流。而他主张的方向是：让 Haskell 成为对 agent 友好的语言——优化构建速度、提供丰富的 copy-paste 示例、让错误信息对 agent 更有用、让项目冷启动更快。
与此同时，Haskell 并非 FP 在工业界的唯一代表。OCaml 在某些量化金融团队中保持活跃，Rust 的类型系统借鉴了 Haskell 的核心思想并在系统编程领域获得广泛采用，Elixir/Erlang 在分布式系统中持续增长。这些语言的共同特点是：在 FP 的理念和工业界的反馈速度之间，找到了不同的平衡点。
Press 文章结尾的警告值得函数式编程社区认真对待。他写道，从 Scarf 自身对开源生态趋势的观察来看，Haskell 的增长「充其量只能算温和」，而大量开发者生态正在 AI 时代加速发展。机会成本的累积从未如此之高。
Scarf 的故事不是 Haskell 的终结，但它揭示了一个正在重塑编程语言竞争格局的趋势：快速反馈循环、庞大的训练语料库和 agent 友好的工具链，正在成为新时代的选择要素。这些要素很少出现在传统的编程语言比较矩阵中，但它们的权重正在快速上升。
参考链接：
- https://avi.press/posts/2026-07-10-after-7-years-in-production-scarf-has-reluctantly-moved-away-from-haskell.html
- https://lobste.rs/s/t4f6jt
- https://news.ycombinator.com/item?id=48859673
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。