📬

Goの言語仕様・標準ライブラリの機能提案を追うためのサイトを作った

に公開
Go
GitHub Actions
個人開発
Claude
tech

Go 言語では、Proposal という形で言語仕様・標準ライブラリへの機能変更提案が行われます。Proposal は大まかに以下のような流れで、リリースが行われます。

  1. GitHub の issue で起票
  2. コメントなどで議論
  3. accept / decline が決定
  4. 実装
  5. リリース

この流れは Google の Go 開発チームの行う機能変更であっても同様で、Proposal を追うことで Go の将来をいち早く知ることができます。また、議論の中で開発チームの考え方などが見えてくるのも、面白いポイントです。
しかし、Proposal の数は現在約30個と多く、それら全ての議論の流れを追うことは困難です。
そこで、毎週の Proposal のステータス変化を議論の流れ・経緯まで含めて追えるサイトを作りました。この記事ではこのサイトについて紹介していきます。
https://go-proposal-weekly-digest.mazrean.com/

Go 言語における Proposal

Go 言語では、機能提案が Proposal という形で管理されます。
詳細は https://go.googlesource.com/proposal/+/master/README.md に記載されていますが、この記事において重要なのは以下です。

  • GitHub issue として投稿後、コメントなどで議論がされる
  • 大まかに以下の6つのステータスがある[1]
    • Active: 議論中。
    • Likely Accept: Accept 前の反対意見の待機期間。問題が出なければ翌週 Accept。
    • Accept: 提案を受け入れることが決定した状態。
    • Likely Decline: Decline 前の反対意見の待機期間。何もなければ翌週 Decline。
    • Decline: 提案を却下することが決定した状態。
    • Hold: 別 proposal が blocker になっているなどで、議論保留。
  • ほぼ毎週行われる Go 開発チームのミーティングで議論が行われる
    • ミーティング後のステータスは proposal: review meeting minutes でコメントされる
      • ただ、議論の流れまでは記載されない
    • 「ほぼ」毎週で、スキップ・リスケされることもある
      • 実際、先週は何らかの事情でスキップされたと思われる
      • このあたりは皆さんの会社などの定例ミーティングと同じ感じなのだと思います

オープンでその気になれば誰でも状況を把握して議論に参加できるようにはなっており、実際proposal: review meeting minutesを subscribe している人はそこそこいる印象です。
ただ、経緯まで把握しようとすると、なかなかに手間がかかり毎週全ての状況変化を追い続けるのはなかなかに難しいです。少なくとも自分は追い切れなくなり、ほとんど見ない状態になっていました。

Go Proposal Weekly Digest

そこで作ったのが、Proposal のステータス変動まとめサイト「Go Proposal Weekly Digest」です。

このサイトでは、毎週 proposal: review meeting minutes のコメントを基にステータスが変更された Proposal を取り出して、LLM にまとめさせた結果を公開しています。
まとめる過程では経緯・議論の流れを明確化するのを重視しており、大本の issue や関連 issue などのコメント、Web 検索などをさせて、背景情報を明確化させています。
また、Proposal の機能追加前後でのコード例なども出すようにしており、使用者視点での変化がわかりやすくなっています。

また、RSS も提供しているので Slack で購読して、毎週習慣的に確認したりコミュニティでワイワイ話すのもやりやすくしています。
https://go-proposal-weekly-digest.mazrean.com/feed.xml

仕組みとしては、Claude Code Action を GitHub Actions の Cron Trigger で動かすようにしています。proposal ごとに subagent を用いて ghコマンドや Web Search で調査を行わせて、出力された markdown を静的サイト化しています。
Claude Max の契約をもともとしていたため、自分が Claude をほぼ使わない時間にCron を動かすことで実質的な運用コストはない状態にしており、今後も継続して更新される状態になっています。
このあたりのアイデア自体も割と面白いと思っているので、いずれ単体で記事としてまとめたい気持ちがあります。

例: 「crypto/uuid: add API to generate and parse UUID」

ここからは、以下を例に実際のまとめの例を示しつつ、面白さや解像度の向上効果を感じていただければと思います。
https://go-proposal-weekly-digest.mazrean.com/2026/w05/62026

