Advent of CodeのためにGleamを使ってみた感想

 (blog.tymscar.com)
2 ポイント 投稿者 GN⁺ 2025-12-14 | 1件のコメント | WhatsAppで共有
  • Advent of Code 2025 の12日間のパズルをGleamで解き、言語の Rust級のエラーメッセージ と パイプライン中心の関数型スタイル が特に印象的だった
  • echo、fold_until、list.transpose などの組み込み関数が、デバッグや組み合わせ問題の解決を単純化し、オプション型ベースの安全性 がグリッド系パズルの処理で有効に機能した
  • 標準ライブラリに ファイルI/Oや正規表現機能が含まれていない点、リストのパターンマッチ制約、明示的な比較構文 などは、繰り返し使う中で不便な点として挙げられた
  • Erlang VMとJavaScriptターゲット間の 整数処理の違い により bigi の利用が必要であり、一部のパズルでは 外部ツール（glpsol） を呼び出して問題を解決した
  • 全体として 関数型の発想への切り替えがパズル解法を明快にし、Gleamを実際のプロジェクト（例: Webサーバー開発）に適用してみたいという期待を示している

Advent of Code 2025とGleamの選択

  • 毎年Advent of Codeを完走してきた筆者は、今年 Gleam言語 を選び、12日間のパズルを解いた
    • 今年は25日ではなく12日に縮小されたが、各問題の難易度は高く、学習には適した構成だった
  • パズルの進行が速く、ツールセットが整う前に複雑な問題に直面したことで、新しい言語を学ぶのに理想的な環境 になった

Gleamの言語的な長所

  • 簡潔な文法、有用なコンパイラのエラーメッセージ、Rust級の親切なフィードバック が特徴
  • パイプ演算子 中心の関数型スタイルが、AoCの問題構造（パース→変換→fold）によく合っている
  • IntelliJ向けGleam拡張 とLSPが安定して動作し、開発環境は快適だった
  • 関数型プログラミング（FP）は命令型コードよりも、問題の本質を記述する方法 へと思考を切り替えさせる

主な機能とコード活用例

  • echo: パイプラインの途中で値を確認できる単純な出力関数で、文字列フォーマットなしにデバッグできる
    • 文字列補間機能がないため、テキスト生成時に <>" 演算が増える点は不便だと言及されている
  • オプション型（dict.get）: グリッド系パズルで境界チェックなしに安全な隣接探索が可能
  • リストユーティリティ
    • list.transpose: 行列の転置演算によってパズル構造を単純化
    • list.combination_pairs: 3Dポイントのペア生成を、ネストしたループなしで1行で処理
    • fold_until: 条件を満たした時点で早期終了できるfold関数で、パズルの反復計算に効率的

Gleamの制約と不便な点

  • 標準ライブラリにファイルI/Oがない ため、simplifile パッケージで代用
  • 正規表現機能 も外部依存（gleam_regexp）が必要
  • リストのパターンマッチ制約: [first, ..middle, last] 形式は不可
  • 比較演算の明示的な処理: order 型を使う必要があり、単純な比較でも構文が冗長になる

高度な活用とパズル別の事例

  • bigi: JavaScriptターゲット時の整数オーバーフロー防止のために使用
  • XORビットマスク: Day 10-1で照明トグル問題をXOR演算でモデル化し、効率的に解決
  • glpsol の呼び出し: Day 10-2で線形方程式を解くため、LPファイルを生成して外部コマンドを実行
  • メモ化キー: Day 11-2でノードと状態を組み合わせてキーに使い、即座に計算を完了
  • 最後のパズル は入力の仮定に依存しており、単純な面積比較（heuristic_area <= max_area）で解決した

結論と今後の計画

  • Gleamは 標準ライブラリの限界にもかかわらず、安全性と表現力で強み を示した
  • パイプライン、オプション/結果型、リスト関数、fold_until などは、パズル解法を明快にした
  • 今後は Webサーバー開発など実際のプロジェクトへの適用 を計画しており、来年のAdvent of CodeでもGleamを使い続ける意向を示している
  • 全ソースコードはGitHubリポジトリで公開されている（tymscar/Advent-Of-Code/2025/gleam/aoc/src）

関連記事

