Proposition d’ajout d’un package UUID à la bibliothèque standard de Go

• Une proposition visant à inclure les fonctions de génération et d’analyse des UUID dans la bibliothèque standard du langage Go est en discussion sur GitHub
• L’auteur de la proposition fait valoir que la plupart des projets Go côté serveurs et bases de données dépendent aujourd’hui de packages externes comme github.com/google/uuid
• De grands langages comme C#, Java et Python offrent déjà une prise en charge des UUID au niveau de la bibliothèque standard
• Au fil des échanges, plusieurs points clés ont été débattus, notamment les spécifications récentes comme UUIDv7, la conformité à la RFC 9562, le périmètre des fonctions d’analyse et la cohérence de l’API
• La proposition a ensuite été fusionnée dans une autre proposition en cours, ajoutant la prise en charge d’UUIDv4 et UUIDv7 au package crypto/rand (#76319)

---

Aperçu de la proposition

• Proposition d’ajouter à la bibliothèque standard de Go une API de génération et d’analyse d’UUID
  • Versions visées : UUID v3, v4 et v5
  • Principaux arguments : la dépendance aux packages externes et l’existence d’un support standard dans d’autres langages
• Les UUID sont un standard international défini par la RFC 4122 (puis par la RFC 9562)
• L’auteur souligne que Go constitue, parmi les grands langages, un cas exceptionnel sans prise en charge standard des UUID

Réactions initiales et discussions

• Certains participants ont rappelé que des propositions similaires avaient déjà été soumises par le passé puis rejetées (#23789, #28324)
  • Motifs invoqués : l’usage de packages externes est suffisamment simple, et leur cycle de publication est plus flexible que celui de la bibliothèque standard
• L’auteur rétorque que si la plupart des projets doivent importer un package externe à chaque fois, il vaut mieux l’intégrer directement au standard
• Le fait que de nombreux langages incluent les UUID dans leur bibliothèque standard liée à la cryptographie a aussi été avancé comme argument en faveur de la proposition

Prise en compte des versions récentes d’UUID et de la RFC

• Certains avis estiment que les UUID v1 à v5 sont dépassés, et que v7 est la version la plus récente et la plus prometteuse
  • v7 laisse place à diverses options d’implémentation, et il est jugé utile d’observer les retours d’usage
• Le brouillon de la RFC recommande de ne pas analyser les UUID inutilement et de les traiter comme des identifiants opaques
• Après la publication officielle de la RFC 9562, la discussion s’est déplacée vers une prise en charge centrée sur UUIDv7

Révision et fusion de la proposition

• En 2025, après la formalisation de la RFC 9562, il a été mentionné que PostgreSQL 18 prend en charge UUIDv7
• Côté Go, une proposition distincte a ensuite été lancée pour ajouter uniquement les fonctions de génération d’UUIDv4 et UUIDv7 au package crypto/rand (#76319)
  • Les fonctions d’analyse en sont exclues conformément aux recommandations de la RFC
• La proposition initiale (#62026) a été fermée comme doublon

Discussions sur la conception de l’API

• Débat sur le comportement par défaut de uuid.New() : faut-il le fixer à v4 ou laisser la porte ouverte à un changement futur ?
  • Certains estiment qu’un changement de version poserait des problèmes de compatibilité, et proposent donc de le figer définitivement sur v4
• Discussion sur l’ajout de méthodes comme Compare, MustParse et Parse
  • Pour certains, Compare est nécessaire afin de prendre en charge les UUID pouvant être triés, conformément à la RFC
  • MustParse serait inclus pour rester cohérent avec les autres fonctions Must* de la bibliothèque standard
• Il a été conclu que la méthode IsZero() n’était pas nécessaire pour un type UUID
• Diverses pistes de conception ont été proposées, comme l’introduction d’une structure Generator ou la séparation par types selon les versions (UUIDv4, UUIDv7, etc.)
• Certains ont aussi jugé la fonction New() trop ambiguë et proposé de ne fournir que des fonctions de version explicites (NewV4, NewV7)

Principaux enjeux techniques

• Débat sur le point de savoir si la définition du tri des UUID n’est clairement établie que pour v6 et v7
• Examen des méthodes d’implémentation permettant de garantir le tri temporel lors de la génération d’UUIDv7 et d’éviter les collisions en concurrence (via un mécanisme de compteur)
• Des différences de sens selon les versions — par exemple, v1 inclut une adresse MAC tandis que v7 est basé sur le temps — ont mis en lumière les limites d’une conception à type unique
• Certains ont proposé de séparer les types par version et d’ajouter des méthodes de conversion explicites comme AsV4() ou AsV7()

Conclusion et état actuel

• La communauté Go semble globalement d’accord sur la nécessité d’un support standard des UUID
• Cependant, afin de préserver la simplicité de la bibliothèque standard et de respecter les recommandations de la RFC :
  • les fonctions d’analyse sont exclues
  • seules les fonctions de génération d’UUIDv4 et UUIDv7 seraient ajoutées à crypto/rand
• La proposition initiale (#62026) a été intégrée à la proposition #76319 et suit désormais cette voie,
  ce qui place la prise en charge standard des UUID dans Go à un stade proche de l’officialisation

[GN⁺]

Avis sur Hacker News

• J’ai trouvé intéressant qu’on dise que les UUID versions 1 à 5 sont déjà dépassés
  Pourtant, v4 reste celui qui offre le plus d’aléa et il est toujours recommandé comme clé primaire pour éviter les hotspots et les problèmes de confidentialité dans les bases de données distribuées
  Liens de référence : documentation UUID de CockroachDB, guide UUID de Google Cloud Spanner

  • Moi aussi, j’ai trouvé ça étrange. v7 est utile quand on a besoin de monotonie, mais son horodatage peut divulguer des informations système. Donc v4 reste tout à fait pertinent
  • Je trouve le terme « outdated » inadapté. Le vrai problème, c’est l’inadéquation avec les besoins, pas l’âge
    Chaque version d’UUID, y compris v4, présente des défauts dans certains contextes. En pratique, beaucoup d’organisations définissent et utilisent leurs propres valeurs 128 bits pures au lieu d’UUID standard
    Au final, les exigences sont devenues trop complexes pour les limites de conception des UUID
  • v4 est le choix par défaut, et on n’utilise d’autres versions que lorsqu’on a spécifiquement besoin de préserver l’ordre
  • Si on a vraiment besoin de 128 bits d’aléa, il suffit d’utiliser un nombre aléatoire de 128 bits. Pas besoin de le faire rentrer de force dans le format UUID
  • Mais v4 peut complètement dégrader les insertions B-Tree. À cause de l’efficacité du page caching du noyau, j’ai appris que v7 est bien plus rapide

• Je suis content de voir aujourd’hui sur HN une petite actu Go sans prétention
  En ce moment, on ne parle que du futur de la programmation ou d’IA, donc ce genre de sujet technique fait du bien

  • Ça fait plaisir de revoir une discussion technique approfondie
  • Ça repose l’esprit de faire une pause loin de la peur liée à l’IA (FUD). Avant, ouvrir HN ne me rendait pas anxieux, alors que ces temps-ci tout le monde ne parle que de catastrophe imminente
  • En apparence, c’est un petit sujet technique, mais en réalité c’est une grande décision qui influence l’architecture du langage Go et l’orientation de son leadership
    Les perfectionnistes, les développeurs pragmatiques et la communauté crypto ont chacun une position différente
    Document lié : RFC 9562
    J’espère que Go prendra la bonne décision. TinyGo, en particulier, est vraiment formidable pour les microcontrôleurs
  • Le paysage des gens qui n’aiment pas Go est amusant. On est maintenant à l’époque où l’IA lit le code, et le plaisir de critiquer les langages semble s’être évaporé

• Je me soucie peu du fait que Go prenne en charge la génération d’UUID, mais l’existence d’un type UUID standard est vraiment importante
  Cela permettra un marshaling cohérent avec JSON, Text, database/sql, etc.
  Dans une analyse récente des dépendances Go, google/uuid était le deuxième package le plus utilisé
  Analyse associée : The most popular Go dependency

  • J’aimerais aussi qu’un type dec128 entre dans le standard. L’idéal serait une struct facile à convertir en uint128

• L’attrait de Go vient de sa praticité plus que de ses fonctionnalités tape-à-l’œil
  Le langage n’accumule pas de complexité au point de s’effondrer, et n’ajoute que les fonctionnalités nécessaires

  • J’ai moi-même fait récemment une mise à niveau en sautant plusieurs versions, sans aucun problème
    Grâce à la garantie de compatibilité, on peut l’utiliser en confiance. Les changements sont lents, mais le langage s’améliore régulièrement

• Plus que l’inactivité du package uuid de Google, je trouve plus important que gofrs/uuid suive les nouveaux standards et soit maintenu activement
  dépôt gofrs/uuid

  • J’aime créer des bibliothèques sans dépendances externes. Ce changement rendra ce travail plus facile
  • Mais google/uuid n’a pas publié de release depuis 2024, et un ticket lié était encore ouvert en juin 2025
    ticket #194
  • Cette proposition était déjà en discussion depuis 3 ans

• Je déteste vraiment les UUID. Ce sont des identifiants peu conviviaux pour les humains
  Pour le débogage ou dans les résultats de requête, c’est beaucoup trop long et peu pratique.
  Bien sûr, c’est utile quand il faut des ID uniques entre des systèmes totalement séparés, mais la plupart du temps on en abuse
  Dans le cas général, un générateur centralisé de numéros est bien meilleur.
  Par exemple, une procédure DB comme GetNextId est plus humaine et plus efficace

  • Dans une ancienne entreprise, on gérait les projets avec des codes à 6 chiffres, puis quelqu’un les a remplacés par des UUID
    Résultat : les codes sont devenus illisibles pour les humains, et en plus c’était une implémentation maison bizarrement séquentielle. Une décision complètement ratée
  • En réalité, dans la plupart des cas, un compteur entier suffit
    Avec une table de compteurs dans Postgres, on peut générer des dizaines de milliers d’ID par seconde
    On y gagne en mémoire, en compression et en performances des hash maps
    Les UUID sont pratiques, mais ruinent les performances
  • J’aimerais qu’il y ait un élément plus facile à lire pour les humains
    Par exemple : BASKETBALL-...-FISH, avec une somme de contrôle basée sur des mots, ce serait plus facile à mémoriser
  • On a évoqué une « randomisation déterministe », et je pense aussi qu’une approche de type LFSR (registre à décalage à rétroaction linéaire) pourrait être valable

• Je me demandais si les UUID allaient vraiment être ajoutés à Go

  • Pour l’instant, le statut est « Likely accept ». On peut le voir sur le tableau de bord du projet Go
    S’il n’y a pas d’opposition particulière, il y a de fortes chances que ce soit inclus
  • Oui, c’est prévu

• Kotlin aussi a récemment ajouté, dans sa version 2.3, la prise en charge des versions d’UUID basées sur la RFC 9562 dans sa bibliothèque standard
  JVM, JS, WASM et Native sont tous pris en charge.
  Maintenant que l’IETF RFC est stabilisée, il est logique que Go suive

• C’est dommage que Go manque de prise en charge pour ce type de fonctionnalité de base

  • Je me demande quel langage a mieux standardisé ce genre de choses. Peut-être Java ? Python et Rust semblent dans une situation similaire
  • Le sens de « batteries included » a beaucoup changé en 20 ans. C’est peut-être une fonctionnalité dont Google n’avait pas besoin en interne
  • Un UUID, au fond, ce n’est qu’un tableau de 16 octets. Générer un v4 prend quelques lignes. Ce n’est pas dramatique
  • Je me demande quelles fonctionnalités te semblent manquer
    Personnellement, j’ai trouvé le système de logs de Go trop minimaliste et j’ai dû l’implémenter moi-même
    Le module slog est lent et peu pratique. On dirait qu’il ne pense qu’aux environnements enterprise
  • Malgré ça, la qualité de la bibliothèque standard de Go reste de tout premier ordre. À mon avis, c’est la stdlib la plus utilisée au quotidien

• Je me suis demandé s’il existait un moyen d’obtenir à la fois l’efficacité de clustering en base de données de v7 et le caractère aléatoire de v4
  En utilisant v7 en interne, puis en le brouillant avant l’envoi externe avec XOR ou AES, ça devrait être possible

  • Il existe effectivement une tentative dans ce sens : projet uuidv47
  • Si l’objectif est la confidentialité, je pense qu’il vaut mieux chiffrer une clé entière
    Par exemple, avec un chiffrement de Feistel, on peut créer des ID publics opaques sans les problèmes de performance des UUID