Skip to content
Go

Proposta para o Go 1.27: Revolucionando a Inferência de Tipos Genéricos com Sintaxe Abreviada

Published: Duration: 6:27
0:00 0:00

Transcript

Apresentadora: E aí, pessoal, bem-vindos de volta ao Allur! O seu ponto de encontro sobre tecnologia, Go, PHP e desenvolvimento mobile. Eu sou a Juliana Santos e hoje o papo é para quem, assim como eu, ama a simplicidade do Go, mas às vezes sente que o código poderia ser um tiquinho menos... digamos, repetitivo. Sabe quando você está escrevendo Generics e parece que está digitando a mesma coisa três vezes na mesma linha? Pois é. A proposta para o Go 1.27 promete atacar justamente essa dor com a introdução da inferência de tipos por literais abreviados. É uma mudança que parece pequena no papel, mas que na prática é uma revolução na ergonomia do dia a dia. A gente vai entender como essa "mágica" do compilador vai funcionar, o impacto nas estruturas aninhadas e por que isso deixa o Go ainda mais com aquela cara de código limpo que a gente adora. E para mergulhar nisso comigo, trouxe um convidado que manja muito de backend e ecossistema Go. Apresentadora: Hoje eu recebo o Rafael Silveira! O Rafa é desenvolvedor sênior, contribuidor da comunidade Go e trabalha diariamente escalando sistemas complexos que usam Generics desde que eles foram lançados lá na versão 1.18. Rafa, seja muito bem-vindo ao Allur, cara! Prazer enorme ter você aqui. Convidado: Valeu, Juliana! O prazer é todo meu. Sou fã do Allur e é massa demais estar aqui pra falar de Go, especialmente dessa proposta do 1.27. É algo que a gente que escreve Go no dia a dia tava esperando, né? Aquela "cereja do bolo" pra deixar os Generics mais palatáveis. Apresentadora: Com certeza! E Rafa, vamos começar do começo. Desde o Go 1.18 a gente tem Generics, o que foi um salto gigante. Mas muita gente reclama da verbosidade. Qual é o "atrito" real que o desenvolvedor sente hoje com os tipos genéricos? Convidado: Cara, o problema principal é o que a gente chama de "boilerplate visual". O Go sempre prezou pela concisão, tipo assim, você olha e entende o que tá acontecendo. Mas com Generics, a gente começou a ter que repetir o parâmetro de tipo em lugares que o compilador, teoricamente, já deveria saber o que é. Se eu declaro uma variável como um `Box` de `int`, por que na hora de atribuir o valor eu tenho que escrever `Box` de novo? Fica aquela coisa redundante, sabe? `var b Box = Box{Content: 42}`. Pô, o compilador já sabe que o `b` é `int`, pra que me fazer digitar isso de novo? Apresentadora: Pois é, parece que a gente tá explicando o óbvio pro computador o tempo todo! E é aí que entra a proposta do Go 1.27, né? Essa sintaxe `S{f: g}`. Explica pra gente como isso muda o jogo. Convidado: Exatamente, Ju. A ideia é o que eles chamam de "shorthand literals". No Go 1.27, se o compilador já tem o "tipo de destino" (o target type) bem definido, você vai poder omitir os colchetes. Então, naquele exemplo da `Box`, você escreveria só `b = Box{Content: 42}`. O compilador olha pro lado esquerdo da atribuição, vê que é um `Box` e preenche as lacunas sozinho. É uma inferência muito mais inteligente. Apresentadora: Nossa, massa! E isso não vale só pra atribuição de variável, né? Eu li que em retornos de função e argumentos isso vai ser muito útil. Como seria um exemplo prático disso? Convidado: Ah, isso vai ser lindo de ver! Imagina uma função que retorna um `Result`. Hoje você tem que dar um `return Result{Data: user}`. No Go 1.27, vai ser só `return Result{Data: user}`. O contexto do retorno da função já diz pro compilador o que ele precisa saber. E onde eu acho que o pessoal vai pirar mesmo é em estruturas aninhadas. Sabe quando você tem um mapa, onde a chave é uma string e o valor é um slice de uma struct genérica? Tipo `mapConfig`. Apresentadora: Nossa, só de imaginar o código pra preencher isso hoje já dá um cansaço (risos). Convidado: (Risos) Exato! Hoje você teria que repetir `Config` em cada elemento que adicionasse ao slice. Com a nova proposta, como o tipo do mapa já tá declarado, você só joga o `Config{...}` ali dentro e pronto. O ruído visual some. O foco volta a ser a lógica de negócio, e não a mecânica dos tipos. É o que a gente chama de código idiomático, né? Simples e direto. Apresentadora: Isso é muito a cara do Go, né? Eles demoram pra implementar as coisas, mas quando fazem, tentam manter essa filosofia de simplicidade. Mas me diz uma coisa, Rafa, tem algum perigo nisso? Tipo, o código ficar "mágico" demais ou perder a clareza que é a marca registrada do Go? Convidado: Olha, essa é uma preocupação clássica na comunidade, mas o time do Go é muito rigoroso com isso. Essa mudança é puramente "açúcar sintático" com inteligência de compilação. Ela não muda como os Generics funcionam "under the hood", sabe? E ela é totalmente retrocompatível. Se você quiser continuar escrevendo de forma explícita com os colchetes, você pode. O ponto é que o Go 1.27 está automatizando o que é óbvio. Se não tem ambiguidade, por que obrigar o humano a escrever? Eu vejo isso mais como um amadurecimento da feature do que como "mágica" perigosa. Apresentadora: Faz todo sentido. E para quem está ouvindo a gente e já usa Go no trabalho ou em projetos pessoais, como se preparar? Isso já está disponível? Convidado: Ainda não, está na fase de proposta aceita e implementação. A previsão é que chegue no ciclo do Go 1.27, seguindo aquele ritmo de lançamentos semestrais. O que eu recomendo é ficar de olho no "Go Weekly" e nas notas de release. E claro, as IDEs como o VS Code e o GoLand devem se atualizar rápido pra não marcar isso como erro. Quem já usa padrões como *Options* ou *Wrappers* genéricos vai sentir um alívio imediato na limpeza do código assim que atualizar. Apresentadora: Cara, sensacional. Eu confesso que fiquei bem empolgada. Às vezes essas mudanças pequenas na sintaxe são as que mais impactam o nosso humor durante o desenvolvimento, né? Menos código repetitivo, menos chance de erro de digitação e um código muito mais bonito de ler. Convidado: Com certeza, Ju! No fim do dia, a gente lê muito mais código do que escreve. Se a gente remove o ruído, a manutenção fica mais fácil e a gente comete menos erros bobos. O Go continua provando que dá pra evoluir sem virar um monstro de complexidade. Apresentadora: Com certeza! Bom, chegamos ao fim de mais um episódio. Rafa, obrigada demais por ter vindo aqui no Allur compartilhar essa novidade. Foi um prazer, cara! Convidado: Eu que agradeço o convite, Juliana! Valeu pessoal, e bora codar em Go! Apresentadora: É isso aí! E para você que acompanhou a gente, o que achou dessa mudança no Go 1.27? Vai facilitar sua vida ou você prefere o jeito explícito? Se quiser saber mais sobre a proposta, dá uma olhada nos links que deixamos na descrição do episódio. Valeu por sintonizar o Allur, e a gente se vê no próximo episódio. Tchau!

Tags

Go Golang software engineering backend generics type inference