まず、この Proposal 自体の説明ですが、

Go標準ライブラリに crypto/uuid パッケージを追加し、UUIDの生成とパース機能を提供する提案

です。多くの方が使っている UUID ですが、Go ではこれまで標準ライブラリが提供されておらずサードパーティライブラリを使う必要がありました。これを標準ライブラリに入れたらどうか？という提案です。

次に、ステータスの変動ですが、

(未設定) → Active

とあるとおり、この週に追加されて議論が開始されたようです。ただ、ここで面白いのが以下の部分で、

過去に2018年（#23789）と2019年（#28324）に同様の提案が却下されていましたが、今回は標準ライブラリ入りに向けて前向きな検討が進んでいます。

の部分で、実は過去に UUID の標準ライブラリ化は2度却下されているんですよね。一方で、今回はどうやら前向きらしいです。

この変化の理由が背景部分で記されています。

Go開発者は現在、UUID生成のためにgithub.com/google/uuidなどのサードパーティパッケージを利用しています。このパッケージは10万以上のプロジェクトで使用される事実上の標準となっていますが、以下の課題があります:

  • メンテナンス体制の不透明性: 2025年以降、メンテナーの応答が鈍く、UUIDv8サポートのPRが半年以上放置されるなど、プロジェクトの持続可能性に懸念が生じています
  • 他言語との差: C#、Java、JavaScript、Python、RubyなどはUUID生成機能を標準ライブラリに含んでいますが、Goは例外的に含んでいません
  • RFC 9562の正式化: 2024年5月にUUID仕様がRFC 9562として正式化され、UUIDv7が新たに標準化されました

まず、Go で広く使用されていた UUID ライブラリのメンテナンス体制に懸念が生まれていることが大きい要素としてあるようです。そのうえで、UUID v7 が追加されたのもあり、タイミングとしてもちょうどよいのではないか？という背景があるようです。

そのうえで、API 形式を見ていくと、以下のコード例がなかなか面白いです。

// Before: サードパーティパッケージの利用
import "github.com/google/uuid"
id, err := uuid.NewRandom()
if err != nil {
    // 実際にはほぼ発生しないエラー処理
    return err
}
idStr := id.String()
// After: 標準ライブラリの利用
import "crypto/uuid"
id := uuid.New()  // エラーなし（crypto/randの改善により）
idStr := id.String()

サードパーティライブラリでは uuid を生成する際に毎度エラーハンドリングが必要で面倒だったのですが、今回の導入時には crypto/rand の改善でエラーハンドリングを消せるらしいです。個人的にはかなり嬉しい変化です。

最後に、議論のハイライトを見ると、

タイムスタンプオフセット論争: PostgreSQL 18やPercona MySQLが実装したタイムスタンプオフセット機能（プライバシー保護）を標準で含めるべきかが議論されましたが、novelな機能として見送りに

や

最小限のAPI方針: 当初はgithub.com/google/uuidをそのまま標準ライブラリに含める案もありましたが、SetNodeIDなどの不要な機能を排除し、80-90%のユースケースをカバーする最小APIに収束

など、Go の必要十分な機能のみを標準ライブラリで提供しようという考えの強さが見えてきます。

まとめ

今回は、Go 言語では、Proposal のステータス変動の背景などを知れるサイトを作り、紹介しました。

普段、プログラミング言語を使うだけだとどうしてもプログラミング言語も開発チームがいて、意思決定の積み重ねで作られているということを忘れがちな気がします。この機会に Proposal を通して、開発チームの考え方などを感じてより近くに感じてもらえるとよいかな、と思ったりします。そのうえで、興味があれば GopherCon などに参加すると、実際に Go の開発チームと話せるので、是非挑戦してみてください。自分は去年 Gophers EX という Gopher の海外進出を手助けするプロジェクトの力を借りていってきたのですが、本当に普通に Go チームに会って話せます。

また、Claude Code Action の活用事例としても割と面白いと思っているので、そちらについてもいずれ記事としてまとめたいと思います。

脚注

  1. 厳密には議論前の Incoming もあるが、トリアージされておらず玉石混合でここから見る価値は薄いと判断して抜いています。 ↩︎

Discussion