Escrever Go para infraestrutura — o que o Python não me preparou para isso
Fiz a transição de Python para Go para trabalho de plataforma. Aqui está o que realmente muda — além da sintaxe.
Aprendi Python quando precisava fazer análise de dados. Aprendi Go quando precisei construir ferramentas de infraestrutura. As duas linguagens me ensinaram coisas diferentes — não só sobre código, mas sobre como pensar em software.
A primeira semana com Go foi estranha. Python me acostumou com uma certa fluidez — você escreve algo, roda, vê o resultado, ajusta. O loop é rápido e permissivo. Go é mais cerimonioso: você precisa declarar tipos, o compilador não perdoa variável não usada, não existe duck typing implícito. Parecia burocrático.
Na segunda semana entendi por quê esse cerimônia existe.
Go força você a ser explícito sobre intenções. Quando você declara um tipo, você está documentando o que aquela variável deve ser. Quando o compilador recusa importação não usada, está prevenindo a entropia que acumula em projetos grandes. Quando error handling é explícito em vez de exceção implícita, você é forçado a pensar em cada lugar onde algo pode dar errado.
Em Python, você pode escrever código que funciona sem pensar muito em falha. Em Go, a linguagem te força a pensar em falha a cada chamada de função que retorna error.
Para infraestrutura, essa característica de Go é exatamente o que você precisa. Ferramentas de infra rodam em produção, geralmente sem supervisão humana direta. Um panic não tratado pode derrubar um serviço crítico. Uma goroutine com memory leak pode consumir recursos ao longo de dias até causar problemas. Go tem mecanismos — defer, recover, context com cancelamento — que tornam o tratamento desses casos parte natural do código, não afterthought.
O modelo de concorrência foi a maior revelação. Goroutines e channels permitem escrever código concorrente que é genuinamente legível. Quando você precisa fazer múltiplas chamadas de API em paralelo e agregar os resultados, Go torna isso limpo — não só possível, mas idiomático.
O que Python não me preparou: pensar em tipagem como design. Em Python, tipos são opcionais e às vezes inconvenientes. Em Go, o sistema de tipos é a principal ferramenta de design da interface. Você pensa: qual é o contrato entre esses dois módulos? Que tipos representam esse contrato? Como eu uso o compilador para garantir que o contrato seja respeitado?
Essa forma de pensar melhorou meu código em todas as linguagens — incluindo Python. Comecei a usar type hints de forma mais rigorosa depois de trabalhar com Go.
A toolchain de Go é outro ponto de diferença. go build, go test, go fmt, go vet — tudo embutido, tudo consistente. Não existe decisão sobre qual formatter usar, qual test runner usar, qual build tool usar. Isso soa como perda de flexibilidade mas na prática é ganho de foco. Você passa menos tempo configurando ferramentas e mais tempo usando.
Para projetos de plataforma onde múltiplos times contribuem, essa consistência tem valor imenso. Todo Go parece Go. Isso não é verdade para Python, onde cada projeto tem suas próprias convenções de projeto, test framework e style guide.
O que me surpreendeu mais depois de um ano escrevendo Go: quanto mais claramente eu penso sobre erros. Go não tem exceções — tem retorno explícito de error. No início isso parece tedioso. Depois de um tempo, você percebe que está perto da realidade: cada operação pode falhar, e o código que não trata esse fato é código que vai causar incidente em produção.
Esse padrão de pensar sobre falha explicitamente contaminou positivamente como eu escrevo código em outras linguagens.
Essa semana: se você nunca escreveu Go, escreve um programa simples — pode ser uma ferramenta de linha de comando que lê um arquivo, processa algo e escreve output. O objetivo não é aprender Go em uma semana. É entender como a linguagem te força a pensar sobre tipos e erros de uma forma diferente do que você está acostumado.