As Novidades do Go 1.27: Suporte Nativo a UUID e o Histórico Debate sobre Lambdas
Transcrição
Apresentadora
Juliana Santos
Convidado
Ricardo Menezes (Engenheiro de Software Sênior e Especialista em Sistemas Distribuídos)
Apresentadora
E aí, pessoal, bem-vindos de volta ao Allur! Eu sou a Juliana Santos e hoje o nosso papo é sobre uma das linguagens que eu mais tenho visto crescer no ecossistema de infraestrutura e backend: o Go. Se você é gopher, ou se está só de olho na linguagem, segura o fone porque o ciclo do Go 1.27 tá prometendo ser um dos mais transformadores dos últimos anos. A gente passou um tempo vendo melhorias mais incrementais, sabe? Coisinhas de performance aqui e ali, o refinamento dos Generics... Mas agora, parece que o time do Go resolveu mexer em dois pilares que tocam na ferida: a modernização da biblioteca padrão e a própria forma como a gente escreve o código no dia a dia. A gente vai falar hoje sobre o suporte nativo a UUID — que era um desejo antigo da comunidade — e o debate que tá pegando fogo sobre as "lambdas", ou funções curtas. O que será que muda no "Go Way" de programar? Vamos descobrir agora.
Apresentadora
E pra desbravar essas novidades comigo, eu trouxe um convidado que manja muito de sistemas de alta escala e respira Go no dia a dia. Ele é Engenheiro de Software Sênior e um entusiasta da linguagem. Ricardo Menezes, seja muito bem-vindo ao Allur! Massa ter você aqui, Ricardo.
Convidado
Pô, Juliana, valeu demais pelo convite! É um prazer estar aqui no Allur. Eu sou fã do podcast e falar de Go é sempre um tema que me empolga, principalmente agora que a linguagem parece estar num ponto de virada bem interessante com essa versão 1.27.
Apresentadora
Com certeza! E Ricardo, vamos direto ao ponto que eu acho que vai economizar muito "import" por aí: o pacote nativo de UUID. Cara, a gente sempre dependeu de pacotes externos, tipo o do Google ou o do Satori. Por que você acha que demorou tanto pra isso entrar na biblioteca padrão?
Convidado
Cara, essa é a pergunta de um milhão de dólares! O Go tem uma filosofia de "stdlib" (biblioteca padrão) muito conservadora. Eles só colocam lá o que é essencial e o que eles têm certeza que podem manter por décadas. Por muito tempo, a comunidade se virou bem com o `google/uuid`. Só que, tipo assim, hoje em dia quase tudo que a gente faz em sistemas distribuídos e microserviços pede um identificador único. Ter isso nativo não é só uma conveniência, é uma declaração de que o Go reconhece que UUID é um tipo primitivo pro desenvolvimento moderno, entende?
Apresentadora
Total! E não é só "qualquer" UUID, né? O destaque que eu vi nas propostas é o suporte ao UUID v7. O que ele tem de tão especial comparado com o v4 que a gente usa em todo canto?
Convidado
Ah, o v7 é o grande "pulo do gato"! O v4, que a gente tá acostumado, é puramente aleatório. Massa, funciona bem pra evitar colisão. Mas quando você joga isso num banco de dados, tipo um Postgres ou MySQL, e tenta usar como chave primária, o índice B-tree sofre. Como é tudo aleatório, o banco tem que ficar reordenando as páginas o tempo todo. Já o UUID v7 é "time-ordered", ou seja, ele é ordenável no tempo.
Apresentadora
Ah, então ele tem uma sequência temporal?
Convidado
Exatamente! Você gera um agora, outro daqui a um segundo, e o segundo é "maior" que o primeiro na ordenação. Pros índices do banco de dados, isso é lindo. A inserção fica muito mais rápida, reduz fragmentação e melhora a performance de escrita absurdamente. Trazer isso nativo, com a implementação otimizada do time core, sem alocações desnecessárias... cara, vai ser um ganho de performance "grátis" pra muita gente.
Apresentadora
Nossa, que legal! É o tipo de coisa que a gente nem percebe o quanto precisa até começar a usar. Agora, Ricardo, vamos pro tópico que tá dividindo opiniões e fazendo a galera debater forte no GitHub: as "Short Function Literals", ou nossas famosas lambdas. Por que isso virou uma urgência agora?
Convidado
Pois é, esse assunto é polêmico! (risos). O debate existe há anos, mas o que mudou o jogo foi o Go 1.23, quando lançaram os iteradores. Com os iteradores, a gente começou a poder fazer aquelas manipulações de lista tipo `Map`, `Filter`, `Reduce`. Só que, no Go atual, pra você passar uma função simples pra conferir se um número é maior que zero, por exemplo, você tem que escrever: `func(x int) bool { return x > 0 }`.
Apresentadora
É... fica um textão pra uma lógica minúscula, né?
Convidado
Exatamente! Fica muito ruído visual. Se você tem uma cadeia de processamento com três ou quatro passos, metade do seu código é a palavra-chave `func`, `return` e chaves. Isso cansa a vista e esconde a lógica de negócio. A proposta pro Go 1.27 é criar uma sintaxe curta, tipo o que a gente vê em Rust, C# ou Java. Algo como `x => x > 0`.
Apresentadora
Cara, eu confesso que eu acho essa sintaxe muito mais limpa. Mas eu sei que tem gente que reclama, falando que o Go vai perder aquela "clareza explícita" que é a marca registrada da linguagem. Você acha que tem esse risco? O Go tá virando um "Haskell da vida"?
Convidado
(Risos) Olha, o risco de virar Haskell é zero, o Russ Cox e o Ian Lance Taylor nunca deixariam! Mas a preocupação é válida. O "The Go Way" sempre foi: "é melhor ser explícito do que implícito". Quando você esconde os tipos e o `return`, tem gente que sente que perde o controle. Mas o contra-argumento, que eu concordo bastante, é que a verbosidade atual tá prejudicando a clareza. Às vezes, menos código significa que o que *sobra* é mais importante. A ideia não é complicar, é justamente limpar o caminho pra você ler o que realmente importa.
Apresentadora
É um equilíbrio difícil, né? Mas a recepção da comunidade parece estar sendo bem positiva, pelo que eu ando lendo.
Convidado
Sim! A maioria tá bem animada. Especialmente quem trabalha com processamento de dados. Quando você vê o código "antes e depois", a diferença de legibilidade é gritante. Se a proposta passar como o planejado, vai ser a mudança sintática mais forte desde os Generics no 1.18. É o Go amadurecendo e admitindo que, pra certos padrões modernos, a gente precisa de um pouco mais de ergonomia.
Apresentadora
Muito massa! É incrível ver como a linguagem evolui sem perder a essência, mas ouvindo o que o desenvolvedor precisa no "front de batalha" ali do dia a dia. Ricardo, a gente tá chegando no fim, mas papo de dev sempre rende. O que você diria pra quem tá começando com Go agora e tá vendo essas mudanças?
Convidado
Eu diria: fiquem tranquilos! O Go continua sendo aquela linguagem que você aprende o básico em um final de semana. Essas mudanças vêm pra tirar o peso das costas da gente, seja removendo dependência de terceiro com o UUID, ou facilitando a escrita de funções. É um ótimo momento pra ser desenvolvedor Go.
Apresentadora
Com certeza! Ricardo, obrigada demais por esse papo, cara. Foi muito esclarecedor entender os "porquês" por trás dessas propostas do Go 1.27.
Convidado
Eu que agradeço, Juliana! Valeu pelo espaço e até a próxima!
Apresentadora
Valeu! E pra você que ouviu a gente até aqui, o que achou? Lambdas no Go: sou a favor ou sou contra? Comenta com a gente nas redes sociais do Allur. Se quiser se aprofundar, dá uma olhada no blog oficial do Go e nas "proposals" lá no GitHub, é tudo aberto pra gente acompanhar. Valeu por sintonizar o Allur, eu sou a Juliana Santos e a gente se vê no próximo episódio. Tchau!