Scarf 的后端跑了整整 7 年 Haskell，扛过真实生产流量，签过实打实的 SLA。这周，创始人发了一篇很不情愿的博客：公司新 API 开发已经全面转向 Python。
理由不是 Haskell 出了问题。是 AI 写代码这件事，把开发反馈的成本账重新算了一遍。
这篇批评来自内部，分量不一样。作者写了 16 年 Haskell，现在还在 Haskell Foundation 董事会、Haskell.org 委员会任职，同时是 Scarf 创始人。他不是外面看热闹的人。
怎么搬的：老系统不推倒，新代码换赛道
Scarf 的核心系统一直靠 Haskell 撑着：主 API 用 Servant，Beam 连 PostgreSQL，高流量的开源包下载网关搭在 WAI 上。这套代码可靠，类型系统真抓过 bug，性能也做到位。
这次没有整体重写，是渐进迁移。
| 阶段 | 系统状态 | 新代码去哪 |
|---|---|---|
| 迁移前 | 纯 Haskell，7 年生产运行 | 全部进 Haskell |
| 过渡期 | Python API 与 Haskell 并行，请求分流 | 新路由进 Python |
| 现在 | Haskell 占比逐步收缩，旧系统继续在线 | 新代码全部进 Python |
认证、数据库访问、公共模型、部署镜像都要重写一遍。放在过去，这是笔不小的成本。这次靠 LLM 把“移植代码”这件事变得相当轻松，这也是迁移能推得动的直接原因。
为什么现在：AI 把编译时间变成了新税
判断代码质量，过去只看两个时刻：编译时报错，还是运行时报错。现在多了第三个时刻——代码生成时。模型足够好，很多错误压根没被写出来，编译器要拦的东西变少了。
这不是说类型安全没用了。是编译这道关卡的相对成本变了。
如果 agent 几分钟就能写出能跑的实现，项目冷启动编译却要等十几分钟，编译器就从“小麻烦”变成了整条工作线里最贵的部分。
真正要命的是并行。一个人写代码，可以忍一次冷启动。但如果要同时开五个 worktree，让五个 agent 各自试错、挑能用的留下，每一次冷启动都是税，而且是按并发数乘出来的。
Nix、远程构建、缓存这些工具都有用，Scarf 也在用。但缓存从来不完美，把它调到“足够好用”本身就是另一份持续成本。
用单个 agent 串行写代码的团队，这笔税还能忍。一旦上多个 agent 并行跑 worktree，冷启动成本会被成倍放大，这类团队最先感到疼。还在评估要不要用 Haskell 写新项目的团队，现在多了一个具体判断标准：先问自己会不会大量用 agent 并行写代码，会的话，把冷启动成本提前算进决策。
Haskell 的问题不在语言，在优先级
作者的判断很直接：类型安全、可组合设计这些 Haskell 的强项没有过时。过时的是生态对这些强项的投入方式。
他观察到，Haskell 社区谈起 AI，更多在讨论要不要限制、要不要禁止，而不是怎么让 agent 更好地用 Haskell——怎么把冷启动压下来，怎么让文档塞满能直接抄的例子，怎么让报错对 agent 更友好。这些问题，他认为比继续深挖依赖类型这类语言理论更紧迫。
他没给出具体增长数字。所谓 Haskell 增长“顶多算温和”，是他个人观察，不是公开统计。方向不难猜：一门语言如果持续把力气押在语言研究上，而不是构建速度、工具链和 agent 友好度，很容易在这轮竞争里慢半拍。
有个限制要说清楚：这只是 Scarf 一家公司的选择，不是 Haskell 生态的整体数据。Haskell 在这套系统里跑了 7 年没出过大问题，类型安全的价值没有归零，只是变得没那么划算。
接下来该看的是，Haskell 社区会不会把冷启动、agent 友好工具链当成优先级来做。如果继续把精力押在类型理论研究上，Scarf 这次迁移大概不会是最后一例。
Scarf 现在的状态是新旧并存：新功能进 Python，老系统继续在生产里跑着，没人打算把 Haskell 一次性推倒重来。孔子说“往者不可谏，来者犹可追”，对 Scarf 来说，可追的不是要不要留着 Haskell，是能不能追上现在的速度。
打不过的不是 Python，是节奏。