在生产环境运行 7 年后，Scarf 不情愿地转向了 Haskell 之外的方案

LLM 与类型的作用

• 许多人认为，在使用 LLM 时，强静态类型的价值反而更大，因为它们能捕捉“垃圾”输出，并让 AI 生成的代码更容易理解和重构。
• 也有人指出，LLM 往往会自行避免或迅速修正简单错误，因此非常强的类型系统所带来的边际收益，可能比以前更低。
• 关于 LLM 是否会降低对类型安全的需求，还是会让它变得更关键，存在争议；几位评论者明确表示，对“更少的类型安全”这一结论感到困惑。

编译时间与代理工作流

• 核心抱怨是：Haskell 缓慢的冷编译时间，成为代理式工作流中的严重瓶颈——这类工作流会频繁构建和运行测试，尤其是在多个 worktree/agent 之间。
• 有人反驳说，更少但更丰富的编译器检查可以抵消慢编译的影响，不过也承认 15 分钟的基础成本很难摊薄。
• 不少人指出，这个问题早就影响了人类生产力；只是 LLM 让它更显眼了。也有人建议，改进构建缓存/基础设施可能比重写语言更合适。

Python 与其他语言选择

• 很多人惊讶这次迁移选择的是 Python，而不是 TypeScript、Go、OCaml、Rust、Java、C#、F# 等这些既有较强类型、又有不错编译时间的语言。
• 为 Python 辩护的理由包括：团队熟悉度高、生态庞大、模型训练数据充足，以及没有编译步骤。
• 批评则集中在：类型生态弱且碎片化、需要多种类型工具、库里的注解不一致、服务器相关“坑”很多，以及运行时性能较差。

Haskell 与替代方案的体验

• 有些人表示，他们在 Haskell + LLM 的工作流中效率很高，并不认为编译时间在实践中是个大问题。
• 也有人早已离开 Haskell（例如转向 Rust），原因包括惰性、异常、生态规模与碎片化，以及工具链带来的痛点。
• OCaml、Lean、F#、Go 和 JVM 语言被反复提及为有前景的折中方案：编译快，同时又有实用的类型系统。

更广泛的 AI 时代反思

• 讨论集中在：我们是否正在进入一个“后语言”世界，代理会根据效率（运行时、token 成本、墙钟时间）来驱动语言选择。
• 也有人担心，为了追求“vibecoding”速度而进行优化，会侵蚀工程严谨性和长期可维护性。
• 还有人认为，未来的语言必须做出选择：主要为人类设计，还是主要为代理设计；这两项目标可能彼此冲突。