ハクソク

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

UUIDパッケージがGo標準ライブラリに追加される

45日前原文(github.com)

概要

  • UUID生成・解析パッケージの標準ライブラリ追加提案
  • バージョン3, 4, 5のUUID対応要望
  • github.com/google/uuidの広範な利用実態
  • 他言語（C#, Java, JavaScript, Python, Ruby）との比較
  • Go標準ライブラリの現状への問題提起

Go標準ライブラリへのUUIDパッケージ追加提案

  • サーバーやDB関連のGoプログラムでUUID生成・解析が頻繁に必要
  • github.com/google/uuidが事実上のデファクトスタンダード
  • GitHub検索でも多くのプロジェクトでこのパッケージが利用されている現状
  • UUIDは国際標準規格（RFC 4122）に準拠している
  • github.com/google/uuidのインターフェースは長期間安定している
  • 標準ライブラリにUUID対応がないのはGoの例外的状況

他言語標準ライブラリとの比較

  • **C#**ではSystem.GuidとしてUUID（GUID）サポート
  • Javaではjava.util.UUIDクラスが標準で利用可能
  • JavaScript（特にNode.js）やPython、RubyもUUID生成・解析を標準搭載
  • これらの言語では追加インストール不要でUUID利用が可能
  • Goのみが標準ライブラリでUUIDをサポートしていない現状

標準ライブラリ追加の意義

  • サードパーティ依存削減によるセキュリティ向上
  • コードの可搬性・保守性の向上
  • UUIDの標準的な利用促進によるエコシステムの強化
  • 他言語と同様の開発体験の提供

まとめ

  • Go標準ライブラリにUUID生成・解析機能を追加することで、開発効率と安全性の向上
  • 他言語と同等の利便性確保
  • バージョン3, 4, 5への公式対応による互換性維持

Hackerたちの意見

Googleのパッケージの非活動に焦点が当たってるのが不思議なんだけど、https://github.com/gofrs/uuidは新しい標準に準拠してるし、ちゃんとメンテナンスもされてるのにね。
└
uuidパッケージはちゃんとメンテされてるけど、2024年以降リリースがないんだよね。実際、2025年6月にはそれについてのオープンな問題も出てるよね。: https://github.com/google/uuid/issues/194
└
外部依存がないライブラリを公開するのが楽しいんだよね。理由はどうあれ、この変更でそれがもっと簡単になるよ。
└
この提案は3年前のものだよ。
Golangがこういう基本的なことにサポートがないのは、ほんとイライラするわ。
└
「バッテリー同梱」っていう考え方がこの20年でかなり変わったよね。Goの quirks のほとんどと同じように、Googleは別に必要なかったんじゃないかな。
└
次はJavascriptやってみて。
└
標準ライブラリでこういう決定がもっと固定されてる言語って何だと思う？Ruby、Python、Rust、Javascriptじゃないのは分かってるけど、Javaかな？Elixirがこれをうまくやってるとは思えないんだけど。
└
https://github.com/rs/xid
└
他にどんな基本的なことを考えてるの？
└
UUIDって、16バイトの配列か64ビットの整数が2つ並んでるだけだよ。UUIDv4を生成するのも数行のコードでできるし、そんな大したことじゃないと思うけど。
└
Goはどの言語よりも標準ライブラリが優れてると思う。日常のプログラミングで最も使われる言語だと言っても過言じゃない。無駄なことはやめて。
└
GitHubで実装を探すことになるけど、それが後でハイジャックされて悪用される可能性があるよね。
コメント欄がドラマだらけだね。
└
https://phk.freebsd.dk/sagas/bikeshed#the-bikshed-email
└
基本的に、誰かが自分と意見が違うとキレてるだけだね。
└
サーバー向けの言語でUUIDが標準パッケージの一部じゃないって議論するのはちょっとおかしいよね。だったら、暗号関数とか他の大きな機能もいらないってことになるじゃん、サードパーティのライブラリで十分っていうならさ。
└
どんなGoスレッドにもようこそ。
Goニュース界隈は今日はスローペースかな？ :) こんな些細な技術的な話題がHNのトップページに載るのを見ると、他ではプログラミングが職業として終わったのかとか、AIが人類を奴隷にするかどうかが議論されてるのに、なんかほっこりするね。 :)
└
AIの不安をちょっと忘れられるのはいいね。昔はHNを見てもすぐに不安にならなかったのに、今はコメント欄を開くと「お前はダメだ」みたいなコメントばっかり見つかるからさ。
会話の流れからすると、実際に来るの？
└
うん。
└
現在「おそらく受け入れられる」ってリストされてるよ。https://github.com/orgs/golang/projects/17/views/1 つまり、何か新しいことが出てこない限り、進むってことだね。
UUIDを実装する時はいつもデータベース用で、PostgreSQLみたいなやつが処理してくれるんだ。こういう機能が開発されてるのは嬉しいけど、完全にテストされたUUIDの仕様を使う代わりにランダムな文字列生成器を使ってたかも。
Goの好きなところは、派手な最新の流行機能じゃなくて、言語が崩壊するかアップグレードが地獄になるまで、役に立つものを追加して邪魔しないところ。
> UUIDのバージョン1、2、3、4、5はもう古いね。面白いコメントだね。v4は最大のランダムビットを提供する唯一のバージョンで、いくつかの分散データベースで非相関行のプライマリキーとして使うのが推奨されてるんだ。ホットスポットやプライバシーの問題に対抗するためにね。 編集: 参考のためのリンク、これらはUUIDv4を推奨してるよ: https://www.cockroachlabs.com/docs/stable/uuid https://docs.cloud.google.com/spanner/docs/schema-design#uui...
└
そうだね、v4が基本だし、特別な理由がない限り他のを使うことはないよ。例えば、ざっくりとした順序が必要な場合とか。
└
本当に？v4ってローカルでB-Treeへの挿入を結構ごちゃごちゃにしない？メモリ効率の良いページングのおかげで、v7を使うと書き込みがかなり早くなるって教わったんだけど（v4だと次の書き込みのページが完全にランダムになるから、これが失われるんだ）。
Kotlinも最近、バージョン2.3でRFC 9562（新しいUUIDバージョンを含む）を標準ライブラリに追加したよ。マルチプラットフォーム実装だから、ネイティブ、wasm、jvm、jsでも動くんだ。IETFのRFCが数年前に出てるから、デフォルトでそれを使うのは理にかなってると思う。だから、Goもこれをサポートするのはいいことだね。
Goは、仕事の中で一番楽しい部分だよ。