01 - Go

Uma linguagem desenhada para times grandes lendo código velho, não para escrever código curto. Entender isso explica quase todas as decisões estranhas do Go.

Definições e explicações

• 1. Go — a tese da linguagem: o que ela recusou de propósito
• 2. Goroutines e Channels — concorrência barata e o vazamento que ela produz
• 3. Erros, Interfaces e o Estilo Go — erro é valor, interface é implícita, composição no lugar de herança
• 4. Versões, Módulos e Compatibilidade — o ciclo de 6 meses, a promessa Go 1 e o que o Go 1.27 mudou
• 5. Go em Produção — contêiner, pools, pprof: onde Go quebra de verdade
• 6. Runtime, Scheduler e GC — G-M-P, work stealing, GOMAXPROCS em cgroup, o pacer do GC
• 7. Memória, Slices e Maps por Dentro — escape analysis, o array compartilhado, map e concorrência
• 8. Race Conditions e o Modelo de Memória — data race ≠ race condition, happens-before, -race
• 9. Mutex vs Channel — as duas famílias de sincronização e quando usar cada uma

A ideia que atravessa a seção

Go troca expressividade por previsibilidade. Não há herança, exceções, sobrecarga de operador, macro nem construtor. O resultado é uma linguagem em que quase não existe "jeito esperto" — e por isso o código de um estranho, escrito há três anos, ainda se lê de cima para baixo.

O preço é visível em cada arquivo: você escreve if err != nil centenas de vezes. Não é um descuido do design, é o design: o fluxo de erro fica no mesmo lugar onde os olhos já estão, em vez de num catch distante.

Quando você achar uma limitação do Go irritante, procure qual leitura ela protege. Costuma haver uma.

A exceção a essa regra é a concorrência: ali o Go não protege você. go f() custa uma palavra a mais de digitação e abre a porta para data race, vazamento de goroutine e deadlock — nada disso pego pelo compilador. É por isso que 8. Race Conditions e o Modelo de Memória e 9. Mutex vs Channel fecham a seção: a parte mais fácil de escrever é a mais difícil de acertar.

---

Parte de Linguagens · go.dev/doc