Elm 0.19.2 与迈向 Elm 1.0 之路

Elm 0.19.2 与迈向 Elm 1.0 之路

Elm 0.19.2 提升了编译器性能

Elm 0.19.2 专注于减少解析过程中的内存分配，以加速构建时间。对于大规模项目，该更新提供了适度的性能提升，而在对拥有 351 个模块的项目进行的实际测试中，从 scratch 进行编译的时间从 4.981 秒减少到了 2.595 秒（提升了 1.9 倍）。

对于超过 500k 行代码的程序，关键技术指标包括：

  • 垃圾回收 (GC) 中的复制操作减少了 20%
  • 峰值内存使用量降低了 10%
  • 整体性能提升了 7%

主要目标是将增量构建时间保持在 400ms 以下，以防止开发者在上下文切换期间注意力分散。

Elm 1.0 的策略

Evan Cunningham 打算通过一系列小的、非破坏性的发布来达到 1.0 版本，而不是通过一次性的单体更新。这种方法允许逐步集成源自 Acadia（一个目前处于私有 alpha 阶段的数据库相关编译器）近期工作的编译器和语言新想法。

计划添加到语言中的特性包括：

  • equatable 类型
  • hashable 类型
  • 进一步的性能优化

社区观点与历史背景

虽然 0.19.2 的发布标志着活跃度的回升，但社区对于语言的发展轨迹和治理仍存在分歧。

技术与哲学上的摩擦

许多用户指出，对原生 JavaScript 互操作性的限制（在 0.19 版本中引入）是一个阻碍采用的关键转折点。通过要求使用 "Ports" 机制并限制用户编写自己的 JavaScript 包装器的能力，核心团队限制了该语言与更广泛的 Web 生态系统的集成能力。

"核心团队限制了用户进行任何原生 JavaScript 互操作的能力，这破坏了每一个需要核心库之外任何功能的 Elm 应用... 那是 7 年前的事了。"

其他批评者指出，缺乏对本地化 (i18n) 和无障碍性 (a11y) 等基本生产环境特性的支持，是称其为 "生产就绪" 的障碍。

Elm 架构的吸引力

尽管存在这些不满，支持者认为 Elm 的严格性和主观性的架构使其成为 LLM 辅助开发的理想目标。由于语言是稳定的，且代码库结构高度一致，与更灵活的框架相比，AI 模型可以生成更可靠的代码。

用户还强调了 Model-View-Update (MVU) 架构的简洁性，指出它比许多现代庞大的 Web 框架更容易进行推理。

市场替代方案

一些社区成员已转向其他受函数式启发的工具，特别提到了 Gleam 和 Lustre 作为替代方案，它们提供了类似的开发者体验，并拥有更活跃的社区管理以及对前端和后端开发的双重支持。

Sources