Gleam 不再编译为 Erlang 源码

Gleam 的 Erlang 后端变更

• Gleam 现在输出 Erlang 的“抽象形式”（Erlang 编译器的 AST/IR），而不是人类可读的 Erlang 源码。
• 几位评论者指出，这正是 BEAM 生态系统中广泛使用的表示形式（包括 Elixir 和 parse transforms）。
• 一位评论者起初批评旧方案选择生成文本源码而非抽象形式，认为这既多余又容易出错。
• 一位核心贡献者解释了最初的决定：当时，抽象形式还不是明确的“标准”，Core Erlang 的 API 对外部 Rust 编译器来说也不稳定，而输出源码可以提供回退到 Erlang 的逃生通道，并让他们借助 Erlang 的构建工具。
• 现在 Gleam 直接写入 Erlang Term Format；仍然有一个 Erlang 源码生成器，主要用于测试。

“Transpiler” 与 Compiler

• 文章提到“transpiler”并不天然带贬义，这一点引发了讨论。
• 有人指出，旧的流水线确实更差，但问题在于实现，而不是因为它生成源码。
• 也有人认为，如果你能把抽象形式再漂亮打印回 Erlang 文本，那么“AST”和“源码”的区别在某种程度上只是语义上的。

目标、用途与互操作

• Gleam 被描述为一门通用、静态类型、类 ML 的函数式语言，目标是简单、安全和良好的工具支持。
• 主要服务端目标：BEAM（Erlang 虚拟机）。次要目标：JavaScript，主要用于 Web/前端或其他由 JS 承载的场景（例如 Lustre Web 应用）。
• 一位评论者质疑如果 Gleam 不是“为 UI 而生”，为什么还要把 JS 作为目标；其他人回应说，JS 在 UI 之外也很有用，而且在服务器、SSR 和有类型的前端之间使用一门语言很有吸引力。
• 与 Elixir 的互操作是可行的，但由于类型系统不同，并不算“无缝”。

原生 / 其他后端

• 有些人希望 Gleam 能编译到原生目标（例如 Rust、Go、C、Wasm、LLVM IR）。
• 一位核心贡献者认为：
  • Rust 是一个糟糕的编译目标：编译器慢、并未广泛安装，而且它为人类作者设计的方式并不适合作为后端 IR。
  • Go 的 GC 和 goroutine 模型并不适合 Gleam 这种不可变、基于进程的风格。
  • 如果要走原生路线，更低层的 IR（C、Wasm、LLVM、Cranelift）会更合适。
• 诸如把 BEAM 打包成单一可执行文件的变通方案（例如通过 Gleepack）已经可以得到小巧、可移植的二进制文件。

语言对比与学习曲线

• 对比：Gleam 经常被比作 OCaml/Standard ML/Elm/F#，而不是 Rust。
• 一些人认为 Rust 用户可能会觉得 Gleam 的语法和模式匹配很容易上手；另一些人提醒，Rust 中的概念预期（所有权、借用）并不能迁移过来，反而可能造成困惑。
• Erlang vs Elixir vs Gleam：
  • Gleam：有类型、极简、没有宏、函数头里没有模式匹配（为了简单而做出的取舍）。
  • Erlang：一些人称赞它的 matcher/guard 和出人意料地令人愉快的语法。
  • Elixir：其宏、OTP 集成、出色的 REPL 以及成熟的 Web 框架很受重视；对一些 Rust 用户来说，即使有 Gleam 的静态类型，他们仍更偏好 Elixir。

社区、生态与采用

• 多条评论称赞 Gleam 社区异常友好，包括直播和教学讲座。
• 用户反馈用它构建真实项目的体验很好（例如 Web API/服务、通过 Gleam + Lustre + Tauri 构建的应用）。
• 有些人把 Gleam 视为自己的默认技术栈；也有人遗憾没有工作项目可以用上它。
• 一位评论者担心，在基于 LLM 编码的时代，“LLM 友好性”可能会成为小众语言被采用的门槛，这让他感到沮丧。

其他零散讨论

• 一段关于英文中逗号使用和语法规范的详细旁支讨论；共识是，风格因人而异，除正式场合外大多数人并不太在意。
• 有一段简短讨论提到把 Gleam 生成的代码与 WhatsApp 的 Erlang 调试器之类工具集成；如果传递了编译标志，这被认为很简单。
• 有人简短批评 Gleam 的品牌形象看起来“像女孩玩具”，其他人则反驳说这种不安很奇怪，也无关紧要。