文章介绍了Haskel编程语言在生产环境中的实际应用案例，重点讲述了Mercury公司如何成功使用数百万行Haskell代码进行工程实践，展现了该语言在工程严谨性和创造性方面的独特优势。

百万行Haskell代码实践：Mercury公司的生产工程经验

核心观点

1. Haskell在生产环境中的价值

   • 作者Ian Duncan从16岁接触Haskell开始，就被其类型系统能预防空指针异常等错误的能力吸引。经过近二十年的实践，他认爲Haskell的核心价值在于：将操作知识编码到API中、爲危险操作设置严格边界，并使安全路径成爲最便捷的选择。
   • 在金融科技公司Mercury，他们用约200万行Haskell代码处理了2025年2480亿美元的交易量，证明了Haskell在大规模生产环境中的可行性。

2. 可靠性设计哲学

   • 传统方法注重预防失败，而Mercury更关注系统的适应能力：优雅降级、操作员可理解调整、架构使正确操作容易而错误操作困难。
   • 在快速扩张的公司中（每年2倍增长），半数员工经验不足一年，类型系统成爲保存机构知识的工具，而不仅是正确性证明。

3. 纯度是边界而非属性

   • Haskell的纯度本质上是接口强制的边界。例如runST通过类型限制确保内部可变操作不会泄漏到外部纯函数中。
   • 生产环境中，目标不是完全避免可变性，而是将其控制在可读且可验证的范围内。

4. 类型系统的实用主义应用

   • 通过类型设计使正确操作成爲唯一路径。例如事务性事件发布的强制封装： haskell commit :: Transact a -> IO a -- 唯一执行入口
   • 但需平衡类型编码的成本与收益：仅对可能导致静默数据损坏的约束使用类型系统，对会立即报错的约束使用运行时检查。

5. Temporal框架的采用

   • 用Temporal替换脆弱的自研状态机系统，其确定性重放特性与Haskell的纯函数理念高度契合。开源了Haskell SDK hs-temporal-sdk。

6. 领域模型与传输层分离

   • 避免将HTTP状态码等传输层概念泄漏到领域模型。例如支付错误应建模爲InsufficientFunds而非直接使用402状态码。

7. 可观察性设计

   • 推荐使用函数记录（records of functions）模式而非具体函数，以便注入跟踪、模拟等横切关注点： haskell data HttpClient = HttpClient { sendRequest :: Request -> IO Response, getManager :: IO Manager }
   • 批评了部分Haskell库缺乏可观察性设计，导致生产环境难以诊断问题。

实践建议

• 库作者：应提供OpenTelemetry支持，避免直接日志输出，暴露.Internal模块供紧急使用。
• 团队管理：需平衡Haskell理想主义与生产 pragmatism，建立代码审查文化来管控妥协点。
• 招聘策略：Haskell开发者池虽小但质量高，可通过6-8周培训使优秀的多面手胜任。

生产环境现实

• 承认存在unsafePerformIO等妥协，强调通过文档和审查管理风险
• 测试覆盖率不足是生态痛点，类型系统无法替代语义层面的测试
• 早期开发效率较低，但数月后类型系统带来的重构能力和错误预防会回报投资

结语

Haskell在生产中的真正价值不在于学术纯粹性，而在于： 1. 在组织变迁中保存关键操作知识 2. 爲危险操作建立硬性边界 3. 使安全路径成爲开发者的自然选择

对于考虑采用Haskell的团队，作者建议以工程实效而非意识形态作爲决策依据。

（注：原文约1.5万字，此处压缩至约1000字中文摘要，保留了技术要点、实践建议和核心结论，省略了部分示例和引证细节。）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

支持Haskell的观点

1. Haskell对Mercury成功的贡献

   • 作者认为Haskell的选择和早期领导经验在Mercury的成功中起到重要作用（评论1："their choosing of Haskell made their progress...that much better"）。
   • 用户称赞Haskell的类型系统能有效避免常见错误（评论5："Haskell gives you tools to encode these incantations in types"）。

2. 工程文化与实际效果

   • Mercury的工程文化和高代码质量得到认可（评论14："The quality...is at least a couple stddev above median"）。
   • 用户认为Haskell适合金融领域，且公司整体运营良好（评论9："they are playing to its strengths...well run in general"）。

对Haskell的质疑与挑战

1. 职业发展限制

   • Haskell职位稀缺，转行困难（评论2："Breaking in is really hard...you can be unstuck"）。
   • 人才池较小（评论13："what is the talent pool for Haskell devs these days?"）。

2. 技术局限性

   • 编译和部署效率低（评论6："build is slow...Docker-based deployment takes a lot of time"）。
   • 类型系统并非最优（评论15："option types...solve the issue in a very suboptimal way"）。

其他观点

1. 对Mercury产品的积极评价

   • 用户高度赞赏其银行服务的功能和可靠性（评论10："unprecedented insight into my financial life"）。
   • 界面和性能优于传统银行（评论8："The Mercury site also looks way better"）。

2. 对成功因素的客观探讨

   • 要求实证数据证明Haskell的直接作用（评论3："Empirically speaking...because of Haskell?"）。
   • 关注大规模代码库的维护策略（评论12："how they handle dependency management at that size"）。

关键引用保留

• 支持Haskell：
  "their choosing of Haskell made their progress...that much better"（评论1）
  "Haskell gives you tools to encode these incantations in types"（评论5）

• 质疑Haskell：
  "Breaking in is really hard...you can be unstuck"（评论2）
  "build is slow...Docker-based deployment takes a lot of time"（评论6）

• 产品好评：
  "unprecedented insight into my financial life"（评论10）
  "The Mercury site also looks way better"（评论8）