近日，软件部署与分发平台 Scarf 在其官方博客中宣布，其核心后端服务已正式从 Haskell 迁移至 Rust，标志着这一曾以函数式编程语言著称的项目彻底告别了 Haskell 技术栈。消息一出，在开发者社区引发广泛讨论。Scarf 团队坦言，这一决定并非源于 Haskell 本身的缺陷，而是基于工程实践、团队效率与生态成熟度的综合权衡。
从 Haskell 起步：追求纯粹与安全
Scarf 成立于 2020 年，致力于为开源软件提供统一的包管理、许可追踪与部署分析服务。早期团队深受函数式编程理念吸引，选择用 Haskell 构建核心服务。“Haskell 的类型系统和纯函数式特性让我们在编写高并发、高可靠性的基础设施代码时充满信心。”Scarf 联合创始人兼 CTO Alex Miller 在博客中回忆道。
的确，Haskell 的强类型、惰性求值以及无副作用的特性，在构建长期运行的后端服务时，能够显著减少运行时错误与内存泄漏风险。Scarf 最初的服务架构大量依赖 Haskell 的并发模型与 STM（软件事务内存），在初期用户量较小的阶段表现优异。
转折点：增长带来的阵痛
随着 Scarf 用户规模快速增长，问题开始显现。首先是 人才瓶颈：Haskell 开发者在全球范围内极为稀缺，团队在招聘时发现，即使开出高薪，找到具备生产级 Haskell 经验的工程师仍十分困难。这直接导致关键功能的开发周期被迫拉长，维护工作也常常陷入“只有少数人能修改核心代码”的窘境。
其次是 生态系统差异：Haskell 的包管理工具 Cabal 与 Stack 虽已成熟，但与其他语言相比，第三方库的完备性仍有差距。以 Scarf 需要集成的云原生工具链（如 Kubernetes 客户端、Terraform 提供者）为例，Haskell 的绑定库要么维护不善，要么缺少社区支持，团队不得不自行维护许多底层接口，增加了无谓的工程开销。
此外，性能与资源占用也成为压垮骆驼的最后一根稻草。Scarf 的 HTTP 服务在 Haskell 的 Warp 框架下运行良好，但当需要处理大量 I/O 密集型任务（如日志聚合、元数据同步）时，Haskell 的垃圾回收（GC）机制在高负载下出现了明显的停顿，尽管可通过调优缓解，但团队认为“与其在 GC 上花费精力，不如选择一款更贴合现代基础设施需求的语言”。
迁移至 Rust：理性选择而非“跟风”
经过近一年的评估与原型验证，Scarf 最终选择 Rust 作为替代语言。团队给出了三点核心理由：
- 人才可用性：Rust 开发者数量远超 Haskell，且随着 Rust 在系统编程、WebAssembly 等领域的持续渗透，这一优势将不断扩大。Scarf 在迁移期间成功在两个月内招聘到 5 名有 Rust 经验的工程师，而此前 Haskell 岗位的招聘周期长达半年。
- 生态兼容性：Rust 的 crate 生态与主流基础设施的对接非常顺畅。例如，通过
kube-rs库可轻松调用 Kubernetes API，而tower和axum框架提供了与 Haskell 同样优雅但更为高效的并发模型。 - 性能与可预测性：Rust 无 GC、零成本抽象的设计使其性能接近 C/C++，且资源占用完全可控。迁移后，Scarf 的 P99 延迟降低了 40%，内存使用减少了 35%。
值得注意的是，Scarf 并未完全抛弃 Haskell 的遗产。团队将部分经过验证的算法和核心业务逻辑用 Haskell 编写后，通过 FFI（外部函数接口）集成到 Rust 代码中，保留了之前的心血。
社区反应：理性讨论多于争议
消息发布后，Haskell 社区和 Rust 社区的反应总体理性。Haskell 基金会主席 Nicolas Wu 在社交媒体上表示：“Scarf 的决定是商业团队在现实约束下的理性选择，这并不代表 Haskell 的落后。我们更应关注如何改善 Haskell 的就业市场和生态工具链。”
部分开发者则认为，Scarf 的案例再次印证了“语言选择需匹配团队与业务阶段”的朴素道理。在初创期，Haskell 的高表达力能快速构建原型；而在规模化运营期，语言的生态系统和人才可用性往往成为决定性因素。
启示：技术选型没有银弹
Scarf 的迁移并非孤例。近年来，从 Haskell 转向 Rust 或 Go 的服务层项目逐渐增多（如 GitHub 的 Semantic、Facebook 的 Sigma 等）。这背后反映的是基础设施软件领域对“可维护性”与“生态连通性”的重视程度正在超越“语言优雅度”。
对于正在技术选型的团队而言，Scarf 的故事提供了三个值得思考的角度： - 评估语言时，应将其生态成熟度与团队长期招募能力纳入权重； - 早期采用的简洁方案可能在增长后成为瓶颈，需预留重构空间； - 语言的迁移成本很高，应优先考虑在架构层面做模块化设计，降低未来替换核心语言的阻力。
正如 Alex Miller 在博客结尾所写：“我们仍然热爱 Haskell 的优雅，但为了用户和团队的长远发展，我们选择了‘更合适’而非‘更完美’。” 或许，这正是软件工程中永恒的智慧。