ハクソク

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

グリームプログラミング言語

2026年1月14日原文(gleam.run)

概要

  • Gleamは 強力な型システム と 関数型プログラミング の表現力を持つ言語
  • Erlang仮想マシン 上で動作し、 高い信頼性 と スケーラビリティ を実現
  • モダンで親しみやすい 構文 と 豊富なツール群 を提供
  • 他のBEAM言語やJavaScriptとの 連携 が容易
  • 多様性と包摂性 を重視したフレンドリーなコミュニティ

Gleamの特徴と実行環境

  • Gleam は、 堅牢な型システム と 関数型プログラミング の表現力を持つ新しいプログラミング言語
  • Erlang仮想マシン（BEAM） 上で動作し、WhatsAppやEricssonなどの大規模システムで実績
  • 高並列・高耐障害性 を備えた実行環境
    • 数百万のグリーンスレッド を効率的に管理
    • イミュータブルなデータ構造 と 並列ガベージコレクタ による高速処理
  • 例：多数のスレッドを簡単に生成・管理できるGleamコード
    • list.range(0, 200_000) |> list.each(spawn_greeter)
    • 各スレッドが独立してメッセージを出力

開発体験とエコシステム

  • コンパイラ・ビルドツール・フォーマッタ・エディタ統合・パッケージマネージャ を標準搭載
  • 新規プロジェクト作成は gleam new コマンド一発
  • BEAMエコシステム の資産活用
    • Gleam, Erlang, Elixir製の 数千のパッケージ を利用可能
    • 例：gleam add gleam_jsonでJSONライブラリを即導入
  • テスト・ビルド・依存管理 もコマンドで簡単操作

安全性とメンテナンス性

  • null値・例外 を排除し、 明確なエラーメッセージ を提供
  • 実用的な 型システム による堅牢なコードベース
  • コード例：フィールド名のタイプミス時に 候補を提案
    • Did you mean 'name'?のような親切なメッセージ

マルチリンガルと相互運用性

  • BEAM上の他言語（ Erlang、Elixir）のコードを 直接利用 可能
  • JavaScriptへのコンパイル にも対応し、 TypeScript型定義 も自動生成
    • フロントエンドや他のJavaScript環境でも活用可能
  • 例：外部関数やDOM操作のコード例をサポート

コミュニティと多様性

  • 全ての人が歓迎される、フレンドリーで多様性を尊重するコミュニティ
    • 性別・経験・背景不問 で参加可能
    • コード・オブ・コンダクト を明示し、安心して参加できる環境を構築
  • Black lives matter や Trans rights are human rights など、多様性への明確な支持

まとめ・次のステップ

  • 公式ドキュメントの 言語ツアー でGleamの詳細を学習可能
  • ニュースレター で最新情報を入手
  • プライバシー保護 と 安心の運営体制

Hackerたちの意見

Gleamのアイデアはすごく好きなんだけど、2026年にあらゆる型のシリアライズを手動で実装したくないな。

└

この言語の最大の問題だね。でも、gleam/glanceでコード生成を実装するのはかなり簡単だよ。今のところ、良いライブラリがこれをうまくサポートしてない（例えば、分岐型のサポートとか）。[0] https://hexdocs.pm/glance/glance.html

└

Gleamのコードでは、あまりすべての型をシリアライズしないんだ。ざっくり計算したら、5%未満だね。

└

Dartにも同じような問題があるよ（そうそう、コード生成ライブラリを使えるけど、やっぱり同じじゃない）。

└

確かに。GleamはElixirとRustのミックスみたいなもので、どちらのシリアライズも明示的に実装する必要がないんだ。これは彼らが解決すべき課題だね。

