本文へ
ハクソク

世界を動かす技術を、日本語で。

GleamはもはやErlangソースにコンパイルされません

元記事: 原文(gleam.run)

概要

  • Gleam v1.19.0 がリリースされ、新しいErlangコード生成方式を採用
  • コンパイル速度 とデバッグ体験が大幅に向上
  • JavaScript向け最適化 やTypeScript型サポートも強化
  • 他ビルドツールや 言語サーバー の機能が拡充
  • コミュニティ主導で 持続可能性 を重視した開発方針

Gleam v1.19.0の新機能と改善点

  • Erlangコード生成ターゲットの刷新

    • Giacomo CavalieriによるErlangコードジェネレータの全面再設計
    • 従来のErlangソースコード出力から Erlang抽象形式 出力へ移行
    • 抽象形式はErlangコンパイラの中間表現であり、直接バイナリ形式でコードをロード可能

  • 新ジェネレータのメリット

    • コンパイラ性能の向上 により、Erlang向けGleamプロジェクトのビルド時間を大幅短縮
    • ランタイムで利用できる 位置メタデータ がGleamソースに忠実となり、BEAMのクラッシュレポートやスタックトレースの行番号が正確に
    • デバッガ（例: edb）でのGleam完全対応も将来的に可能
    • コード品質の向上と最新の開発基準への適合

  • コンパイル速度の比較・ベンチマーク

    • José Valimのlangcompilebenchプロジェクトを基に100モジュール・各100関数のコンパイル時間を測定
      • v1.17.0とv1.19.0で 大幅な速度改善 を確認
      • 他言語（Go, Java, Elixir, Elm, Rust, TypeScript等）とも比較し、Gleamのビルドが高速であることを示唆

  • BEAMバイトコード直接生成をしない理由

    • BEAMバイトコード仕様がErlang VMのリリースごとに進化し続けているため、 保守コスト が高い
    • Erlangコンパイラが長年かけて実装した最適化を再現するのは困難
    • コミュニティ主導で 持続可能な開発リソース を重視
    • Elixirも同様に抽象形式を採用している実績

JavaScript向け最適化

  • 分岐最適化（Decision tree assignment optimisation）

    • John Downeyによるcase式のif文最適化
      • ネストしたif文を単一条件式にまとめ、 コードの分岐と変数数を削減
      • JavaScriptエンジンによる最適化効率向上

  • リストリテラル最適化

    • 短いリストリテラルをarrayToList関数経由ではなく、 直接的なGleamリスト構築コード に変換
      • パフォーマンス向上、特にLustreライブラリ等短いリスト多用時に効果大
      • 長いリストは従来通りarrayToListを利用

  • TypeScript APIオーバーロード

    • カスタム型判定関数の型情報損失を解消するため、 オーバーロード定義 を追加
      • 型パラメータを保持しやすくなり、TypeScriptとの統合性が向上

他ビルドツール・開発体験の向上

  • 他ビルドツール対応の強化

    • ElixirやErlangのビルドツール（Mix, rebar3）でのGleamサポートを想定
      • .appリソースファイルの自動生成
      • --no-devフラグによるdev_dependencies除外ビルド
      • 各種情報のstdout出力やファイル出力対応

  • 言語サーバーのラベルサポート

    • Alistair Smithによる フィールド・引数ラベルのgo-to-definition, find-references, rename 機能追加
      • 開発効率とIDE体験の向上

  • WebAssemblyによるブラウザ上でのGleamコード整形

    • ブラウザでGleamコードを 自動整形 できる機能の提供

Gleamの今後とコミュニティ

  • コミュニティ主導・持続可能性重視の開発方針

    • 限られたリソースの中で、長期的な互換性と信頼性を重視
    • Elixirなど他言語との協調・相互運用性の確保
    • スポンサーシップ による開発支援

  • Gleam v1.19.0 はパフォーマンス、DX、エコシステム拡充のバランスを重視した進化を遂げている

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

チームおめでとう！Gleamが大好きで、Gleamのコードを書くたびに本当に楽しいよ。

ジャコモのTwitch配信に感謝！彼からGleamやRustのいくつかの機能を教えてもらったし、何よりも彼はめっちゃいい人なんだ。質問に対して丁寧に、偏見なく答えてくれる時間を取ってくれる。配信者が自分のエゴを忘れちゃうプログラミング配信はたくさんあるけど、彼はその一人じゃない。ぜひフォローすることをおすすめするよ。

└

それに、彼はプレゼンテーションを手描きで各フレームの遷移をアニメーションさせていて、それがすごく伝わってくる。 [編集 - これ、ちょっとあいまいだったかも。彼が細かいところに本当に気を使っているってことを言いたかったんだ。]

└

うん、彼はめっちゃ優しいよ。

└

ありがとう！！これを読んで本当に嬉しかったよ <3

└

超賛成！彼の配信を時々見てるけど、彼は本当に謙虚で落ち着いた人だよ。

興味がある人のために、erlang abstract formは、erlangコンパイラなどで使われるAST表現だよ。これを見ると、erlangの用語で構成されているのがわかるし、標準ライブラリからこの表現を操作するためのルーチンに簡単にアクセスできる。必要なときは本当に快適だよ！それに、elixirがコンパイルされるターゲットでもあって、parse transformsによって操作される表現でもある。基本的にerlangでは、構文シュガー（特にqlcやmerlのかわいらしいパターンマッチなど）がこうやって実現されてる。ほとんどのBEAM言語は実際にerlang abstract formatに落ち着くんだ。core erlangの方がもっと一般的だと思うかもしれないけど、伝統的な関数型IRに近い感じがするからね。でも、実際にはLFEだけがこれをやってる。リリースごとに特に安定性の保証がない動的なターゲットだからね。

すごいニュース！ありがとう！

予想外のワクワクする変化だね——誰かがWhatsappのErlangデバッガとの統合を実装することになるのかな。

└

これにはErlangコンパイラに2つのフラグを渡すだけで済むんだ。ほんとに簡単だよ！

これ、明らかな疑問を引き起こすね。Gleamチームは最初からそれをやってなかったの？明らかに彼らは直接Gleam ASTからErlangソースへのパイプラインを持ってなかったはずだから、自分たちでカスタムのErlang AST表現を作って、それをソースコードに翻訳してたんだろうね。

└

コンパイラには内部的なErlangのAST表現がなかったし、今もないんだ。以前はGleamのASTから印刷代数を経てErlangのソースコードに変換するパイプラインがあったけど、今はErlang Term Formatでデータをエンコードしたバイトのバッファを作ってる。ソースは以前のターゲットだったけど、その時はErlang Abstract Termsが主流のフォーマットとして確立されてなかったんだ（Core Erlangは人気だったけど、BEAMの外では安定したAPIがなかったから、GleamのRust製コンパイラではそれを構築できなかった）。新しい言語だから、Gleamを放棄してErlangに逃げられる「エスケープハッチ」があるのはすごく価値があったね。それに、Gleamのビルドツールが使えるようになるまでErlangのビルドツールを使えるってことでもあった。

Hacker Newsで議論の続きを見る

同じ出典の記事