Gleam：Erlang VM 上的一门类型安全语言

原文 ↗ Hacker News 讨论 ↗

Gleam 是一门面向 Erlang VM 的新型静态类型、ML 风格语言，旨在把强类型安全与 BEAM 著名的并发和故障容错能力结合起来，同时还能编译到 JavaScript。评论者赞赏它简洁的语法、Hindley–Milner 类型系统、基于 Rust 的编译器和不断增长的生态，但也对 OTP 的成熟度、测试工具，以及在小众语言与 C#、Java 或 TypeScript 等主流技术栈之间下注的长期招聘风险提出疑问。项目网站上明确的政治立场也引发了讨论：这类信息是否应该出现在技术工具中。

关于 Gleam 和 BEAM 的总体看法

  • 许多评论者都很热情：在 BEAM 上运行、ML 风格的类型安全语言、可编译到 JS、社区不错、生态在增长。
  • 有些人认为它是 Rescript 的有力替代品，也是 Phoenix/LiveView 的不错补充。
  • 也有人对 BEAM 很感兴趣，但对把它用于生产仍持保留态度，把 BEAM 看作一个“黑盒”；另一些人则反驳说，BEAM 有很好的自省和调试工具，而且通常比 Node/JVM 更容易检查。

类型系统和语言设计

  • 类型系统是 Hindley–Milner，更接近 OCaml 而不是 Haskell：有代数数据类型、泛型、类型别名；没有 type classes，也不是纯函数式。
  • 有些人觉得它“很基础”，希望有结构类型/集合论类型；也有人追问，这类特性到底能解决什么实际问题。
  • 模式匹配被认为很强；语法总体上也因简洁而受到称赞。
  • 带标签参数被广泛讨论：一些人觉得它们很讨喜，并且有助于可读性和 API 设计；另一些人则觉得它增加了复杂度并且有冗余。
  • 管道操作符的行为（自动插入为第一个参数）存在争议：一些人喜欢它的简洁，另一些人觉得它降低了清晰度。
  • 与 Elixir 相比缺少函数重载，也被简短地惋惜。

OTP、生态和互操作

  • 原生 OTP 支持通过 gleam_otp 和 gleam_erlang 提供；它们被描述为实验性的，但已经在生产中使用，包括一个据称比 Cowboy 更快的 webserver。
  • 底层所有 OTP 仍可通过 FFI 访问。
  • Rust NIF 和 port 也是可用的（通过 Rustler 等工具），但需要小心以适配 BEAM 的进程/调度器模型。

工具链、实现语言，以及用 Rust 编写编译器

  • Gleam 用 Rust 编写，并被视为基于 Rust 的语言实现的一个强有力例子。
  • 讨论涉及编译器工作中 Rust 与 Haskell/OCaml 的优缺点：Rust 的生态（解析器、LSP、诊断、增量式工具）受到赞赏，但有些人觉得 Rust 的枚举/所有权对 AST 来说很别扭。

语言选择、招聘，以及“非主流”技术栈

  • 一种观点认为：在普通企业里使用小众 BEAM 语言会损害招聘，并可能迫使进行高成本重写；主流技术栈（C#、Java、Python、TypeScript，也许还有 Go）更“稳妥”。
  • 反方观点是：按能力招聘，语言可以教；Erlang/Elixir 很容易学，而非主流技术栈还能吸引更高水平的开发者。若干轶事声称，Elixir 的招聘和上手并不困难。

使用场景与“类型化脚本”之争

  • 有些人希望 Gleam 作为一种类型化脚本选项；另一些人则认为，BEAM 和显式类型并不适合像以字符串为中心的 shell 那样快速写脚本，但非常适合更大的分布式系统。

测试故事

  • 目前测试主要围绕 gleeunit，它也可用于 JS 目标。
  • 这个工具有意保持极简；故意不支持 mock，而更偏好依赖注入。一些用户希望有更多指导或功能。

社区准则和政治

  • 项目网站明确表述了社会/政治立场（例如反种族主义/反法西斯、支持跨性别权利）。
  • 这引发了一场旁支争论：一些人认为这是表达项目价值观的适当方式；另一些人则觉得它具有争议性，并表示会因为这一点避免使用或劝阻使用。双方都指责对方把“政治”带入了技术空间。