数年前にAlpacaで遊んだことがあるけど、楽しかったな。ただ、生成されたコードが普通のErlangで書いたものよりもエラーが少ないとは思わなかった。見た目はイマイチだけど、Erlangのパターンマッチングを使った準ランタイム型付けは結構役立つし、「クラッシュさせろ」っていうErlangの哲学にも合ってると思う。正直言うと、これを言うとちょっと反発があるかもしれないけど、分散アプリケーションでは型システムの有用性が薄れてくる気がする。結局、送信されるのはビットだけだからね。ワイヤーはモナドや整数、文字列、ファンクタなんて気にしない。ただの1と0だし、型システムを強制することが逆に邪魔になることが多いと思う。ワイヤーを通るものには変なことや不確実性がたくさんあって、きれいな型ではそれを捉えきれないことが多い。まだGleamは試してないけど、やってみるつもりだし、これで考えが変わる可能性もあるから、受け入れる準備はできてるよ。

└

このコメントがよくわからないな。確かにワイヤーを通るのはビットだけど、両端点はそのデータをどう解釈するかを知っておく必要があるよね？型はそのための素晴らしいツールだよ。データとプロトコルのバージョンの検証にも使えるし、ワイヤープロトコルを正確に決めることもできる。だから、型が邪魔になるとは思えないんだけど、分散通信プロトコルを形作るための究極のツールだと思う。

└

面白いね！全然その意見には賛成できないけど、だってローカルで動いてるものも結局はビットだよね？CPUもモナドや整数、文字列、ファンクタなんて気にしないし。だけど、最終的には高レベルのコードはデータが何らかの不変条件に従うことを期待してる。個人的には、すべてを既知の型にパースしてから、そこから言語のネイティブなデータ構造で扱うのが正しいアプローチだと思う。

└

あなたは型システムについて根本的な誤解をしているようだね。ほとんどの（最高の？）型システムは消去される。つまり、コンパイル時にしか意味がなくて、コードが健全でできれば未定義動作がないことを保証するんだ。「ただのビット」っていうのは型の世界では意味がない。結局、機械語は人間が（実際には）書いたり読んだりしないものだから。

└

正直言って、これでちょっと反発を受けるかもしれないけど、それは全然構わない。分散アプリケーションでは型システムの有用性が薄れてくると思うんだ。結局、送信されるものはビットに過ぎないからね。実際、Gleamも似たような考えを持っていて、型安全な分散メッセージパッシングができるなんて思わせないし、何十年も続いているこの問題を解決しようとする罠にもはまってない。Gleamの分散コンピューティングでは、外部からのレスポンスを扱うのと同じように動的メッセージを処理することになる。ちょっとボイラープレートが増えるけど、型安全を装うか存在しないかの他の2つの選択肢よりはマシだと思う。

Elixirから来たんだけど、休暇中にGleamを数日試してみたよ。追求しないことにした理由は以下の通り：- アドホック多態性がない（関数のオーバーロードを除いて、たしか）から、物事の動作を定義する標準的な方法がない。まだ多くの慣習が整ってないから、自分のライブラリが例えばJSONのデシリアライズをサポートしているかどうかわからない - マクロがないから、JSONの（デ）シリアライズのような基本的な機能も自分で実装しなきゃいけない - 標準ライブラリや人気のあるライブラリの構造体でも - ファイルシステムにアクセスする方法を調べたら、標準ライブラリはAPIがJSとErlangのターゲット間で共有できないから、fsアクセスを提供してないことがわかった。一番人気のあるErlangターゲット用のfsパッケージも全然質が高くなさそうだった。こんな基本的で重要なことなのに。 - これで、ElixirはBEAM（「Erlang」）上で動くだけでなく、Erlangとのシームレスな相互運用があるのに対し、Gleamは最初からErlang / Elixirエコシステムのほとんどにアクセスできないことに気づいた。代数データ型やResult、Option型、パターンマッチングとデストラクチャリングなど、好きな点もたくさんあったけど、結局はRustが本当に欲しいんだなって思った。私の道はRustに続いてるのかな。

└

Elixirを9年やってて、そのうち5年はプロで使ってるけど、アドホックポリモーフィズムなんて誰も気にしないよ。コミュニティは「データ用」以外でプロトコルを使わないし、意味がわからん。どこにでもグローバルシングルトンプロセスがあるし、観察してる実践にがっかりしてるけど、それでも一番楽しい言語だね。

Hacker Newsで議論の続きを見る