{
  "$type": "site.standard.document",
  "canonicalUrl": "https://rednafi.com/shards/2026/04/go-uuid/",
  "description": "Notes on Go's newly accepted uuid proposal and the tradeoffs behind the API.",
  "path": "/shards/2026/04/go-uuid/",
  "publishedAt": "2026-04-19T00:00:00.000Z",
  "site": "at://did:plc:fgtm2c26vfcj74rfmeggbyqj/site.standard.publication/3mnl6f7ob462z",
  "tags": [
    "Go",
    "API"
  ],
  "textContent": "It's good to see that Go is finally getting uuid in the standard library. The [proposal]\nwas accepted on April 8. I hadn't been following the conversation in the thread and only\nfound out about it from [Cup o' Go episode 154].\n\n[google/uuid] is usually one of the first extra imports I add to a Go service that talks to\na database, so this one has felt overdue for years.\n\nPython, Java, and Chave had native UUID support for years. I often use python -m uuid\nwhenever I need a one-off UUIDv4, and [Python 3.14+] added python -m uuid -u uuid7 to get\nUUIDv7s. So Go's not having it in the stdlib has always felt odd to me.\n\nThe accepted API is much smaller than google/uuid. The thread landed on a package that\ncovers the common cases and leaves the rest alone.\n\nThe package is uuid, not crypto/uuid, which makes more sense to me. The stdlib's\ntype UUID [16]byte matches google/uuid, so conversion basically requires a single cast.\nParse accepts the same string forms as google/uuid: dashed strings, braces, urn:uuid:\nprefixes, and bare 32-character hex. If someone changes the import path and the code still\ncompiles, it should still run.\n\nThe API keeps generation and parsing front and center. It adds NewV4() and NewV7(),\nkeeps a plain New() for the common case, and leaves most of the inspection surface from\ngoogle/uuid out.\n\nI had expected New() to resolve to v7 because that is where most UUID discussion has moved\nover the last two years. Go went with v4 instead. v7 is better for insertion locality in\nB-tree indexes, which is great if you're planning to use UUIDs as primary keys in Postgres\nor MySQL. But it also puts creation time in the ID and makes ordering visible.\n\nIf your system benefits from v7, you'll call NewV7() directly.\n\nThere's no v1, v3, v5, v6, or v8 constructor. There's no Version(), Time(), NodeID(),\nor other API for pulling fields back out of the bytes. The package is trying to set a common\nUUID type for Go and cover the common cases instead of absorbing every feature from the\nthird-party packages.\n\nThere's already a follow-up issue asking if Nil() should become Zero(). I would have\npicked Zero(), because nil means something specific in Go and [16]byte is not that.\nBut the [RFC] calls it Nil, the existing Go packages call it Nil, and the [rename issue] is\nleaning toward decline.\n\nThe proposal is accepted, but there is no target Go release attached to it yet. But I'm\nhoping that it lands on 1.27.\n\n\n\n\n[proposal]:\n    https://github.com/golang/go/issues/62026\n\n[google/uuid]:\n    https://github.com/google/uuid\n\n[Python 3.14+]:\n    https://docs.python.org/3/library/uuid.html#command-line-usage\n\n[Cup o' Go episode 154]:\n    https://cupogo.dev/episodes/a-nil-by-any-other-name\n\n[RFC]:\n    https://www.rfc-editor.org/rfc/rfc9562.html\n\n[rename issue]:\n    https://github.com/golang/go/issues/78612",
  "title": "Accepted proposal: UUID in the Go standard library"
}