Proposta em Golang: container/: tipos de coleção genéricos

Artigo original ↗ Discussão no Hacker News ↗

Uma proposta para adicionar tipos de coleção genéricos como sets, maps e heaps à biblioteca padrão do Go reacendeu o debate sobre a evolução da linguagem, do minimalismo para uma maior abstração. Defensores argumentam que esses recursos já deveriam existir há muito tempo, reduzirão boilerplate e darão melhor suporte a casos de uso do mundo real, especialmente para autores de bibliotecas. Críticos temem que genéricos, iteradores e contêineres mais complexos corroam a simplicidade original do Go e seu design orientado a desempenho, vendo as mudanças como uma convergência tardia e algo relutante para padrões há muito presentes em linguagens como Java, C# e Rust.

Reação geral à proposta de contêineres genéricos

  • Muitos acolhem coleções genéricas padrão (sets, heaps tipadas etc.) como “antes tarde do que nunca”.
  • Alguns veem isso como algo que torna diretamente o “código comum” mais fácil, evitando contêineres feitos à mão e boilerplate.
  • Outros se preocupam que isso acelere o afastamento do Go de sua identidade minimalista original.

Genéricos em Go: adequação e filosofia

  • Vários argumentam que genéricos acabaram sendo necessários para bibliotecas idiomáticas (coleções, wrappers de JSON/API, helpers de canais).
  • Críticos dizem que os genéricos não se encaixam limpidamente nas escolhas de design anteriores (por exemplo, sem métodos em tipos externos), levando a padrões estranhos e contornos em tempo de execução.
  • Defensores dizem que o design prioriza a legibilidade do uso genérico em vez da ergonomia para autores de código genérico e mantém os tempos de compilação rápidos.

Simplicidade vs poder

  • Um grupo valoriza a simplicidade “YAGNI” do Go e vê mais recursos como portas abertas para código “esperto” e mais difícil de manter.
  • Outro grupo responde que o Go nunca esteve na “fronteira de Pareto”; sua simplicidade muitas vezes empurrou a complexidade para o código do usuário (contêineres duplicados, assertions de tipo).
  • Alguns lamentam que o Go esteja convergindo para uma linguagem “corporativa/elefantina” como Java, perdendo seu nicho como a alternativa simples.

Map/iterators e estilo funcional

  • Debate sobre operações no estilo Map/filter:
    • Pró: código mais curto e claro para padrões comuns de transformação; raciocínio mais fácil quando os dados são tratados como imutáveis.
    • Contra: lambdas verbosas em Go e inlining mais fraco tornam isso menos ergonômico; loops for explícitos são mais claros e flexíveis.
  • Iteradores/streams são vistos por alguns como poderosos e componíveis; outros destacam novos modos de falha (por exemplo, uso incorreto ao interromper a iteração).

Tratamento de erros e ergonomia

  • Alguns gostariam que o Go tivesse adotado uma construção de tratamento de erros mais concisa e componível; os padrões atuais são vistos como ruidosos e priorizando “caminhos tristes”.
  • Outros insistem que verificações explícitas de erro são uma força central e que tentativas de açúcar sintático têm armadilhas de design no modelo do Go.

História, timing e “esforço desperdiçado”

  • Vários comentários argumentam que resistir aos genéricos por anos causou grandes quantidades de código de contorno e dívida técnica.
  • Outros respondem que a evolução de linguagens sempre implica algum “desperdício”, e que a equipe adiou os genéricos para evitar a complexidade ao estilo Java/C++.
  • Garantias de compatibilidade retroativa significam que a biblioteca padrão precisa evoluir devagar e com cuidado; alguns aceitam isso, outros acham frustrante.

Comparações, ecossistema e futuro

  • Comparações frequentes com Rust, Java, C#, Smalltalk, Lisp, JavaScript, .NET e GCs da JVM; as visões divergem sobre se o Go está alcançando ou perdendo seus diferenciais.
  • Alguns atribuem o sucesso do Go בעיקר a Google, Docker e Kubernetes; outros dizem que seu runtime, modelo de implantação e tooling se sustentam por conta própria.
  • Não há consenso claro sobre a direção de longo prazo do Go: alguns estão satisfeitos em “deixar rolar”, outros consideram migrar para linguagens mais ricas em recursos.