Go Concurrency Destilada

Artigo original ↗ Discussão no Hacker News ↗

As goroutines e os canais do Go são elogiados por tornar a concorrência simples e poderosa, mas muitos engenheiros acham a semântica dos canais, o cancelamento e os padrões de encerramento surpreendentemente difíceis e propensos a vazamentos ou data races. Comentadores contrastam o modelo do Go com alternativas como coroutines do Kotlin, virtual threads do Java, o BEAM do Erlang/Elixir, o STM do Haskell, async do Rust e tasks do Julia, debatendo ergonomia, segurança e o quanto de estrutura a linguagem deve impor. Um tema recorrente é que, embora o runtime e as ferramentas do Go (como o race detector) sejam fortes, escrever código concorrente robusto ainda exige design cuidadoso, contenção no uso de canais e, muitas vezes, padrões suplementares como contexts ou wait groups.

Modelo de Concorrência do Go

  • Muitos comentadores elogiam goroutines e o escalonador M:N por parecerem “mágicos” e incomumente fluidos em comparação com threads tradicionais.
  • O escalonamento preemptivo de green threads mapeado sobre threads do SO é visto como um diferencial importante em relação aos modelos cooperativos async/await.
  • Outros observam que o Go não foi o primeiro nisso (Erlang, Haskell) e argumentam que seu modelo é mais evolutivo do que revolucionário.

Canais: Poder e Dor

  • Canais e select são centrais, mas amplamente descritos como o principal ponto de dor.
  • Requisitos como fechar exatamente uma vez, pânicos em double-close ou send-to-closed, e zero-values ao receber de canais fechados são considerados pouco intuitivos e propensos a erros.
  • Desmontagem adequada, padrões com múltiplos remetentes e evitar vazamentos de goroutines exigem disciplina (contexts, waitgroups, cuidado com a posse do fechamento de canais).
  • Alguns usuários experientes dizem que canais são usados em excesso; mutexes, atomics, waitgroups e slices compartilhados simples muitas vezes bastam.

Comparações com Outras Linguagens

  • Kotlin: Coroutines + structured concurrency + trySend/tryReceive são vistos como mais ergonômicos e seguros do que canais do Go.
  • Haskell: STM, combinadores de concorrência de alto nível e composição estruturada (timeouts, races) são considerados estritamente mais poderosos e mais fáceis de raciocinar do que o estilo centrado em canais do Go.
  • Erlang/Elixir (BEAM): Apontados como um “ótimo local” para concorrência tolerante a falhas, estilo actor e supervisão; o Go é visto como mais familiar, mas menos holístico.
  • Java: virtual threads + structured concurrency + futures são defendidos como ergonomicamente superiores para muitos workloads, embora alguns observem que Java chegou depois.
  • Rust: tasks + channels sem data races são elogiados; alguns dizem que isso torna difícil voltar ao Go.
  • Julia e Zig também são citados como tendo histórias de concorrência fortes e modernas.

Ferramentas, Desempenho e Memória

  • O detector de race do Go é elogiado, mas limitado ao que os testes exercitam; comentadores querem melhores verificações estáticas para correção de mutex/atomic.
  • O comportamento de memória sob pressão e a necessidade de overprovisioning são notados; outros comparam favoravelmente com a experiência de depuração em Java.
  • Vários comentários enfatizam que o Go não é totalmente memory safe na presença de data races.

Padrões e Melhores Práticas

  • Conselho: comece com código serial; adicione concorrência apenas quando necessário e raramente via canais.
  • Use canais sem buffer por padrão; coloque buffer apenas com uma justificativa clara.
  • Prefira contexts para cancelamento e liveness, e evite múltiplos mutexes ao mesmo tempo para fugir de padrões clássicos de deadlock.