As Novidades do Go 1.27: Suporte Nativo a UUID e o Histórico Debate sobre Lambdas

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!