Journal

Goは「現代のC言語」くらいでちょうどいい

Goの話をすると、すぐに「シンプル」という言葉で片づけられます。もちろんそれもあります。ただ、私が触っていて毎回いいと思うのは、もっと乾いた感触です。余計なものを先に要求してこない。そこがかなり大きいです。

少し前に、ダウンロードフォルダの更新ファイルを新しい順に5件だけ出す小さなCLIをGoで30分ほどで書きました。やっていることは地味です。でも、こういう地味な道具ほど毎日効きます。起動も速いですし、配るときも単体のバイナリで済みます。説明が短く終わる道具は、それだけでかなり偉いです。

余計なものを先に要求しない

Goの気楽さは、文法が少ないことだけではないです。最初の一歩で要求される前提が少ないです。ランタイムの空気を読みすぎなくていい。設定ファイルを何枚もめくる前に、main関数を書いて動かせます。ここがかなり好きです。

最近の開発環境は、コードを書く前に文化圏へ入門させてくることが多いです。このフレームワークではこの書き方、このビルドではこの作法、その周辺ツールではまた別の流儀、という具合です。あれはあれで便利ですが、正直しんどいです。私は自分のPCで動く小さな道具くらい、もっと勝手に触りたいです。

OSに近いのに、持ち運びが軽い

Goを「現代のC言語」と言いたくなるのは、この距離感のせいです。ファイル、プロセス、ソケット、HTTPのような硬いものに、妙に素直に触れます。なのに、昔のCみたいに毎回神経を削られるわけでもないです。機械の近くに立てるのに、持ち運びは軽い。そのバランスがいまでも珍しいです。

記事を書く前に、公式のGoコンテナで最低限の確認だけしました。手元で打ったのは次の3本です。

docker run --rm golang:1.24 go version
docker run --rm golang:1.24 go env GOOS GOARCH CGO_ENABLED
docker run --rm -e GOOS=windows -e GOARCH=amd64 golang:1.24 go env GOOS GOARCH

返ってきた値は、順番に go1.24.13 linux/amd64、既定環境の linux / amd64 / 1、そして切り替え後の windows / amd64 でした。大げさな話ではありません。Goはこういう場面で説明が短く済みます。対象を変えるときの発想が素直です。私はこの素直さをかなり信用しています。

考える場所が、ちゃんと残る

私は、AIにボイラープレートを書かせること自体はもう普通にやります。退屈な配線まで全部手で書きたいわけではないです。ただ、そのあとに残る設計まで曖昧になる道具は苦手です。Goはその点で都合がいいです。標準ライブラリが強いので、何を外に出して、何を自分で持つかを考える場所が残ります。

net/http などはまさにそうです。派手ではないですし、最初から全部入りでもないです。でも、入力を受けて、処理して、返すという流れが見えやすいです。フレームワークの流儀を覚える前に、まずHTTPそのものを考えられます。いまの私は、その順番のほうが楽しいです。

非エンジニアがAIに丸投げしてアプリを組み上げる話もよく見ますが、あれを見ていると少し冷めます。動いた瞬間だけなら気持ちいいのでしょうが、壊れたあとに誰が責任を持つのかがすぐ曖昧になります。自分の道具を自分で直せない状態は、便利というより借り物です。せめて自分のPCの上で動くものくらい、分解して見られるほうがいいです。

だから私は、Goをほめるときに「学びやすい言語です」より先に、「自分の手元へ責任を戻してくる言語です」と言いたくなります。昔のCそのものではありません。メモリ管理の苦味も、そのままの不便さもかなり薄いです。それでも、機械の近くで考えている感じだけは残ります。いまの自分には、そのくらいがちょうどいいです。

Previous