Gleam を入れて最初の 1 行を動かす
この章を終えると、手元で gleam new・gleam run・gleam test が通り、エディタが Gleam のコードを読み、コンパイラ・モジュール・パッケージ・依存関係・テストを専門用語として使える。
この記事は、構成を Claude Opus が決め、本文を Gemini が書き、頁に組んだのは Claude です。
コード例の動作は Gleam 1.19.2 で確かめています(gleam_stdlib 1.0.5、gleeunit 1.11.0)。
この章では、手元の環境でプロジェクトの作成から実行、テストの動作確認までを行い、エディタで Gleam のコードを読める状態を整えます。あわせて、プログラムを動かす仕組みやファイル構成を表す、コンパイラ、モジュール、パッケージ、依存関係、テストといった専門用語を身につけます。第 1 部の設計メモを実際のプログラムへと写すための土台を手元に築き、Gleam の最初の 1 行を動かしましょう。
なぜ Gleam で書くのか
第 1 部では、社内の備品の貸し出し台帳を作るための設計メモを言葉でまとめました。第 2 部では、その設計メモを Gleam というプログラミング言語を使って実際のプログラムに写していきます。設計で決めた言葉の約束事を、コンピュータが動かせるプログラムに写し取る作業が実装です。
Gleam は、型を持つ言語です。第 1 部の設計メモでは、「短い名前」の型や、備品の種類の列挙型、NULL 可の日付といったデータの形を決めました。Gleam では、そうした設計メモで決めたデータの形を、そのまま Gleam の型として書き表すことができます。
人間が書いたプログラムを、コンピュータが動かせる形に変える道具があります。これをコンパイラと呼び、変えることをコンパイルと呼びます。Gleam のコンパイラは、コンパイルのときにプログラムのコード全体を読み、型の食い違いを見つけて処理を止めます。もし設計メモで決めた型と食い違うコードを書いてしまっても、プログラムを実際に動かす前にコンパイラが間違いを知らせてくれます。これは人間が自分で書いたコードだけでなく、AI に書かせたコードであってもまったく同じです。
ただし、コンパイラが見つけてくれるのは型の食い違いであり、設計との違いの全部を見つけてくれるわけではありません。型だけでは書き表せない業務の決まりは、この章の最後に出てくるテストという仕組みを使って確かめます。
Gleam で書いたプログラムは、Erlang の仮想マシンでも JavaScript の実行環境でも動きます。Dev Tour の第 2 部では、Erlang の側でプログラムを動かしていきます。
また、日々の作業で使う道具がまとまっている点も Gleam の特徴です。gleam という 1 つのコマンドの中に、新しいプロジェクトを作る、プログラムを動かす、テストを行う、コードの見た目を整形するといった道具が最初から揃っています。
入れるもの
Gleam でプログラムを動かすために、手元の環境に入れるものは 4 つあります。Gleam、Erlang、rebar3、そしてエディタです。プログラムをコンパイルして動かせる形にまとめる手順を受け持つ道具があります。これをビルドツールと呼びます。rebar3 は Erlang のビルドツールです。
具体的な導入手順は OS ごとに違います。そのため、この記事では手順そのものは書きません。和訳した公式の頁であるGleam のインストールの手順に従って、それぞれの環境に合わせて用意を進めてください。
Windows を使っている人には、WSL を勧めます。WSL とは、Windows の中で Linux を動かす仕組みのことです。このツアーの 2-8「SQLite」では、備品の貸し出し台帳のデータを保存するためにデータベースを使います。その際、C 言語のコンパイラが必要になる部品が入ってきます。WSL の中の Linux 環境を使っていれば、そうした部品の用意も Linux の手順 1 つだけで済みます。
道具の導入や確認を行うときは、文字を使って指示を入力します。文字でコンピュータに指示する画面があります。これをターミナルと呼び、そこに打つ指示をコマンドと呼びます。macOS なら「ターミナル」、Windows なら WSL の画面、Linux なら端末を開いて操作を進めます。
道具が入ったら、正しく用意できたかを確かめます。ターミナルを開いて、まずは gleam --version とコマンドを打ちます。
$ gleam --version
gleam 1.19.2続けて、rebar3 version とコマンドを打って確認します。
$ rebar3 version
rebar 3.27.1 on Erlang/OTP 28 Erts 16.4.0.6それぞれの版が表示されれば、正しく入っています。rebar3 version の出力には、rebar3 の版だけでなく、Erlang の版(OTP 28 など)も一緒に出ます。
この記事の出力をどの版の Gleam で取ったかは、頁の冒頭に示してあります。本文には版の数字を書きません。手元に入れた道具の版が冒頭の数字より新しい場合、画面に現れる細かい表示が違うことがありますが、そのまま進めて構いません。
プロジェクトを作る
道具の準備ができたら、備品台帳のプログラムを書いていく場所を作ります。Gleam のプログラムは、1 つのフォルダにまとめて書きます。このフォルダをプロジェクトと呼びます。ターミナルで gleam new ledger とコマンドを打つと、ledger という名前のプロジェクトが作られます。ledger は英語で「台帳」という意味です。
$ gleam new ledger
Your Gleam project ledger has been successfully created.
The project can be compiled and tested by running these commands:
cd ledger
gleam test
コマンドを実行すると、フォルダの中に必要なファイルが作られます。できたファイルの一覧を見てみましょう。
.github/workflows/test.yml
.gitignore
README.md
gleam.toml
src/ledger.gleam
test/ledger_test.gleam一覧には複数のファイルが並んでいますが、今気にするべきものは 3 つだけです。1 つ目は、プログラムの本体を書く src/ledger.gleam です。2 つ目は、テストを書く test/ledger_test.gleam です。そして 3 つ目は、プロジェクトの設定が書かれた gleam.toml です。
一覧の中にある .github/workflows/test.yml や README.md、.gitignore といったファイルは、開発を補助するためのものです。今は気にしなくて構いません。
プロジェクトができたら、cd ledger とコマンドを打って、できたフォルダの中に入ってから先へ進みます。gleam new ledger を打ったときの画面の出力でも、そのようにフォルダの中に入って進めるよう案内されています。
gleam.toml と依存関係
プロジェクトのフォルダにある設定ファイル gleam.toml を見てみましょう。gleam.toml には、プロジェクトの名前と、プログラムで使う部品が書かれています。
プログラムを作るときは、ほかの人が作って公開している部品を使うことがよくあります。ほかの人が作って公開している部品のまとまりをパッケージと呼びます。プロジェクトがパッケージを使うことを「依存する」と言い、使うパッケージの一覧を依存関係と呼びます。
[dependencies]
gleam_stdlib = ">= 1.0.0 and < 2.0.0"
[dev_dependencies]
gleeunit = ">= 1.0.0 and < 2.0.0"できたばかりの gleam.toml には、最初から 2 つのパッケージが入っています。1 つ目は gleam_stdlib です。これは Gleam の標準ライブラリです。言語の標準の部品集を標準ライブラリと呼び、文字列や数やリストを扱う関数が用意されています。2 つ目は gleeunit です。これはテストを動かすパッケージです。テストのときだけ使う部品なので、通常の依存関係とは分かれて [dev_dependencies] という別の欄に書かれています。普段の実行で使うパッケージは [dependencies] の欄に並びます。
なお、ファイルの中にある # で始まる行は説明書きです。プログラムの動作には影響しないので、今は読み飛ばして構いません。
動かす
プロジェクトのフォルダに入ったら、最初のプログラムを実際に動かしてみましょう。ターミナルで gleam run とコマンドを打って実行します。
$ gleam run
Resolving versions
Downloading packages
Downloaded 2 packages in 0.00s
Added gleam_stdlib v1.0.5
Added gleeunit v1.11.0
Compiling gleam_stdlib
Compiling gleeunit
Compiling ledger
Compiled in 0.28s
Running ledger.main
Hello from ledger!最初の 1 回は、いくつかの段階を経て動きます。まず、依存関係に書かれたパッケージをインターネットから取ってきます(Downloading packages)。次に、コンパイラがプログラムの全体をコンパイルします(Compiling)。そして最後に、出来上がったプログラムを動かします(Running ledger.main)。
画面の一番下の行に表示された Hello from ledger! が、プログラムが表示した文です。ここまで来れば、Gleam は手元の環境でしっかりと動いています。
Gleam ではファイル 1 つをモジュールと呼びます。プロジェクトの中にある src/ledger.gleam というファイルが ledger モジュールにあたります。画面に現れた Running ledger.main という表示は、「ledger モジュールの main を動かす」という意味です。main は、gleam run を実行したときに最初に動く場所です。
なお、2 回目以降に実行するときは、書き換えて変更したところだけをコンパイルするので、より素早く動きます。
最初の 1 行を書き換える
プログラムが動くことを確かめたので、次はコードの中身を自分の手で書き換えてみましょう。src/ledger.gleam を下のとおりに書き換えます。画面に表示する文を、備品の貸し出し台帳のものに変えてみます。
import gleam/io
pub fn main() -> Nil {
io.println(greeting())
}
pub fn greeting() -> String {
"備品の貸し出し台帳を始めます"
}詳しいコードの読み方は 2-2「値と型と関数」 で詳しく扱います。ここでは全体の形だけを見ておきましょう。先頭に書かれた import gleam/io は、画面への表示に使うモジュールである gleam/io を使うという宣言です。その下にある greeting は、台帳の挨拶文を 1 つ作って返す関数です。そして main は、その greeting が返した文を io.println に渡して 1 行表示します。
また、関数である greeting の前には pub が付いています。pub が付いているものは公開され、ほかのモジュールからも呼び出して使えるようになります。次の節で扱うテストのモジュールから greeting を使うために、あらかじめ pub を付けておきます。
ファイルを保存したら、ターミナルで gleam run と打って動かしてみましょう。
$ gleam run
Compiling ledger
Compiled in 0.16s
Running ledger.main
備品の貸し出し台帳を始めます画面の最後の行に表示される文が、新しく書き換えた台帳の挨拶文に変わったことを確かめてください。これで、自分の手でモジュールの中身を書き換えて動かすことができました。
テストを動かす
プログラムが思い通りに動いているかを自動で確かめる方法を見てみましょう。プログラムが決めたとおりに動くかを、別のプログラムで確かめるものがあります。これをテストと呼びます。
テストのファイルである test/ledger_test.gleam を、下のとおりに書き換えます。
import gleeunit
import ledger
pub fn main() -> Nil {
gleeunit.main()
}
pub fn greeting_test() {
assert ledger.greeting() == "備品の貸し出し台帳を始めます"
}ここで書いた greeting_test は、先ほど定義した greeting が返す文が決めたとおりになっているかを確かめるテストです。Gleam では、名前が _test で終わる pub の関数がテストとして動く決まりになっています。関数の中にある assert は、「この式が正しいはず」という宣言です。もし式が成り立たず正しくなければ、テストが落ちるようになっています。
書き換えたら、ターミナルで gleam test と打ってテストを動かします。
$ gleam test
Compiled in 0.15s
Running ledger_test.main
.
1 passed, no failures画面に 1 passed, no failures と出ました。これは「1 つ通り、落ちたものは無い」という意味です。テストが無事に通ったことが分かります。
では、テストが失敗したときの様子も確かめるために、わざとテストを落としてみましょう。test/ledger_test.gleam の中にある期待する文の最後を「始めます」から「始めました」に変えて保存し、もう一度 gleam test を打ってみます。
$ gleam test
Compiling ledger
Compiled in 0.16s
Running ledger_test.main
assert test/ledger_test.gleam:9
test: ledger_test.greeting_test
code: assert ledger.greeting() == "備品の貸し出し台帳を始めました"
left: "備品の貸し出し台帳を始めます"
right: "備品の貸し出し台帳を始めました"
info: Assertion failed.
0 passed, 1 failuresするとテストが落ちて、画面に詳しい結果が出ます。どの行の assert が落ちたか(test/ledger_test.gleam:9)がはっきりと示されています。さらに、プログラムが実際に返した左辺(left、実際の値)と、期待した右辺(right、期待した値)が並んで出ます。何が食い違っているのかが一目で分かります。確かめたら、書き換えた文を元の「始めます」に戻しておきます。
このように、テストは設計メモの決まりのうち型で書けないものを確かめる道具になります。コンパイラによる型の確認と組み合わせることで、意図どおりの実装を確かめられます。テストは 2-6「テスト」 で本格的に使っていきます。
エディタに Gleam を読ませる
コードを書いていくために、エディタで Gleam のプログラムを快適に読めるようにしましょう。エディタの横で Gleam のコードを読み、間違いに印を付けたり型を教えたりするプログラムがあります。これを言語サーバと呼びます。Gleam の言語サーバは gleam のコマンドに同梱されていて、gleam を手元に入れた時点で一緒に入っています。
エディタに VS Code を使っているなら、公式の Gleam のプラグインを入れるだけで準備ができます。プラグインを入れて Gleam のファイルを開いたときに、言語サーバが自動的に動きます。VS Code 以外のエディタを使う場合は、和訳のGleam のインストールの「エディタ対応」の節に従って用意を進めてください。
言語サーバが動いているかを確かめてみましょう。src/ledger.gleam を開き、文を囲む " を 1 つ消してみます。ファイルを保存する前後のタイミングで、エディタが間違いを見つけて赤い印を付ければ、言語サーバが正常に動いています。確かめたら、消した " を元に戻しておきます。
この章のまとめ
この章では、手元の環境で gleam new、gleam run、gleam test の各コマンドが通り、エディタが Gleam のコードを読めるようになりました。また、プログラムを動かす仕組みやファイル構成を表す、コンパイラ、モジュール、パッケージ、依存関係、テストといった専門用語を使えるようになりました。これで、備品の貸し出し台帳の実装を進めるための最初の土台がしっかりと整いました。
次の章(2-2「値と型と関数」)では、src/ledger.gleam に書いた値、型、関数を、1 つずつ読めるようにしていきます。それぞれの書き方と働きを丁寧に見ていきましょう。