在 JVM 上跑 Haskell：Turbo Haskell 想拆掉的是「语言孤岛」
Haskell 社区里一件不大不小的事：Edward Kmett 发布了 Turbo Haskell（THC）——一个基于 Truffle 与 GraalVM 的 GHC Core JIT/AOT 编译器，目标是让 Haskell 跑在 JVM 上。目前已实现 GHC 9.14.1 的全部 prim-ops，并支持 Template Haskell 与 Linear Haskell。
为什么非 Haskell 用户也该关注
表面上看这是「多了一个后端」，但它真正想解决的是语言孤岛问题：一门语言再优秀，如果它的库生态、部署工具、监控体系都是独立的，采用成本就会高到多数团队放弃。
接到 JVM 上，能一次性获得几样东西：
- 现成的库生态。 可直接调用 Java 侧成熟库，而不必等社区为每件事重写一遍。
- 现成的部署与运维面。 打包、监控、调优的工具链与 JVM 服务保持一致，不需要另建一套发布流程。
- 双向集成。 反过来说，JVM 侧服务也能把一小块核心逻辑交给 Haskell 实现——只引入需要的那部分，而不是重写整个服务。
它和 AI 工程的实际交集
把这件事放进 AI 基础设施的语境，价值更清楚。近一年 Agent 系统最典型的故障不是模型答错，而是流程状态失控：重试次数没有上限、工具调用顺序错乱、并发分支的结果互相覆盖、失败回滚不完整。
这些恰好是强类型系统最擅长表达的领域。用类型把「哪些状态合法、哪些转换被允许」编码进去，很多错误在编译期就消失了，而不是等线上跑飞一次才发现。在 JVM 生态里能直接写这类逻辑，比另外再起一个 Haskell 服务现实得多。
评估路径建议
若真要试，别一上来就移植核心服务。按这个顺序成本最低：
- 先验 prim-ops 兼容性。 作者已实现 GHC 9.14.1 全部 prim-ops，但你的项目可能用了更冷门的扩展或外部 C 绑定，先跑通编译再说。
- 量一量编译期开销。 Template Haskell 在编译期执行代码，这个成本在大项目上不低，需要与 JIT 预热时间一起算进部署时长。
- 测互操作边界。 跨语言调用的序列化、异常传递、GC 行为是实际踩坑最多的地方，比语言特性本身更容易出问题。
- 明确收益口径。 引入它的理由若是「用类型系统降低状态机出错率」，那就拿缺陷率来验证；若是性能，就该先证明 GraalVM 上确实优于现有方案。
语言之争通常无解，但「能不能与其他生态一起工作」是有明确答案的。 Turbo Haskell 押的是后者。