Go
Preview do Go 1.27: A Chegada dos Métodos Genéricos e a Evolução das Ferramentas
Published:
•
Duration: 7:47
0:00
0:00
Transcript
Apresentadora: E aí, pessoal, bem-vindos de volta ao Allur! Eu sou a Juliana Santos e hoje o nosso papo é para quem, assim como eu, não consegue tirar os olhos das atualizações da linguagem que mais cresce no nosso ecossistema de backend. Pois é, vamos falar de Go! Mas não é qualquer update, não. O Go 1.27 está batendo na porta e ele traz o que muitos desenvolvedores chamam de "a peça que faltava no quebra-cabeça dos Generics". Desde a versão 1.18, a gente ganhou os tipos genéricos, mas ficou aquele gostinho de "quero mais" porque os métodos ainda tinham umas limitações bem chatas. Sabe quando você quer criar uma API elegante, mas acaba caindo num mar de `interface{}` ou tendo que criar funções globais soltas? Pois é, o Go 1.27 promete acabar com essa agonia. Hoje a gente vai dissecar o que são esses métodos genéricos, como o time do Google resolveu os desafios de performance e como as ferramentas automáticas, tipo o `go fix`, vão ajudar a gente a não quebrar a cabeça na hora de atualizar o código. Fica com a gente porque o episódio de hoje está massa!
Apresentadora: E para me ajudar a mergulhar nesse mar de tipos e ponteiros, eu trouxe um convidado que respira Go no dia a dia. Ele é engenheiro de software sênior, especialista em sistemas distribuídos e um entusiasta de longa data da comunidade Go aqui no Brasil. Seja muito bem-vindo ao Allur, Rafael Medeiros! Tudo bem, Rafa?
Convidado: Valeu, Juliana! Tudo ótimo por aqui. É um prazer enorme estar no Allur. Cara, eu tava ansioso por esse papo, porque o Go 1.27 tá mexendo com o brio de quem escreve biblioteca há anos. É uma daquelas atualizações que a gente olha e pensa: "Finalmente!"
Apresentadora: Pois é, "finalmente" é a palavra de ordem, né? Rafa, vamos direto ao ponto. Desde o Go 1.18 a gente tem Generics, mas a galera reclamava muito de uma limitação específica nos métodos. Explica pra gente: o que mudou de verdade no Go 1.27?
Convidado: Então, Ju, o buraco era o seguinte: antes, você podia ter uma struct genérica, tipo uma `Lista`. Mas, se você tivesse uma struct comum, você não podia criar um método nela que recebesse um tipo genérico novo. O método estava "preso" aos tipos que a struct já conhecia. Se você quisesse um método `.Processar(dados)`, o compilador simplesmente falava "não". Aí a gente tinha que fazer o quê? Ou usava `any`, perdendo toda a segurança de tipos, ou criava uma função global tipo `Processar(meuObjeto, dados)`. Isso quebrava totalmente a fluidez do código, né? Parecia que a gente tava voltando dez anos no tempo. Agora, no 1.27, o método pode ter o seu próprio parâmetro de tipo. É a liberdade total de criar APIs muito mais fluídas.
Apresentadora: Nossa, total! E eu imagino que isso facilite muito a vida de quem cria bibliotecas. Mas eu li que implementar isso não foi fácil para o time do Go. Teve toda uma treta técnica com tabelas de despacho e o tal do "binary bloat", né? Como eles resolveram isso sem deixar o binário do Go gigantesco?
Convidado: Cara, essa é a parte "mágica" e, ao mesmo tempo, super complexa. O grande medo da comunidade era que, ao permitir métodos genéricos, o compilador gerasse uma cópia do método para cada tipo diferente que a gente usasse — o que a gente chama de monomorfização pura. Se você usasse o método com 50 tipos diferentes, seu binário ia explodir de tamanho. O time do Go, sendo o time do Go, foi bem pragmático. Eles usam um mix de monomorfização com dicionários de tipos. Basicamente, o compilador tenta ser esperto: ele compartilha código onde dá e usa esses "dicionários" em tempo de execução para resolver os detalhes dos tipos. O resultado é um equilíbrio legal entre performance e tamanho de binário. Não é perfeito, nada é, mas para o uso real de dia a dia, ficou sensacional.
Apresentadora: Entendi, tipo aquele "equilíbrio de mestre" que o Go sempre tenta buscar. Agora, falando de código na prática... Onde que o desenvolvedor médio, aquele que tá lá no meio de um projeto de microserviço, vai sentir a diferença? Você mencionou APIs fluídas, tipo Builders, né?
Convidado: Exatamente! Pensa num Builder de consultas ou um cliente de API. Antes, se você queria fazer um `.Decode()` no final de uma cadeia de chamadas, você tinha que passar o tipo de um jeito meio feio ou fazer um cast manual depois. Agora, você pode ter um método `.Decode()` direto no objeto. O código fica muito mais limpo, tipo assim: `cliente.Get("/users").Decode()`. É muito mais natural, cara. Outro ponto são os drivers de banco de dados e middlewares. A gente vai começar a ver bibliotecas que dependem muito menos de *reflection* (reflexão) e mais do compilador. Isso significa menos erro em tempo de execução e, possivelmente, um ganho de performance porque o compilador "enxerga" o que tá acontecendo ali.
Apresentadora: Massa demais! E tem uma coisa que me chamou a atenção nesse preview do 1.27 que é o foco nas ferramentas. O `go fix` ganhou uns superpoderes novos, né? Muita gente esquece que o Go tem esse ecossistema de automação muito forte.
Convidado: Com certeza! O `go fix` é o herói anônimo do Go. Para essa versão, eles estão trazendo modernizadores que identificam padrões antigos. Sabe aquelas funções globais que eu falei, que a gente criava só pra contornar a falta de métodos genéricos? O `go fix` vai conseguir sugerir: "Ei, quer transformar isso aqui num método genérico bonitinho?". Isso para quem tem um legado de milhões de linhas de código é uma mão na roda. Além disso, o LSP — que é o que faz o VS Code e o GoLand funcionarem bem — foi tunado. A inferência de tipo em métodos encadeados tá bem mais inteligente. Você não vai precisar ficar escrevendo o tipo toda hora, o editor já vai entender o que tá vindo.
Apresentadora: Pô, isso ajuda muito no fluxo de trabalho, né? Menos tempo brigando com o linter e mais tempo entregando feature. Mas ó, nem tudo são flores. Eu sei que você é fã de Go, mas onde é que a gente tem que tomar cuidado? Tem perigo de a galera começar a "super-engenheirar" as coisas agora que tem essa ferramenta nova na mão?
Convidado: (Risos) Com certeza, Ju! Esse é o meu maior medo. O Go sempre foi sobre simplicidade, né? "Menos é mais". O perigo é o desenvolvedor querer transformar tudo em método genérico só porque agora pode. Tem muita gente que vem de linguagens como Java ou C# e quer trazer aqueles padrões de abstração super complexos. Minha dica é: se uma interface simples resolve, usa a interface. Se você só vai usar o método com um tipo, não precisa ser genérico. Generics é para quando você tem duplicação real de lógica. Se começar a ficar difícil de ler o código por causa dos colchetes, é sinal de que você passou do ponto.
Apresentadora: É aquela velha máxima: só porque você *pode* fazer algo, não significa que você *deva*, né? (Risos). E para quem quer se preparar agora, Rafael? O Go 1.27 ainda tá chegando, mas qual o dever de casa para os Gophers que estão ouvindo a gente?
Convidado: Cara, o primeiro passo é baixar as versões beta ou RC assim que saírem e rodar nos seus testes. Mas o principal é olhar para as suas bibliotecas internas. Aqueles utilitários de conversão, de validação, de mapeamento... ali é o lugar onde os métodos genéricos vão brilhar. Começa a planejar como você pode limpar essas APIs usando o `go fix`. E, claro, fica de olho nas tags de versão do `go.mod`, porque se você começar a usar métodos genéricos, sua biblioteca vai exigir o Go 1.27 pra cima. Então, tem que alinhar isso com o time e com a infra.
Apresentadora: Dicas de ouro! Bom, a gente está chegando ao fim desse papo, mas já deu pra ver que o Go 1.27 vai ser um divisor de águas na maturidade da linguagem. Rafa, valeu demais por compartilhar esse conhecimento aqui no Allur. Foi um prazer!
Convidado: O prazer foi meu, Juliana! Valeu pelo convite e bora codar que esse Go 1.27 promete!
Apresentadora: Com certeza! E para você que acompanhou a gente até aqui, as principais conclusões são claras: o Go está ficando mais expressivo, as APIs vão ficar mais limpas e o nosso querido `go fix` vai ser nosso melhor amigo nessa transição. Se você quiser saber mais, dá uma olhada no blog oficial do Go e nas propostas técnicas que a gente citou aqui. Valeu por sintonizar o Allur, eu sou a Juliana Santos e a gente se vê no próximo episódio. Tchau!
Tags
Go
Golang
backend
modernization
generics
compiler