Vorschlag zur Aufnahme eines UUID-Pakets in die Go-Standardbibliothek

• Auf GitHub wird ein Vorschlag diskutiert, Funktionen zum Erzeugen und Parsen von UUIDs in die Standardbibliothek der Sprache Go aufzunehmen
• Der Vorschlag begründet dies damit, dass die meisten Go-Server- und Datenbankprojekte derzeit von externen Paketen wie github.com/google/uuid abhängen
• Wichtige Sprachen wie C#, Java und Python bieten bereits UUID-Unterstützung auf Ebene der Standardbibliothek
• In der Diskussion wurden UUIDv7 und andere aktuelle Spezifikationen, die Einhaltung von RFC 9562, der Umfang der Parsing-Funktionen und die Konsistenz der API als zentrale Streitpunkte behandelt
• Der Vorschlag wurde später mit dem Vorschlag zur Unterstützung von UUIDv4 und UUIDv7 im Paket crypto/rand (#76319) zusammengeführt und wird nun dort weiterverfolgt

---

Überblick über den Vorschlag

• Es wird vorgeschlagen, der Go-Standardbibliothek eine API zum Erzeugen und Parsen von UUIDs hinzuzufügen
  • Zielversionen sind UUID v3, v4 und v5
  • Als wichtigste Begründungen werden die Abhängigkeit von externen Paketen und die Standardunterstützung in anderen Sprachen genannt
• UUID ist ein internationaler Standard, definiert in RFC 4122 (später RFC 9562)
• Der Vorschlagsteller weist darauf hin, dass Go unter den wichtigen Sprachen ein ungewöhnlicher Fall ohne standardmäßige UUID-Unterstützung sei

Erste Reaktionen und Diskussion

• Einige Teilnehmer verwiesen darauf, dass es bereits früher ähnliche, aber abgelehnte Vorschläge gab (#23789, #28324)
  • Als Gründe wurden genannt, dass externe Pakete einfach genug zu verwenden seien und ihr Release-Zyklus flexibler sei als der der Standardbibliothek
• Der Vorschlagsteller argumentierte, wenn die meisten Projekte ohnehin jedes Mal ein externes Paket importieren müssten, sei es besser, dies direkt in den Standard aufzunehmen
• Als weiteres Argument zur Unterstützung wurde angeführt, dass viele Sprachen UUID in ihre kryptografiebezogene Standardbibliothek aufnehmen

Neuere UUID-Versionen und Berücksichtigung des RFC

• Einige Stimmen merkten an, dass UUID v1 bis v5 veraltet seien und v7 die modernste und vielversprechendste Version sei
  • Für v7 gibt es verschiedene Implementierungsoptionen, daher müsse man die praktischen Ergebnisse zunächst beobachten
• In einem RFC-Entwurf wird empfohlen, UUIDs nicht unnötig zu parsen, sondern als opake Identifikatoren zu behandeln
• Nach der offiziellen Veröffentlichung von RFC 9562 verlagerte sich die Diskussion auf die Unterstützung von UUIDv7

Überarbeitung und Zusammenführung des Vorschlags

• Im Jahr 2025 wurde nach der offiziellen Verabschiedung von RFC 9562 erwähnt, dass PostgreSQL 18 UUIDv7 unterstützt
• Anschließend startete das Go-Projekt einen separaten Vorschlag (#76319), der nur Funktionen zur Erzeugung von UUIDv4 und UUIDv7 im Paket crypto/rand hinzufügen soll
  • Parsing-Funktionen wurden entsprechend der RFC-Empfehlung ausgeschlossen
• Der ursprüngliche Vorschlag (#62026) wurde als Duplikat geschlossen

Diskussion zum API-Design

• Es wurde diskutiert, ob das Standardverhalten von uuid.New() v4 sein oder ob eine spätere Änderung möglich bleiben sollte
  • Einige schlugen vor, es dauerhaft auf v4 festzulegen, da ein Versionswechsel Kompatibilitätsprobleme verursachen könnte
• Diskutiert wurde auch, ob Methoden wie Compare, MustParse und Parse bereitgestellt werden sollten
  • Zu Compare hieß es, die Methode sei gemäß RFC nötig, um sortierbare UUIDs zu unterstützen
  • MustParse solle aufgenommen werden, um konsistent mit anderen Must*-Funktionen der Standardbibliothek zu bleiben
• Es wurde beschlossen, dass eine Methode IsZero() für den UUID-Typ unnötig ist
• Es wurden verschiedene Designvorschläge gemacht, etwa die Einführung einer Generator-Struktur oder die Trennung nach Versionstypen (UUIDv4, UUIDv7 usw.)
• Einige hielten die Funktion New() für zu mehrdeutig und schlugen vor, nur explizite Versionsfunktionen (NewV4, NewV7) anzubieten

Wichtige technische Streitpunkte

• Es wurde diskutiert, ob eine Definition der UUID-Sortierung nur für v6 und v7 klar existiert
• Geprüft wurden Umsetzungsansätze für zeitbasierte Sortierung bei UUIDv7 und zur Vermeidung von Kollisionen bei Gleichzeitigkeit (Counter-Methode)
• Aufgrund der unterschiedlichen Bedeutung je Version (z. B. v1 mit MAC-Adresse, v7 zeitbasiert) wurde auf Grenzen eines einheitlichen Typs hingewiesen
• Einige schlugen daher die Trennung nach Versionstypen und explizite Konvertierungsmethoden (AsV4(), AsV7() usw.) vor

Fazit und aktueller Stand

• Die Go-Community ist sich weitgehend einig, dass eine standardmäßige UUID-Unterstützung sinnvoll ist
• Um jedoch die Einfachheit der Standardbibliothek zu bewahren und die RFC-Empfehlungen einzuhalten, wurde folgender Kurs eingeschlagen:
  • Parsing-Funktionen werden ausgeschlossen
  • Nur Funktionen zur Erzeugung von UUIDv4 und UUIDv7 werden crypto/rand hinzugefügt
• Der ursprüngliche Vorschlag (#62026) wurde in den Vorschlag #76319 integriert und wird dort weiterverfolgt; damit ist die offizielle standardmäßige UUID-Unterstützung in Go einem Beschluss sehr nahe

[GN⁺]

Meinungen auf Hacker News

• Ich fand die Aussage interessant, dass UUID-Versionen 1 bis 5 bereits veraltet seien
  v4 hat aber weiterhin die höchste Zufälligkeit und wird als Primärschlüssel empfohlen, um in verteilten Datenbanken Hotspot-Probleme und Datenschutzprobleme zu vermeiden
  Referenzen: CockroachDB UUID-Dokumentation, Google Cloud Spanner UUID-Leitfaden

  • Ich fand diese Aussage auch seltsam. v7 ist gut, wenn Monotonie benötigt wird, aber der Zeitstempel kann Systeminformationen preisgeben. Deshalb ist v4 weiterhin sinnvoll
  • Ich halte die Formulierung „outdated“ für unpassend. Das Problem ist eine Nichtübereinstimmung der Anforderungen, nicht das Alter
    Jede UUID-Version, einschließlich v4, hat in bestimmten Situationen Schwächen. Tatsächlich definieren viele Organisationen statt Standard-UUIDs eigene reine 128-Bit-Werte
    Letztlich sind die Anforderungen komplexer geworden als es die ursprünglichen Designgrenzen von UUID erlauben
  • v4 ist die Standardwahl, und andere Versionen nutzt man nur dann, wenn ausdrücklich Ordnungserhalt gebraucht wird
  • Wenn man wirklich 128 Bit Zufälligkeit braucht, kann man einfach 128-Bit-Zufallszahlen verwenden. Man muss sie nicht in das UUID-Format zwängen
  • Aber v4 kann B-Tree-Einfügungen durcheinanderbringen. Ich habe gelernt, dass v7 wegen der Effizienz des Page-Cachings im Kernel deutlich schneller ist

• Ich fand es schön, dass heute auf HN einmal so eine kleine Go-bezogene Nachricht aufgetaucht ist
  In letzter Zeit geht es nur noch um die Zukunft des Programmierens oder um AI, daher wirkt so ein technisches Thema erfrischend

  • Es tut gut, nach langer Zeit wieder eine fundierte technische Diskussion zu sehen
  • Es ist angenehm, kurz dem AI-bezogenen FUD zu entkommen. Früher wurde ich nicht nervös, wenn ich HN geöffnet habe, aber in letzter Zeit reden alle nur noch davon, dass „alles untergeht“
  • Oberflächlich wirkt es wie ein kleines technisches Thema, aber tatsächlich ist es eine große Entscheidung, die Architektur der Sprache Go und die Richtung ihrer Führung beeinflusst
    Perfektionisten, praxisorientierte Entwickler und die Crypto-Community vertreten jeweils unterschiedliche Positionen
    Zugehöriges Dokument: RFC 9562
    Ich hoffe, dass Go die richtige Entscheidung trifft. Besonders TinyGo ist für Mikrocontroller wirklich großartig
  • Die Szenerie der Leute, die Go nicht mögen, ist unterhaltsam. Jetzt leben wir in einer Zeit, in der AI Code anschaut, und sogar der Spaß an Sprachkritik scheint verschwunden zu sein

• Dass Go die UUID-Erzeugung unterstützt, ist mir nicht so wichtig, aber ein standardisierter UUID-Typ ist wirklich bedeutsam
  Damit wären konsistentes Marshaling in JSON, Text, database/sql usw. möglich
  In einer aktuellen Analyse von Go-Abhängigkeiten war google/uuid das am zweithäufigsten verwendete Paket
  Zugehörige Analyse: The most popular Go dependency

  • Ich hätte auch gern einen standardmäßigen dec128-Typ. Ideal wäre eine Struct-Form, die sich leicht in uint128 umwandeln lässt

• Der Reiz von Go liegt eher in Pragmatismus als in spektakulären Features
  Die Sprache wird nicht so komplex, dass sie daran zerbricht, sondern fügt nur notwendige Funktionen hinzu

  • Ich habe kürzlich ebenfalls nach dem Überspringen mehrerer Versionen ein Upgrade gemacht und hatte keinerlei Probleme
    Dank der Kompatibilitätsgarantie kann man es beruhigt einsetzen. Veränderungen kommen langsam, aber die Sprache wird stetig besser

• Ich halte es für wichtiger, dass gofrs/uuid dem neuen Standard folgt und aktiv gepflegt wird, als dass das uuid-Paket von Google inaktiv geworden ist
  gofrs/uuid-Repository

  • Es macht Spaß, Bibliotheken ohne externe Abhängigkeiten zu bauen. Diese Änderung macht so etwas leichter
  • Aber bei google/uuid gab es seit 2024 keine Releases mehr, und selbst im Juni 2025 ist dazu noch ein Issue offen
    Issue #194
  • Über diesen Vorschlag wurde bereits seit drei Jahren diskutiert

• Ich hasse UUIDs wirklich. Es sind nicht menschenfreundliche Bezeichner
  Beim Debugging oder in Query-Ergebnissen sind sie viel zu lang und unpraktisch.
  Natürlich sind sie nützlich, wenn man systemübergreifend eindeutig getrennte IDs braucht, aber meist werden sie überstrapaziert
  Im Normalfall ist ein zentralisierter Nummernvergeber viel besser.
  Zum Beispiel ist etwas wie GetNextId in der DB deutlich menschlicher und effizienter

  • Früher haben wir in einer Firma Projekte mit sechsstelligen Codes verwaltet, und dann hat das jemand auf UUIDs umgestellt
    Das Ergebnis waren für Menschen unlesbare Codes, und weil es sogar eine Eigenimplementierung war, waren sie auf seltsame Weise noch sequentiell. Eine komplett missratene Entscheidung
  • Tatsächlich reicht in den meisten Fällen ein ganzzahliger Zähler
    Mit einer Zählertabelle in Postgres kann man zehntausende IDs pro Sekunde erzeugen
    Das verbessert sogar Speichernutzung, Kompressionseffizienz und Hashmap-Performance
    UUIDs sind bequem, ruinieren aber die Performance
  • Schön wäre ein menschenlesbares Element
    Zum Beispiel eine Form wie BASKETBALL-...-FISH mit einer wortbasierten Prüfsumme, damit man sie sich leichter merken kann
  • Es wurde „deterministische Randomisierung“ erwähnt, und ich denke ebenfalls, dass etwas wie ein LFSR (Linear Feedback Shift Register) dafür geeignet sein könnte

• Ich hatte mich gefragt, ob UUID wirklich zu Go hinzugefügt wird

  • Der Status ist derzeit „Likely accept“. Das lässt sich im Go-Projektboard nachsehen
    Wenn es keinen besonderen Widerspruch gibt, ist die Aufnahme sehr wahrscheinlich
  • Ja, es wird voraussichtlich hinzugefügt

• Kotlin hat ebenfalls kürzlich in Version 2.3 die Unterstützung für UUID-Versionen auf Basis von RFC 9562 in die Standardbibliothek aufgenommen
  Unterstützt werden JVM, JS, WASM und Native.
  Da das IETF-RFC inzwischen stabilisiert ist, ist es sinnvoll, dass Go nachzieht

• Es ist etwas schade, dass Go bei solcher Unterstützung grundlegender Funktionen schwach aufgestellt ist

  • Ich frage mich, welche Sprache so etwas besser standardisiert hat. Vielleicht Java? Python und Rust sind in einer ähnlichen Lage
  • Die Bedeutung von „batteries included“ hat sich in 20 Jahren stark verändert. Vielleicht war das intern bei Google einfach keine benötigte Funktion
  • UUID ist letztlich nur ein 16-Byte-Array. Einen v4-Generator schreibt man in ein paar Zeilen. Das ist keine große Sache
  • Ich frage mich, welche Funktionen genau als fehlend empfunden werden
    Persönlich fand ich das Logging-System von Go so schlicht, dass ich es selbst implementieren musste
    Das slog-Modul ist langsam und unhandlich. Es wirkt, als sei nur an Enterprise-Umgebungen gedacht worden
  • Trotzdem ist die Qualität der Standardbibliothek von Go auf höchstem Niveau. Ich halte sie für die im Alltag am häufigsten genutzte stdlib

• Ich habe darüber nachgedacht, ob man die DB-Cluster-Effizienz von v7 und zugleich die Zufälligkeit von v4 bekommen kann
  Intern könnte man v7 verwenden und es nach außen per XOR oder AES verschleiern

  • Tatsächlich gibt es so einen Versuch: uuidv47-Projekt
  • Wenn Datenschutz das Ziel ist, halte ich es für besser, einfach ganzzahlige Schlüssel zu verschlüsseln
    Mit einer Feistel-Verschlüsselung kann man zum Beispiel undurchsichtige öffentliche IDs erzeugen, ohne die Performance-Probleme von UUIDs in Kauf zu nehmen