Proposta para adicionar um pacote UUID à biblioteca padrão do Go

• Está sendo discutida no GitHub uma proposta para incluir recursos de geração e parsing de UUID na biblioteca padrão da linguagem Go
• O autor da proposta argumenta que hoje a maioria dos projetos de servidor e banco de dados em Go depende de pacotes externos como github.com/google/uuid
• Linguagens importantes como C#, Java e Python já oferecem suporte a UUID no nível da biblioteca padrão
• Durante a discussão, os principais pontos em debate foram especificações mais recentes como UUIDv7, conformidade com a RFC 9562, o escopo da inclusão de parsing e a consistência da API
• Mais tarde, a proposta foi incorporada a uma proposta de suporte a UUIDv4 e UUIDv7 no pacote crypto/rand (#76319), que segue em andamento

---

Visão geral da proposta

• Foi apresentada uma forma de adicionar uma API de geração e parsing de UUID à biblioteca padrão do Go
  • As versões alvo eram UUID v3, v4 e v5
  • Os principais argumentos eram a dependência de pacotes externos e casos de suporte padrão em outras linguagens
• UUID é um padrão internacional definido na RFC 4122 (posteriormente RFC 9562)
• O autor destacou que o Go é um caso excepcional entre linguagens importantes por não ter suporte padrão a UUID

Reações iniciais e discussão

• Alguns participantes mencionaram que já houve propostas semelhantes no passado, mas com precedentes de rejeição (#23789, #28324)
  • O motivo era que usar pacotes externos já era suficientemente simples e tinha um ciclo de releases mais flexível do que a biblioteca padrão
• O autor argumentou que “se a maioria dos projetos precisa importar um pacote externo toda vez, é melhor incluí-lo no padrão”
• O fato de muitas linguagens incluírem UUID em uma biblioteca padrão relacionada a crypto foi apresentado como argumento favorável

Versões mais recentes de UUID e adoção da RFC

• Algumas opiniões apontaram que UUID v1~v5 são antigos, e o v7 é a versão mais recente e promissora
  • O v7 possui várias opções de implementação, e seria necessário observar os resultados da adoção
• Um rascunho da RFC recomendava não fazer parsing de UUID sem necessidade e tratá-lo como um identificador opaco
• Depois da publicação oficial da RFC 9562, a discussão relacionada passou a se concentrar em suporte a UUIDv7

Revisão e consolidação da proposta

• Em 2025, com a RFC 9562 oficializada, surgiu a menção de que o PostgreSQL 18 passou a oferecer suporte a UUIDv7
• Depois disso, do lado do Go foi iniciada uma proposta separada para adicionar apenas a geração de UUIDv4 e UUIDv7 ao pacote crypto/rand (#76319)
  • O recurso de parsing foi excluído em conformidade com a recomendação da RFC
• A proposta original (#62026) foi fechada como duplicada (duplicate)

Discussão sobre o design da API

• Houve debate sobre definir o comportamento padrão de uuid.New() como v4 ou deixar margem para mudança futura
  • Alguns sugeriram fixá-lo sempre em v4, alegando que mudar a versão depois poderia causar problemas de compatibilidade
• Também se discutiu se métodos como Compare, MustParse e Parse deveriam ser oferecidos
  • Houve opiniões de que Compare seria necessário para suportar UUIDs ordenáveis, conforme definido pela RFC
  • MustParse seria incluído para manter consistência com outras funções Must* da biblioteca padrão
• Concluiu-se que o método IsZero() é desnecessário para o tipo UUID
• Foram apresentadas várias propostas de design, como introduzir uma struct Generator e separar tipos por versão (UUIDv4, UUIDv7 etc.)
• Alguns apontaram a ambiguidade da função New() e defenderam oferecer apenas funções com versão explícita (NewV4, NewV7)

Principais questões técnicas

• Houve discussão sobre se a definição de ordenação (sorting) de UUID existe de forma clara apenas para v6 e v7
• Também foi analisado como implementar garantia de ordenação baseada em tempo na geração de UUIDv7 e prevenção de colisões em concorrência (método com contador)
• Foi apontado que as diferenças de significado entre versões (por exemplo, v1 inclui endereço MAC; v7 é baseado em tempo) limitam um design com tipo único
• Alguns propuseram separar tipos por versão e introduzir métodos de conversão explícitos (AsV4(), AsV7() etc.)

Conclusão e estado atual

• A comunidade Go, em geral, concorda com a necessidade de suporte padrão a UUID
• No entanto, para manter a simplicidade da biblioteca padrão e seguir as recomendações da RFC:
  • o recurso de parsing foi excluído
  • decidiu-se seguir na direção de adicionar apenas a geração de UUIDv4 e UUIDv7 a crypto/rand
• A proposta original (#62026) foi integrada à proposta #76319 e continua em andamento,
  deixando o suporte padrão a UUID na linguagem Go próximo da formalização

[GN⁺]

Comentários do Hacker News

• Achei interessante dizerem que as versões 1~5 do UUID já estão ultrapassadas
  Mas o v4 ainda tem a maior aleatoriedade e continua sendo recomendado como chave primária para evitar hotspots e problemas de privacidade em bancos de dados distribuídos
  Links de referência: documentação de UUID do CockroachDB, guia de UUID do Google Cloud Spanner

  • Também achei essa afirmação estranha. O v7 é bom quando se precisa de monotonicidade, mas o timestamp pode expor informações do sistema. Por isso o v4 continua válido
  • Acho inadequado usar a expressão “outdated”. O problema é incompatibilidade de requisitos, não idade
    Cada versão de UUID (incluindo a v4) tem falhas em determinados cenários. Na prática, muitas organizações acabam definindo e usando seus próprios valores puros de 128 bits em vez do UUID padrão
    No fim, surgiram muitos requisitos complexos que vão além das limitações de projeto do UUID
  • O v4 é a escolha padrão, e outras versões só são usadas quando há necessidade específica de preservar ordenação
  • Se você realmente precisa de 128 bits de aleatoriedade, basta usar um número aleatório de 128 bits. Não há necessidade de forçar isso ao formato UUID
  • Mas o v4 pode bagunçar as inserções em B-Tree. Aprendi que o v7 é bem mais rápido por causa da eficiência do page caching do kernel

• Fiquei feliz de ver esse tipo de notícia pequena sobre Go no HN hoje
  Ultimamente só se fala do futuro da programação ou de IA, então esse tipo de tópico técnico parece fresco

  • Foi bom ver uma discussão técnica aprofundada depois de tanto tempo
  • Deu um alívio sair um pouco do medo e FUD sobre IA. Antigamente eu não ficava ansioso ao abrir o HN, mas hoje em dia parece que todo mundo só fala que “vai tudo acabar”
  • Parece uma questão técnica pequena à primeira vista, mas na verdade é uma decisão grande que influencia a arquitetura da linguagem Go e a direção da sua liderança
    Perfeccionistas, desenvolvedores de campo e a comunidade de crypto têm posições diferentes
    Documento relacionado: RFC 9562
    Espero que o Go tome a decisão certa. Especialmente o TinyGo é realmente incrível para microcontroladores
  • É curioso observar o pessoal que odeia Go. Agora estamos na era em que a IA lê código, então até a graça de criticar linguagens parece ter desaparecido

• Não me importo muito se Go oferece suporte para gerar UUID, mas ter um tipo UUID padrão é realmente importante
  Isso permitirá marshaling consistente em JSON, Text, database/sql etc.
  Em uma análise recente de dependências de Go, google/uuid foi o segundo pacote mais usado
  Análise relacionada: The most popular Go dependency

  • Eu também gostaria que o tipo dec128 entrasse no padrão. O ideal seria oferecê-lo como uma struct fácil de converter para uint128

• O charme do Go está mais na praticidade do que em recursos chamativos
  A linguagem não fica complexa a ponto de desmoronar e só adiciona o que é necessário

  • Recentemente também atualizei pulando várias versões e não tive problema nenhum
    Graças à garantia de compatibilidade, dá para usar com tranquilidade. É uma linguagem que muda devagar, mas melhora de forma constante

• Mais importante do que o pacote uuid do Google estar inativo é o fato de que o gofrs/uuid segue o novo padrão e continua sendo mantido ativamente
  repositório do gofrs/uuid

  • É prazeroso criar bibliotecas sem dependências externas. Essa mudança vai tornar esse tipo de trabalho mais fácil
  • Mas o google/uuid não tem lançamentos desde 2024, e ainda há uma issue aberta sobre isso em junho de 2025
    issue #194
  • Essa proposta já vinha sendo discutida há 3 anos

• Eu realmente odeio UUID. É um identificador nada amigável para humanos
  Em debugging ou em resultados de consulta, ele é longo demais e inconveniente.
  Claro, ele é útil quando se precisa de IDs únicos entre sistemas totalmente separados, mas na maioria dos casos seu uso é exagerado
  Em situações comuns, um emissor centralizado de números é muito melhor.
  Por exemplo, um procedimento como GetNextId no banco de dados é mais humano e mais eficiente

  • Uma vez, na empresa, gerenciávamos projetos com códigos de 6 dígitos, e alguém resolveu trocar isso por UUID
    O resultado foi um código ilegível para humanos, e ainda por cima era uma implementação própria que ficava estranhamente sequencial. Foi uma decisão totalmente desastrosa
  • Na verdade, na maioria dos casos um contador inteiro já basta
    No Postgres, usando uma tabela de contadores, dá para gerar dezenas de milhares de IDs por segundo
    Isso ainda melhora economia de memória, eficiência de compressão e desempenho de hashmap
    UUID é conveniente, mas destrói o desempenho
  • Eu gostaria que houvesse algum elemento fácil para humanos lerem
    Ex.: algo como BASKETBALL-...-FISH, adicionando um checksum baseado em palavras para facilitar a memorização
  • Você mencionou “randomização determinística”, e eu também acho que algo como LFSR (linear feedback shift register) pode ser uma boa abordagem

• Fiquei me perguntando se o UUID vai mesmo ser adicionado ao Go

  • No momento está com status ‘Likely accept’. Dá para conferir no board do projeto Go
    Se não houver oposição relevante, a chance de entrar é alta
  • Sim, deve ser adicionado

• O Kotlin também adicionou recentemente, na versão 2.3, suporte a versões de UUID com base na RFC 9562 à biblioteca padrão
  Há suporte para JVM, JS, WASM e Native.
  Como a RFC da IETF já se estabilizou, faz sentido o Go seguir pelo mesmo caminho

• É uma pena que o Go tenha esse tipo de falta de suporte para funcionalidades básicas

  • Fico curioso sobre quais linguagens padronizaram isso melhor. Talvez Java? Python e Rust parecem estar em situação parecida
  • O significado de “batteries included” mudou muito ao longo dos últimos 20 anos. Talvez isso simplesmente não fosse uma necessidade dentro do Google
  • UUID no fim das contas é só um array de 16 bytes. Gerar um v4 leva poucas linhas. Não é grande coisa
  • Fico curioso sobre que funcionalidade exatamente parece estar faltando
    Pessoalmente, achei o sistema de logging do Go simples demais e tive de implementar o meu próprio
    O módulo slog é lento e pouco prático. Parece ter sido pensado só para ambiente enterprise
  • Ainda assim, a qualidade da biblioteca padrão do Go é de altíssimo nível. Acho que é a stdlib mais usada no desenvolvimento do dia a dia

• Fiquei pensando se existe uma forma de ter ao mesmo tempo a eficiência de clustering em banco de dados do v7 e a aleatoriedade do v4
  Talvez seja possível usar v7 internamente e, ao expor externamente, fazer um embaralhamento com XOR ou AES

  • Na prática já existe uma tentativa assim: projeto uuidv47
  • Se o objetivo é privacidade, acho melhor simplesmente criptografar chaves inteiras
    Por exemplo, usando cifra de Feistel dá para criar IDs públicos opacos sem os problemas de desempenho do UUID