Proponen agregar un paquete UUID a la biblioteca estándar de Go

• Se está debatiendo en GitHub una propuesta para incluir en la biblioteca estándar del lenguaje Go funciones de generación y parseo de UUID
• El autor de la propuesta señala como fundamento que actualmente la mayoría de los proyectos de servidores y bases de datos en Go dependen de paquetes externos como github.com/google/uuid
• Lenguajes principales como C#, Java y Python ya ofrecen soporte de UUID a nivel de biblioteca estándar
• Durante la discusión, los principales puntos en debate incluyen especificaciones recientes como UUIDv7, el cumplimiento de RFC 9562, el alcance de las funciones de parseo y la consistencia de la API
• Más adelante, esta propuesta se integró en la propuesta de soporte para UUIDv4 y UUIDv7 en el paquete crypto/rand (#76319), que sigue en curso

---

Resumen de la propuesta

• Se plantea agregar a la biblioteca estándar de Go una API de generación y parseo de UUID
  • Las versiones objetivo son UUID v3, v4 y v5
  • Los principales argumentos son la dependencia de paquetes externos y los casos de soporte estándar en otros lenguajes
• UUID es un estándar internacional definido en RFC 4122 (más tarde RFC 9562)
• El proponente señala que Go es un caso excepcional entre los lenguajes principales al no contar con soporte estándar para UUID

Reacciones iniciales y discusión

• Algunos participantes mencionaron que ya hubo propuestas similares en el pasado, pero fueron rechazadas (#23789, #28324)
  • La razón fue que usar paquetes externos es suficientemente sencillo y que su ciclo de publicación es más flexible que el de la biblioteca estándar
• El proponente argumenta que “si la mayoría de los proyectos tienen que importar siempre un paquete externo, entonces sería mejor incluirlo en el estándar”
• También se presentó como argumento a favor que muchos lenguajes incluyen UUID en una biblioteca estándar relacionada con crypto

Versiones más recientes de UUID y adopción del RFC

• Algunas opiniones señalan que UUID v1~v5 ya están desactualizados y que v7 es la versión más reciente y prometedora
  • v7 tiene varias opciones de implementación, por lo que sería necesario observar sus resultados en la práctica
• En el borrador del RFC se recomienda no parsear UUID innecesariamente y tratarlos como identificadores opacos
• Después de la publicación oficial de RFC 9562, la discusión relacionada pasó a centrarse en el soporte para UUIDv7

Revisión y fusión de la propuesta

• En 2025, tras oficializarse RFC 9562, apareció una mención de que PostgreSQL 18 soporta UUIDv7
• Más adelante, del lado de Go se abrió una propuesta separada para agregar únicamente funciones de generación de UUIDv4 y UUIDv7 al paquete crypto/rand (#76319)
  • Las funciones de parseo quedaron excluidas siguiendo la recomendación del RFC
• La propuesta original (#62026) fue cerrada por considerarse duplicada (duplicate)

Discusión sobre el diseño de la API

• Se discutió si el comportamiento predeterminado de uuid.New() debería ser v4 o si debería dejar abierta la posibilidad de cambios futuros
  • Algunos propusieron fijarlo siempre en v4, advirtiendo que cambiar la versión en el futuro podría causar problemas de compatibilidad
• También se debatió si debían ofrecerse métodos como Compare, MustParse y Parse
  • Sobre Compare, hubo opiniones de que es necesario para soportar UUID ordenables, conforme a la definición del RFC
  • MustParse se incluiría para mantener consistencia con otras funciones Must* de la biblioteca estándar
• Se concluyó que el método IsZero() no es necesario para el tipo UUID
• Se propusieron varias ideas de diseño, como introducir una estructura Generator o separar tipos por versión (UUIDv4, UUIDv7, etc.)
• Algunos señalaron la ambigüedad de la función New() y propusieron ofrecer solo funciones de versión explícita (NewV4, NewV7)

Principales temas técnicos

• Se discutió si la definición de ordenamiento de UUID (sorting) existe con claridad solo para v6 y v7
• También se revisaron métodos para implementar la garantía de orden temporal al generar UUIDv7 y la prevención de colisiones en concurrencia (mediante contador)
• Se señaló que las diferencias semánticas entre versiones (por ejemplo, v1 incluye dirección MAC y v7 se basa en tiempo) muestran los límites de un diseño con un único tipo
• Algunos propusieron separar tipos por versión e incorporar métodos de conversión explícitos como AsV4() y AsV7()

Conclusión y estado actual

• En la comunidad de Go existe un consenso general sobre la necesidad de soporte estándar para UUID
• Sin embargo, para mantener la simplicidad de la biblioteca estándar y respetar las recomendaciones del RFC, se definió la siguiente dirección:
  • excluir las funciones de parseo
  • agregar solo funciones de generación de UUIDv4 y UUIDv7 a crypto/rand
• La propuesta original (#62026) fue integrada en la propuesta #76319 y sigue en curso,
  por lo que el soporte estándar de UUID en el lenguaje Go parece estar cerca de una etapa de formalización

[GN⁺]

Opiniones en Hacker News

• Me pareció interesante que dijeran que las UUID versión 1~5 ya están obsoletas
  Pero v4 sigue teniendo la mayor aleatoriedad y se recomienda como clave primaria para evitar problemas de hotspot y cuestiones de privacidad en bases de datos distribuidas
  Enlaces de referencia: documentación de UUID de CockroachDB, guía de UUID de Google Cloud Spanner

  • A mí también me sonó raro. v7 es buena cuando se necesita monotonicidad, pero la marca de tiempo puede exponer información del sistema. Por eso v4 sigue siendo válida
  • Me parece inapropiado usar la palabra “outdated”. El problema es una discordancia de requisitos, no la antigüedad
    Cada versión de UUID, incluida v4, tiene defectos en ciertos contextos. De hecho, muchas organizaciones usan valores puros de 128 bits definidos por ellas mismas en lugar de UUID estándar
    Al final, han aparecido muchos requisitos complejos que superan las limitaciones de diseño de UUID
  • v4 es la opción por defecto, y solo uso otras versiones cuando necesito específicamente preservar el orden
  • Si de verdad necesitas 128 bits de aleatoriedad, simplemente usa un número aleatorio de 128 bits. No hace falta forzarlo al formato UUID
  • Pero v4 puede hacer un desastre con las inserciones en B-Tree. Aprendí que v7 es mucho más rápida por la eficiencia del page caching del kernel

• Me alegra ver hoy en HN una noticia pequeña sobre Go
  Últimamente todo gira en torno al futuro de la programación o a la IA, así que este tipo de tema técnico se siente fresco

  • Se siente bien volver a ver una discusión técnica profunda después de tanto tiempo
  • Me da tranquilidad alejarme un rato del miedo y la incertidumbre (FUD) sobre IA. Antes abrir HN no me ponía ansioso, pero últimamente todos hablan solo de que “todo se va a arruinar”
  • A simple vista parece un tema técnico menor, pero en realidad es una decisión grande que define la arquitectura del lenguaje Go y la dirección de su liderazgo
    Los perfeccionistas, los desarrolladores de campo y la comunidad crypto tienen posturas distintas
    Documento relacionado: RFC 9562
    Espero que Go tome la decisión correcta. En especial TinyGo es realmente genial para microcontroladores
  • Es curioso el panorama de la gente que odia Go. Ahora que la IA revisa código, hasta la diversión de criticar lenguajes parece haberse perdido

• No me importa mucho que Go soporte la generación de UUID, pero que exista un tipo UUID estándar sí es realmente importante
  Permitirá un marshaling consistente en JSON, Text, database/sql, etc.
  En un análisis reciente de dependencias de Go, google/uuid fue el segundo paquete más usado
  Análisis relacionado: The most popular Go dependency

  • A mí también me gustaría que el tipo dec128 entrara al estándar. Sería ideal si se ofreciera como una estructura fácil de convertir a uint128

• El atractivo de Go está en la practicidad más que en las funciones llamativas
  El lenguaje no se vuelve tan complejo como para romperse, y solo agrega lo necesario

  • Yo también actualicé hace poco saltándome varias versiones y no tuve ningún problema
    Gracias a la garantía de compatibilidad se puede usar con tranquilidad. Los cambios son lentos, pero es un lenguaje que mejora de forma constante

• Más que el hecho de que el paquete uuid de Google esté inactivo, creo que lo importante es que gofrs/uuid sigue el nuevo estándar y se mantiene activamente
  repositorio de gofrs/uuid

  • Me gusta crear librerías sin dependencias externas. Con este cambio, ese tipo de trabajo se vuelve más fácil
  • Pero google/uuid no ha tenido lanzamientos desde 2024, y en junio de 2025 todavía hay issues abiertos al respecto
    issue #194
  • Esta propuesta ya se venía discutiendo desde hace 3 años

• Realmente odio las UUID. Son identificadores poco amigables para las personas
  Son demasiado largas e incómodas para depurar o ver resultados de consultas.
  Claro, sirven cuando necesitas IDs únicos entre sistemas completamente separados, pero en la mayoría de los casos se abusa de ellas
  En casos normales, un generador centralizado de números es mucho mejor.
  Por ejemplo, un procedimiento como GetNextId en la base de datos es más humano y más eficiente

  • En una empresa donde trabajé antes, gestionábamos proyectos con códigos de 6 dígitos, y alguien decidió cambiarlos por UUID
    El resultado fue un código imposible de leer para humanos y, para colmo, era una implementación propia extrañamente secuencial. Fue una decisión terrible
  • En realidad, en la mayoría de los casos basta con un contador entero
    En Postgres, usando una tabla de contadores, puedes generar decenas de miles de IDs por segundo
    Así también mejoras el ahorro de memoria, la eficiencia de compresión y el rendimiento del hashmap
    UUID es conveniente, pero arruina el rendimiento
  • Me gustaría que tuviera algún elemento fácil de leer para humanos
    Por ejemplo, algo como BASKETBALL-...-FISH, agregando un checksum basado en palabras para que sea más fácil de recordar
  • Se mencionó la “aleatorización determinista”, y yo también creo que algo como un LFSR (registro de desplazamiento con retroalimentación lineal) puede funcionar bien

• Me preguntaba si UUID realmente se va a agregar a Go

  • Actualmente está en estado ‘Likely accept’. Se puede ver en el tablero del proyecto Go
    Si no hay objeciones importantes, es muy probable que se incluya
  • Sí, está previsto que se agregue

• Kotlin también agregó recientemente en la versión 2.3 el soporte de versiones UUID basado en RFC 9562 a su biblioteca estándar
  Es compatible con JVM, JS, WASM y Native.
  Ahora que el IETF RFC ya está estabilizado, tiene sentido que Go también lo adopte

• Es una lástima que Go tenga este tipo de carencias en soporte básico

  • Me pregunto qué lenguajes han estandarizado mejor este tipo de cosas. ¿Java quizá? Python y Rust parecen estar en una situación parecida
  • El significado de “batteries included” ha cambiado mucho en 20 años. Tal vez era una función que Google no necesitaba internamente
  • UUID al final no es más que un arreglo de 16 bytes. Generar v4 se resuelve en unas pocas líneas. No es gran cosa
  • Me pregunto qué funciones sienten que faltan
    En lo personal, el sistema de logging de Go me parece demasiado simple y tuve que implementarlo por mi cuenta
    El módulo slog es lento e incómodo. Parece pensado solo para entornos enterprise
  • Aun así, la calidad de la biblioteca estándar de Go está al máximo nivel. Creo que es la stdlib que más uso en el desarrollo diario

• Me puse a pensar si habría una forma de obtener al mismo tiempo la eficiencia de clustering en DB de v7 y la aleatoriedad de v4
  Tal vez se pueda usar v7 internamente y, al enviarlo hacia afuera, mezclarlo con XOR o AES

  • De hecho sí hay intentos de eso: proyecto uuidv47
  • Si el objetivo es la privacidad, creo que es mejor cifrar una clave entera
    Por ejemplo, usando cifrado Feistel puedes crear IDs públicos opacos sin los problemas de rendimiento de UUID