Remoção dos tipos centrais (Core Types) e a evolução enxuta da linguagem Go

• Com a introdução de generics no Go 1.18, foi adicionado também um novo conceito, o tipo central (core type), mas foi decidido removê-lo na versão 1.25
• O tipo central era um conceito abstrato para facilitar a implementação do compilador, substituindo o tipo subjacente (underlying type) existente no tratamento de operandos de tipos genéricos
• Na especificação da linguagem, o termo “tipo subjacente” também passou a ser substituído por “tipo central”

Parâmetros de tipo e restrições de tipo

• Parâmetros de tipo funcionam como marcadores de posição para tipos que serão definidos no futuro e são determinados em tempo de compilação
• Restrições de tipo determinam quais operações são possíveis para aquele tipo de parâmetro
• Em Go, as restrições de tipo são definidas combinando requisitos de métodos e de tipos, formando assim um conjunto de tipos (type set)
• Um conjunto de tipos significa o grupo de todos os tipos que satisfazem uma determinada interface

  type Constraint interface {  
    ~[]byte | ~string  
    Hash() uint64  
  }  
  

• Essa abordagem baseada em conjunto de tipos é muito flexível e poderosa para definir operações sobre tipos genéricos

  func at[bytestring Constraint](s bytestring, i int) byte {  
    return s[i]  
  }  
  

Introdução e limitações dos tipos centrais

• Os tipos centrais foram definidos como uma regra para simplificar o uso de tipos genéricos em algumas operações
• Forma de definição dos tipos centrais:
  • No caso de um tipo comum, o tipo central é igual ao tipo subjacente desse tipo
  • No caso de um parâmetro de tipo, só existe tipo central se todos os tipos no conjunto de tipos tiverem o mesmo tipo subjacente
• No entanto, essa abordagem gerou os seguintes problemas:
  • A especificação da linguagem ficou mais complexa, tornando difíceis de entender até mesmo regras simples
  • O conceito de tipo central passou a ser mencionado desnecessariamente até em código não genérico
  • Algumas operações que usam o conceito de tipo central ficaram restritivas demais, impedindo até operações que na prática são seguras
  • A inconsistência com regras que não usam tipos centrais reduziu a coerência do design da linguagem como um todo

Remoção dos tipos centrais no Go 1.25

• Na versão Go 1.25 (prevista para agosto de 2025), foi decidido remover o conceito de tipo central da especificação da linguagem
• A linguagem passa a adotar uma forma de descrever, com frases explícitas, as restrições necessárias para cada operação
• Principais efeitos da mudança:
  • Com menos conceitos, aprender Go fica mais fácil
  • Código não genérico fica mais claro, sem depender de conceitos de genéricos
  • Fica possível projetar regras mais flexíveis para operações específicas
  • Cria uma base para futuras expansões da linguagem (por exemplo: acesso a campos comuns, aprimoramento de recursos de slices, melhoria da inferência de tipos etc.)

Principais mudanças aplicadas e efeitos esperados

• Todas as passagens da especificação que mencionavam tipos centrais foram removidas ou substituídas por descrições explícitas
• Nas mensagens de erro do compilador, o termo tipo central também foi removido e substituído por explicações mais específicas
• Não há impacto no comportamento dos programas Go existentes
• A especificação da linguagem fica mais simples e, do ponto de vista do usuário, Go se torna mais intuitiva e clara

[GN⁺]

Comentários do Hacker News

• É bom ver que a equipe do Go trata mudanças na especificação com muito cuidado

  • Generics em Go são uma grande mudança e podem ser difíceis de usar
  • Acho que as restrições ajudam a evitar o uso excessivo de generics
  • Já vi casos em projetos Java e Typescript em que o sistema de tipos foi usado em excesso e o código ficou pouco claro
  • Espero que a equipe do Go continue adotando uma abordagem conservadora com a linguagem

• Os últimos 10 anos da equipe de desenvolvimento do Go foram um processo de busca de equilíbrio entre funcionalidades e simplicidade

  • Generics mostram bem a essência dessa dinâmica
  • Implementar sobre Go um sistema de tipos como o de Rust traz complexidade demais
  • É bom ver um pequeno retorno na direção de priorizar a simplicidade
  • O objetivo do Go é ser um Java melhor para equipes de engenheiros de nível intermediário

• O Go 1.25 não adiciona funcionalidades reais à linguagem

  • Talvez sum types sejam adicionados na 1.30

• Acompanho Go desde antes do build para Windows

  • Tudo o que aprendi em 2011 ainda continua válido
  • Não tive oportunidade de trabalhar com Go, mas venho estudando com pequenos projetos
  • Fiquei decepcionado com a fala, em uma entrevista com desenvolvedores de Go, de que parecia improvável que generics fossem introduzidos na linguagem
  • Agora que generics foram introduzidos, pretendo começar projetos paralelos em Go

• Não é verdade que, quando o argumento de close é um parâmetro de tipo, todos os tipos precisam ser canais com o mesmo tipo de elemento

  • O tipo de elemento não afeta close, e a compilação funciona bem mesmo ao usar conjuntos de tipos com diferentes tipos de elemento
  • A documentação precisa melhorar
  • Espero que a expansão de flexibilidades, como campos compartilhados, acelere

• Estou aprendendo Go devagar e tenho experiência com C++

  • Fico curioso se isso é parecido com especialização de templates
  • Gostaria que mais linguagens oferecessem suporte a isso

• [morto]

• Agora que a IA generativa já consegue escrever código, fico me perguntando se o coletor de lixo ainda é necessário

[aer0700]

Agora que a IA generativa já consegue escrever código, fico me perguntando se o coletor de lixo ainda é realmente necessário
> Bastante sugestivo...

[galadbran]

Nossa... se a IA chegar ao nível de escrever esse tipo de código (código que faz gerenciamento de memória de forma perfeita), vai ser difícil para os desenvolvedores humanos continuarem tendo o mesmo papel de hoje.

[kandk]

Dá para resolver 1+1=2 com matemática, então por que raios resolver isso com IA...

[jeiea]

Será que o GC também não tem valor no sentido de reduzir o boilerplate que humanos precisam ler e o contexto de código que precisam acompanhar?
Se a previsão é que nem vai ser preciso ler código, aí já não sei.
Pelo fato de o comentário original também estar esmaecido, parece que não é algo com que muita gente concorde.

[savvykang]

Não seria possível eliminar a contagem de referências quando for possível calcular, em tempo de compilação, os momentos de alocação e liberação de memória? Parece que o autor do comentário original no Hacker News não está entendendo o problema da reutilização de memória.