用了七年 Haskell 后，他们为什么在 AI 时代转向 Python
作者：陈墨｜OC 开发编辑
陈墨
据 Scarf 创始人 Avi Press 的公开复盘，公司在生产环境使用 Haskell 七年后，已经把新的 API 开发转向 Python，并在维护旧系统的同时逐步迁移功能。
一句话结论：Scarf 不是因为 Haskell 不可靠而离开，恰恰相反，它认为 Haskell 很可靠；变化在于 AI Agent 把写代码变快以后，编译、冷启动和生态摩擦成了新的主要成本。
Press 不是站在门外批评。他学习 Haskell 16年，是 Haskell Foundation 董事和 Haskell.org 委员会成员。Scarf 的 API 使用 Servant、Beam 与 PostgreSQL，高流量下载网关直接建立在 WAI 上，长期承担真实 SLA。他对类型系统、性能和领域建模仍然给出高度评价。
问题是完整反馈周期。人类写一小时代码，再等十分钟编译，虽然烦但还能接受；Agent 几分钟写完修改，却要等十五分钟冷构建，编译就从“小麻烦”变成任务的主要耗时。并行开五个 worktree 让五个 Agent 尝试不同方案时，构建缓存、Nix 环境和内存成本还会一起乘五。
类型安全真的不重要了吗
这篇文章最容易被误读成“有 AI 就不用类型”。Press 的原意更细：错误过去主要在编译期或运行期暴露，现在模型可能在生成阶段就避开一部分常见错误，类型检查的相对收益与等待成本因此重新计算。Scarf 转向 Python 后，用更快的测试循环补偿一部分静态保证，并没有停止测试和代码审查。
这仍然只是一个公司的经验，不是编程语言定律。Python 的运行时错误、依赖管理和性能问题不会因为 Agent 出现就消失；社区讨论中也有人质疑，迁往 Python 是否只是把编译期成本换成长期维护成本。更合理的结论是：AI 放大了工具链反馈速度的重要性，而不是宣布强类型语言过时。
Scarf 采用的迁移方式也值得注意。它没有重写整个后端，而是让新 API 进入 Python 服务，旧 Haskell 服务继续运行，访问流量按路由分配。认证、数据库模型、测试和部署逐步重建。这种“绞杀者模式”降低了大爆炸迁移的风险。
关键事实
- Scarf 的 Haskell 系统仍在生产运行，并非因稳定性事故被紧急替换。
- 新 API 使用 Python，旧功能在被修改时逐步迁移。
- 作者没有给出统一的 PR 数量或代码行指标，生产力提升主要是团队观察。
- Haskell 社区对 AI、编译速度和生态优先级存在明显分歧。
OC 判断
AI 编程会让“反馈延迟”成为语言竞争的新指标。最适合 Agent 的语言未必语法最简单，而是环境容易复制、文档例子充足、错误信息可修复、测试启动快。Haskell 的类型系统本可以成为 Agent 的强反馈器，但前提是编译器不能让每次尝试都付出过高时间成本。
为什么重要
- 开发者：评估语言时，应测量完整的生成、构建、测试和修复循环。
- 企业：渐进迁移通常比一次性重写更能保留业务稳定性。
- 用户：这不是 Haskell 产品会立刻消失，而是未来新增功能可能更多出现在其他技术栈。
评论
围绕这篇文章补充信息、提出问题或分享观察。