回顾：在生产环境中使用Haskell

语言 Haskell 服务器

摘要

Better联合创始人Carl Baatz发表了一篇博文，总结了他们四年来在生产环境中使用Haskell的情况。他写道，在构建服务器端软件时，Haskell可能“最像秘密武器了”

正文

Better联合创始人Carl Baatz发表了一篇博文，总结了他们四年来在生产环境中使用Haskell的情况。他写道，在构建服务器端软件时，Haskell可能“最像是秘密武器了”。Baatz从四个不同的角度进行了回顾：你们能完成工作吗？在实践中，它会导致延期吗？你们能招聘到开发人员吗？应该有更多的公司使用它吗？

他们构建了一个“每周处理50万个操作”的系统。该系统“已经稳定地运行了一年多，没有宕机或维护。”下面是Baatz从中学习到的一些经验：

• 只需要相当有限的知识就可以使用Haskell完成构建，但如果希望有非常高的生产力，就需要大量地学习；
• cabal-install对于初学者而言不太友好，但Stack让工作更简单；
• 库生态系统“还不错，但不是很好”；
• Laziness使得开发人员需要仔细考虑空间复杂度；
• Haskell的类型系统使得代码很容易重构和扩展；
• Haskell的类型系统降低了通过单元测试捕获不一致的需要，虽然Haskell使用QuickCheck对单元测试提供了很好地支持；
• 招聘程序员比预期容易，许多程序员为使用Haskell的前景所吸引。

为了进一步了解他的经验，InfoQ采访了Carl Baatz。

在您的博文中，其中有一个观点是，Haskell让你可以构建一个几乎没有Bug的系统。对此，您能更详细地说明下吗？

我不是说系统没有Bug，但我们目前还没有发现任何Bug（已经稳定运行了一年多）。我们的工程团队值得赞扬。对于这门语言以及我们如何使用它，我也许可以提供一些有用的信息。

对于初学者而言，Haskell的类型系统确实可以确保更高程度的一致性，比许多主流语言都高。根据我的经验，在动态类型语言中，Bug通常是重构导致的“低级”错误：我修改了一个对象的字段属性，但没有将用到它的地方全部更新。在Haskell中，编译器会告诉你遗漏了什么，因为你所做的修改改变了对象的类型，使得修改后的对象和以前的使用前提出现了不一致。

该语言还鼓励你使用一种具有“强静态保障（strong static guarantees）”的编程风格。例如，你可以将配置信息一个字符串一个字符串地保存在词典中，然后在使用配置信息的地方处理丢失或无效的条目。不过，具体指定配置类型通常很容易；例如，你可以规定，它必须有一个整数类型的端口。然后，你就可以在任何地方使用它——你知道端口查找不会失败。当然，从磁盘读取配置信息可能会失败，你可以通过退出程序或提供一个默认值来处理那种情况。

另外一个有用的东西是不可变数据和Purity（限制副作用）。不可变数据是指，我们可以安全地共享值，并把值传递给函数，而不必担心它们在我们不知情的情况下发生变化。限制副作用是指，如果函数执行不可预测的操作，如读取文件和获取随机数（即输入/输出），就必须显式标记，并且只能在其他这样的函数中使用。对于这样的输入/输出函数，要尽可能地保持简单，将大部分逻辑移到单独的函数中。这样做使得程序推断简单了许多，尤其是当复杂度增加时。

公平地说，我们还应该指出，Haskell有个地方可能比传统的语言更容易引入Bug：空间使用。因为Haskell是懒惰的，很难推断空间复杂度，那会导致“泄漏”（不是真正的泄漏，而是使用很大的内存）。这不是无法解决的问题，但需要注意跟踪这类情况。

还有更多内容可以介绍，但我要说，前面那些内容就是要点。当然，有许多东西是语言和编译器无法检测的：你的授权模型可靠吗？你的计算正确吗？你的网站显示了恰当的标签吗？

你们没有做TDD，也没有追求单元测试的完全覆盖。那你们采用什么方法测试变更？你们定义了什么类型的测试？其中哪一种最有价值？

我们使用了一种实用的测试方法：只有当编写测试的成本低于预期的Bug修复成本才编写测试。因而，我们针对可能损坏数据库的代码编写了测试，我们在重大部署之前测试性能/负载处理。在开发过程中，我们当然也会有Bug，但我不记得有哪一个成本很高，通常很快就可以修复。特别地，我们可以放心地重构代码，这很关键，不需要测试（这还是得益于Haskell的类型系统）。

另一方面，我认为，可以将Haskell的类型系统视为一个由编译器运行的测试套件，这还是很有用的。从那个角度来看，Haskell及其他具有强表达性静态类型系统的语言实际上都有许多“测试”（它们每次编译时都运行），只是，它们不是我们通常所认为的传统测试。

在上市时间方面，Haskell提供了什么优势，如果有的话？

Haskell并没有一个像Ruby和JavaScript那样的库和工具的生态系统，也就无法像Ruby和JavaScript那样快速地创建一个Web项目。因此，它在原型阶段要慢一些。我不认为那是语言的内在缺陷。不过，其生态系统确实是缺少一些我们希望能有的东西。另一方面，在快速编写和修改需要在生产环境中运行的代码时，Haskell很强大，因为我们可以少写测试，并放心地重构。如果更笼统一点讲，有人可能会认为，Haskell的初始成本高，而总拥有成本低。我认为，初始成本也可以降低，但我们还没有做到。

如何提供一种更好的Haskell开发体验？

第一样东西可能是库。Haskell的生态系统还不错，但举例来说，不如Java、Ruby、Python、JavaScript的生态系统丰富。不过，它也在稳步改善，去年已经取得了重大的进展。然而，质量更高的库和工具肯定会受到欢迎。我认为，随着社区的发展以及更多公司开始在生产环境中使用Haskell，其生态系统会不断改善（尽管不可否认，有个鸡蛋相生的问题）。

另一样让人们打退堂鼓的东西是文档，其中经常缺少一些人们希望有的东西。不同于类型，许多库即使有文档也很少。此外，我认为，有更多高质量的一般性学习资料也是有好处的。虽然现在已经有一些资料，情况也在改善，但还有很长的路要走。

最后一样东西，我可能得说更好的IDE。虽然大部分Haskell开发人员都对vim/emacs感到满意。但我认为，一个现代化的、能够识别Haskell类型系统的IDE可以降低门槛，对提高生产力也有很大的好处。有些Haskell IDE服务器（它会连接到各种文本编辑器和IDE）相关的工作已在进行当中，那是个积极的信号。不过，关于这一点，有人比我更了解。我从他们那里了解到，一个真正优秀的IDE服务器需要对编译器本身做重大修改。因此，可能还需要一段时间。

还有一样东西，有些人可能会把它列为潜在的改进点，就是语言稳定性。即使语言和基础库一次又一次地引入了破坏性变化，并招致了运维负担，但好处是，该语言保持着相对的简洁，改善了日常的工作体验。在我个人看来，那是一种比较好的折衷。不过，有些人可能会不赞同。

Better成立于2012年，旨在构建一个基于云的学习平台，并可以集成到企业现有的学习管理系统。2016年初，该公司被GRC Solutions收购。

查看英文原文：Retrospective: Haskell in Production