1件のコメント

 
GN⁺ 2025-12-14
Hacker Newsの意見

  • Gleamは本当に美しい言語。Elixirも型システムの面でこういう方向に進化してくれたらよかったのにと思う
    GleamもErlang VMであるBEAM上で動作し、そのおかげで並行性やキュー処理がとても簡単
    エコシステムも素晴らしい。ただ、LLM時代以降、2021年以後の言語の発展が止まったように感じて心配している
    それでもGleamはその扉が閉まる直前にうまく入ってきたし、LLMもすぐに追いつくと期待している

    • なぜLLMが言語の発展を止めると思うのか気になる。最新モデルは今年までの知識を含んでいるし、新しい言語でも例がいくつかあればかなりうまく学習する
      言語は文法的にも哲学的にも完全に別物にはなり得ないのだから、大きな問題ではない気がする
    • GleamがOTPの上に作られているというのは正確ではない。Erlang VMはBEAMで、OTPはErlangのライブラリと設計原則の集合
      Gleamは独自に型安全なOTPサブセットを提供している。関連ライブラリは gleam-lang/otp を参照
    • その通り。Erlang VMはBEAMであってOTPではない。GleamのOTP実装はElixirやErlangほど完成度は高くない
    • 私も最近ElixirでLLM機能を含むプロジェクトを初めて作ってみたが、むしろこうした流れが言語採用を促進することもあり得ると感じた
    • Elixirも段階的に集合論的型付けを導入中。関連文書: gradual-set-theoretic-types

  • 今年のAdvent of CodeをGleamで解いてみたが、かなり印象的だった
    長所としては性能が良く、言語サーバーが驚くほど強力。自動フォーマット、自動import、パターンマッチの補完など、開発体験が素晴らしい
    短所は、フォーマッタがコードを縦に伸ばしすぎることと、単純さを重視しているため list.map のような繰り返し入力が多いこと。さらにライブラリエコシステムがまだ不足している

    • 私も性能には驚いた。Cほどではないが、予想よりずっと速い。言語サーバーもほぼすべてのIDEでうまく動く
      list.map は import gleam/list.{range, map} のように短くできる。Cライブラリの移植も面白そう
    • 短所は受け入れられるが、if/elseやguardがないのは不便。真偽値による分岐処理が冗長になりすぎる
    • F#でAoCをやったが、似たような感覚だった。List.map のような名前空間の繰り返しが**発見しやすさ（discoverability）**を下げている
    • 引数のフォーマットはおそらくPrettierアルゴリズムのせいだろう。それでもclang-formatのbinpackingよりはずっと良いと思う

  • Gleamは好きだが、再帰関数呼び出しの制約が惜しい。内部関数呼び出しの自由度が高くない
    構文的にはSchemeほど優雅ではなく、概念的にはErlangより単純。それでも静的型付けは長所
    OCamlも使ったことがあるが、opamのlockファイル問題などで環境の再現性が低かった。SMLのエコシステムがもっと大きければと思う

    • 私も似た考え。Haskellは理論的には素晴らしいが、単純なhello worldですらリソース消費が大きい
      Idris 2は依存型と優雅な設計を備えているがエコシステムが小さく、PureScriptはHaskellより実用的だがJSランタイムに縛られている
    • ML系が好きならReScript v12を勧めたい。OCamlとGleamの間でバランスの取れた位置にある

  • echo 機能を見て、デバッガにこうした中間結果確認機能が標準であればいいのにと感じた
    配列スライスやフィルタチェーンの途中結果をコード修正なしで見られるとよい
    また、2次元配列をグリッドとして使うのは非効率だと思う。1次元配列 + 境界情報のほうが安全で効率的

  • Gleamはよく知らないが、list.map(fn(line) { line |> calculate_instruction }) は
    単に list.map(calculate_instruction) と書けるのではないかと思う

    • その通り。私も時々、もっと複雑な処理をしていたものを消して、その形だけ残したことがある
    • はい、その通り

  • Gleamは素晴らしい言語。自分にはそこまで刺さらなかったが、人々が楽しんでいるのを見るのはうれしい
    Gleam + Lustre の組み合わせは新たなElmになるかもしれないと思う

    • バックエンド開発者としてElmは魅力的だったが、作者との対立やリリース停止によって離れた。それでもそのアーキテクチャは他のプロジェクトでも有用だった
    • 私も最近Gleam + Lustreで小さなアプリを作ってみたが、Elm + PostgRESTよりずっとうまくいった。これからもっと大きなプロジェクトにも使う予定
    • Lustreを見てみたが、エコシステムがまだ小さい。認証関連の例もなくてLiveViewにした。それでもergonomicsが良いので成長してほしい

  • 最近のLLM時代に、新しい言語を学ぶ価値があるのか悩む
    LLMが学習していない言語だと、ツールとしての有用性が下がるのではと心配

    • 長期的にLLMが新しい言語を学習できないなら、汎用知能としての目標に失敗しているということだ
    • 1〜2年前はそうした懸念があったが、今ではClaude CodeがElixirコードもかなりうまく書く。学習データが少なくても問題ない
    • ClaudeはGleamもうまく扱える。文書と診断メッセージの品質が高いので、LLMが学びやすい。Rust並みの診断を提供する
      一方でSwiftは構文が複雑でLLMには扱いにくい
    • 言語を道具として見るなら、市場需要の不足のほうがより大きな制約かもしれない
    • 新しい言語がLLMの限界のせいで止まってほしくない

  • 以前Gleamを見たとき、動的ディスパッチ（interfaceやtype class）がなさそうに見えたが、今はどうなのか気になる

    • たいていは「関数の構造体を渡す」という形で解決する。明示的なアプローチなので、むしろジェネリクスの複雑さから自由で良い
    • Gleamは第一級関数をサポートしているので動的ディスパッチは可能。type classやinterfaceは結局高階関数で表現できる

  • [first, ..rest] や [first, second] は可能だが、[first, ..middle, last] はできない。
    おそらくコストが高いので意図的に禁止しているのだと思う

  • 幸いにもブログタイトル警察がすぐに出動した
    関連リンク