¿Por qué Go necesita un paquete UUID en su biblioteca estándar?
Si desarrollas en Go y trabajas con sistemas distribuidos, APIs o bases de datos, casi con certeza usas UUIDs (identificadores únicos universales). Durante años, la comunidad ha dependido de paquetes externos como github.com/google/uuid —con más de 5.800 estrellas en GitHub y utilizado por más de 434.000 paquetes— para cubrir esta necesidad fundamental. Pero eso podría estar a punto de cambiar de forma definitiva.
La propuesta golang/go#62026, presentada originalmente en agosto de 2023, plantea incorporar un paquete nativo crypto/uuid directamente en la biblioteca estándar de Go. Al cierre de esta publicación, la propuesta figura con estatus Likely Accept en el proyecto de propuestas del equipo de Go, con actualizaciones activas tan recientes como el 25 de febrero de 2026.
El problema real: dependencias externas, mantenimiento y riesgos de seguridad
La ausencia de un paquete UUID nativo no es solo una incomodidad técnica; tiene implicaciones directas en la seguridad y la estabilidad de los proyectos en producción.
Typosquatting: el riesgo silencioso
En diciembre de 2025, el equipo de investigación de Socket descubrió dos paquetes maliciosos en el ecosistema Go que se hacían pasar por la librería google/uuid. Estos paquetes, activos desde 2021, convertían funciones helper en canales cifrados de exfiltración de datos hacia servicios de paste. El caso demostró con dureza que la proliferación de paquetes UUID de terceros crea una superficie de ataque que un módulo nativo de Go —mantenido directamente por el equipo del lenguaje— eliminaría por completo.
Fragmentación e inestabilidad de dependencias
Históricamente, la comunidad Go ha debatido este tema en múltiples issues. Paquetes como satori/go.uuid introdujeron cambios de API sin advertencia que rompieron frameworks enteros. google/uuid se consolidó como estándar de facto, pero su velocidad de mantenimiento ha disminuido desde 2025, generando incertidumbre en equipos que dependen de él para operaciones críticas.
¿Qué propone crypto/uuid? Detalles técnicos de la propuesta
La propuesta principal (#62026) busca un paquete crypto/uuid que cubra las versiones más relevantes del estándar RFC 9562 —la evolución moderna del histórico RFC 4122—. Los puntos técnicos clave incluyen:
- Generación de UUIDs: Soporte nativo para las versiones más usadas en producción, con UUIDv4 (aleatorio, con
crypto/rand) y UUIDv7 (basado en tiempo Unix con alta entropía, ideal para ordenación en bases de datos). - Parsing flexible: Una función
Parsemás permisiva que las implementaciones actuales, capaz de manejar variantes del formato estándarxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. - Constantes de referencia: Variables
NilyMax, ambas referenciadas explícitamente en el RFC 9562. - Función Compare: Para comparación determinista entre UUIDs.
- Tipo de datos: UUID representado como un array fijo de 16 bytes (
[16]byte), garantizando type safety sin la ambigüedad de los byte slices.
La propuesta paralela: solo generación en crypto/rand (#76319)
En noviembre de 2025 surgió una propuesta más conservadora (#76319) que sugería limitar el soporte únicamente a la generación de UUIDv4 y UUIDv7 dentro del paquete crypto/rand ya existente, tratando los UUIDs como identificadores opacos sin funcionalidades de parsing. Esta propuesta fue cerrada, lo que indica que el equipo de Go se inclina por el enfoque más completo de #62026.
Comparación: ¿Qué cambia frente a google/uuid?
Para los founders y equipos técnicos que ya usan github.com/google/uuid en sus stacks, la transición a un paquete nativo implicaría ventajas concretas:
- Cero dependencias externas: Eliminas una entrada de
go.mody reduces la superficie de ataque de la cadena de suministro de software. - Mantenimiento garantizado: El equipo central de Go asume la responsabilidad, con el respaldo de la Go 1 Compatibility Promise.
- API familiar: El diseño propuesto en #62026 es deliberadamente similar al de
google/uuidpara facilitar la migración. - Soporte RFC 9562: La propuesta nativa referencia directamente el RFC más reciente, que formaliza versiones modernas como UUIDv7, especialmente valioso para sistemas que usan UUIDs como primary keys en bases de datos SQL y NoSQL por su ordenabilidad temporal.
Impacto para founders y equipos de producto en LATAM
Para startups y equipos de desarrollo que construyen sobre Go —un lenguaje muy usado en infraestructura, microservicios y backends de alto rendimiento— esta propuesta tiene implicaciones prácticas inmediatas:
Arquitecturas de microservicios y sistemas distribuidos
Los UUIDs son el mecanismo de correlación por excelencia en sistemas distribuidos. Tener soporte nativo significa que herramientas de observabilidad, trazabilidad y logging pueden depender de una implementación estable sin riesgo de incompatibilidades entre versiones de dependencias.
Compliance y auditorías de seguridad
En contextos regulados (fintech, healthtech, edtech con datos sensibles), reducir el número de dependencias de terceros facilita auditorías de seguridad y cumplimiento normativo. Un paquete nativo de Go pasa automáticamente por el proceso de revisión del equipo central del lenguaje.
UUIDv7 y bases de datos: el caso de uso más caliente
El UUIDv7 es particularmente relevante para equipos que usan UUIDs como claves primarias en PostgreSQL, MySQL o bases de datos distribuidas como CockroachDB. A diferencia del UUIDv4 (completamente aleatorio), el v7 incorpora un timestamp en los bits más significativos, lo que mejora drásticamente el rendimiento de índices B-tree y reduce la fragmentación. Tener esto disponible en stdlib simplifica enormemente la arquitectura de nuevos proyectos.
Estado actual y próximos pasos
La propuesta #62026 tiene estatus Likely Accept en el repositorio oficial de Go. Las actualizaciones más recientes de febrero de 2026, con refinamientos de API propuestos por neild (miembro del equipo de Go), sugieren que se está trabajando activamente hacia una versión final antes de la aceptación formal.
No hay una versión de Go confirmada para la inclusión, pero dado el ciclo de releases semestrales del lenguaje (Go 1.x cada ~6 meses), la comunidad anticipa que podría estar disponible en alguna versión de Go 1.24 o 1.25 si la aceptación formal ocurre en los próximos meses.
La propuesta paralela (#76319) fue cerrada, lo que refuerza la señal de que el equipo prefiere una solución más completa en lugar de un parche mínimo en crypto/rand.
Conclusión
La incorporación de un paquete UUID nativo en la biblioteca estándar de Go es una de las propuestas más esperadas por la comunidad en los últimos años. No se trata solo de conveniencia: responde a necesidades reales de seguridad (eliminar vectores de typosquatting), estabilidad de dependencias y soporte de estándares modernos como el RFC 9562 con UUIDv7.
Para founders y equipos técnicos que construyen en Go, esto significa menos fricción en la gestión de dependencias, auditorías más limpias y acceso directo a herramientas esenciales para sistemas distribuidos, APIs y bases de datos. Vale la pena seguir de cerca el progreso de esta propuesta en el repositorio oficial de Go.
Descubre cómo otros founders implementan Go, UUID y arquitecturas distribuidas en sus productos reales.
Fuentes
- https://github.com/golang/go/issues/62026 (fuente original)
- https://github.com/golang/go/issues/76319 (propuesta paralela crypto/rand UUIDv4 y UUIDv7)
- https://github.com/google/uuid (paquete de referencia actual)
- https://pkg.go.dev/github.com/google/uuid (documentacion oficial google/uuid)
- https://socket.dev/blog/malicious-go-packages-impersonate-googles-uuid-library-and-exfiltrate-data (caso de seguridad typosquatting)
- https://groups.google.com/g/golang-nuts/c/J_htXsnVjdY (debate comunidad golang-nuts)
