Gleam 不再编译为 Erlang 源代码

Gleam 是一种适用于 Erlang 虚拟机和 JavaScript 运行时的类型安全且可扩展的语言。今天 Gleam v1.19.0 已经发布，让我们来看看有哪些新功能。新的编译目标 在过去的几个月里，Giacomo Cavalieri 完全重写了 Gleam 的 Erlang 代码生成器，它具有完全不同的设计，最值得注意的是，输出了不同的格式。以前Gleam生成Erlang源代码，现在它生成Erlang抽象形式。 “Erlang 抽象形式”是 Erlang 编译器使用的中间表示形式。它是一个表示 Erlang 语法的元数据注释树，通常是通过运行 Erlang 的标记器和解析器生成的。它有一个使用 Erlang 的外部术语格式的二进制编码，通过这种二进制格式，我们可以直接加载生成的代码，跳过 Erlang 编译器的前半部分。这个新的 Erlang 代码生成器带来了几个好处： 编译器的性能得到了提高，显着缩短了在 Erlang 上运行的 Gleam 项目的构建时间。运行时可用的位置元数据现在精确到原始 Gleam 源代码，而不是编译器生成的 Erlang 源代码。这意味着，例如，BEAM 崩溃报告和堆栈跟踪中的行号是完全准确的，而以前它们可能不准确，仅指向最近的函数。此元数据还可以在 edb 等调试器中启用对 Gleam 的全面支持，尽管我们自己尚未对此进行任何工作。 Gleam 编译器的代码质量得到了提高。 Erlang 代码生成器是 Gleam 代码库中最古老、最稳定的部分之一，因此虽然它没有给我们带来任何问题，但它不符合我们今天的标准和约定。这个新的替代品非常出色，并且可以说提高了整个编译器的标准。我们再也不会听到有人使用“转译器”这个词作为贬义词了。 1 好的，那么速度有多快？我稍后将向您展示一些数字，但请记住，基准总是人为设计的，永远无法讲述完整的故事。这些数据可能是一个很好的介绍或起点，但良好的理解需要人们做进一步的研究和经验。该基准测试基于 José Valim 的 langcompilebench 项目。谢谢你何塞！它衡量编译 100 个模块所需的时间，每个模块包含 100 个返回“hello world”字符串的函数。这是实用的，因为这种形式的测试项目可以轻松地在不同语言之间复制，以生成最相似的测试项目，但它能告诉我们的内容有限，因为只能编译每种语言功能的一小部分。在实际项目中，代码会更加多样化，不同的功能在不同的语言中会有不同的编译成本。代码生成器重写的第一阶段已在上一个版本 v1.18.0 中发布，因此让我们将 v1.17.0 与新发布的 v1.19.0 进行比较。该图表显示了编译基准项目所需的时间，越低越好。 0ms 100ms 200ms 300ms 400ms 500ms Gleam v1.19 Gleam v1.17 正如您所看到的，相当大的改进！这是从头开始的完整构建，没有任何缓存。 Gleam 的编译是增量式的，因此在典型的开发过程中它会快得多，因为它不会编译整个项目。最初的 langcompilebench 仅包含 Erlang、Elixir 和 Gleam，但我将其扩展为其他流行的编程语言，以帮助人们粗略地了解 Gleam 与他们熟悉的语言相比的编译速度。编译为 JavaScript 时我还包含了 Gleam。结果如下： 0ms 200ms 400ms 600ms 800ms 1000ms Gleam (JavaScript) Go Gleam (Erlang) Erlang Java Elixir Elm Rust C# TypeScript 7 请记住：这是一个人为的基准测试，仅凭这一点不足以得出有关这些语言的任何硬性结论。也就是说，这些结果确实表明 Gleam 的编译又好又快，作为一名 Gleam 程序员，我可以说 Gleam 开发非常愉快，几乎不需要等待计算机的时间。为什么不直接针对 BEAM 字节码？我们已经从从输入到 Erlang 编译器的源代码进行编译转向输入到 Erlang 编译器的中间表示形式，但为什么不完全绕过 Erlang 编译器呢？难道我们不能制作一个性能优于 Erlang 编译器的 BEAM 字节码生成器吗？也许我们也可以使用 Gleam 的类型信息来生成更优化的代码。虽然有可能实现这些好处，但我们不太可能做到。与 Erlang 源代码和 Erlang 抽象形式不同，BEAM 字节码不是固定不变的。虚拟机的每个新版本都可以发展和改进字节码，添加新功能，有时删除冗余的功能。我们需要致力于永远保持最新状态