Go é excelente — quando o seu problema realmente pede Go

Go é excelente — quando o seu problema realmente pede Go

Existe uma tentação recorrente no desenvolvimento de software: descobrir uma linguagem interessante e começar a enxergar qualquer problema como uma desculpa para usá-la.

Com Go, isso acontece fácil.

A linguagem é rápida, compilada, fortemente tipada, tem uma sintaxe relativamente pequena, uma biblioteca padrão muito competente, concorrência embutida na linguagem e gera executáveis que tornam o deploy surpreendentemente simples em muitos cenários.

Aí alguém olha para tudo isso e conclui:

"Então vou fazer tudo em Go."

Calma.

O que torna Go excelente não é ser a melhor linguagem para qualquer aplicação. É o fato de que, quando os requisitos do sistema combinam com as decisões de design da linguagem, Go encaixa de um jeito quase desconfortavelmente bom.

E esse é o ponto deste artigo.

Não quero discutir Go como torcida organizada. Quero discutir quando ele faz sentido tecnicamente.

---

Primeiro: Go ou Golang?

O nome oficial da linguagem é Go.

"Golang" virou um apelido extremamente popular, em boa parte porque o domínio originalmente usado pelo projeto era golang.org e porque pesquisar apenas "Go" na internet sempre foi... digamos... pouco específico.

Então, se alguém disser Golang, está falando de Go.

---

O que Go está tentando resolver?

A própria documentação oficial descreve Go como uma linguagem compilada, estaticamente tipada, eficiente e com mecanismos de concorrência pensados para aproveitar máquinas multicore e sistemas conectados em rede.

Essa frase já entrega boa parte da vocação da linguagem.

Go nasceu dentro do Google em um ambiente no qual alguns problemas eram recorrentes:

• sistemas grandes;
• builds demorados;
• muitos serviços;
• infraestrutura distribuída;
• necessidade de concorrência;
• servidores lidando com muitas conexões;
• equipes grandes mantendo código por muito tempo.

Não por acaso, hoje o próprio site oficial destaca como casos de uso:

• Cloud e serviços de rede;
• CLIs;
• desenvolvimento web;
• DevOps e SRE.

Esse contexto importa porque uma linguagem também carrega as prioridades de quem a desenhou.

---

O primeiro pré-requisito: seu problema tem concorrência de verdade?

Aqui começa a ficar interessante.

Go possui goroutines, funções que podem executar concorrentemente e que são muito mais leves que a ideia tradicional de criar uma thread do sistema operacional para cada trabalho.

Você pode escrever algo conceitualmente simples como:

go processarPedido(pedido)

Isso não quer dizer que concorrência virou mágica. Race condition continua existindo. Deadlock continua existindo. Código concorrente continua exigindo raciocínio.

Mas Go trata concorrência como cidadã de primeira classe.

Além das goroutines, existem channels, mutexes, context e uma biblioteca padrão desenhada em torno desse modelo.

Isso é especialmente interessante quando sua aplicação precisa lidar simultaneamente com:

• milhares de conexões;
• filas;
• workers;
• processamento paralelo de tarefas independentes;
• chamadas a múltiplas APIs;
• pipelines;
• sockets;
• eventos;
• coleta de dados;
• serviços de rede.

Imagine, por exemplo, um integrador de marketplace que precisa consultar estoque, preço, pedidos, logística e reputação de milhares de anúncios.

Grande parte desse tempo não é CPU.

É espera por rede.

Enquanto uma requisição está aguardando uma resposta externa, outras podem continuar trabalhando.

Esse é um cenário muito natural para Go.

---

Mas cuidado: concorrência não significa automaticamente performance

Esse detalhe é importante.

Se sua aplicação é basicamente:

1. receber uma requisição;
2. consultar um banco;
3. montar HTML;
4. devolver a página;

e ela já responde bem com sua stack atual, migrar tudo para Go apenas para dizer que usa goroutines provavelmente é arquitetura orientada a currículo.

Go fica mais interessante quando a concorrência faz parte da natureza do problema, não quando você precisa inventar concorrência para justificar a linguagem.

---

Segundo pré-requisito: você precisa de serviços pequenos, independentes e fáceis de distribuir?

Aqui Go é muito confortável.

Em muitos projetos sem dependências nativas via cgo, você consegue compilar sua aplicação e distribuir praticamente um único executável.

Algo na linha:

go build -o minha-api

E pronto: você tem um binário.

Isso muda bastante a experiência operacional.

Em determinados cenários, você não precisa instalar runtime de linguagem no servidor, gerenciar dezenas de dependências em produção ou replicar exatamente o ambiente de desenvolvimento.

Naturalmente, containers já resolveram uma parte enorme desse problema em várias stacks. Mas mesmo dentro de containers, binários Go costumam produzir uma experiência operacional muito conveniente.

Por isso Go aparece tanto em:

• agentes;
• proxies;
• ferramentas de infraestrutura;
• sidecars;
• exporters;
• serviços internos;
• APIs;
• ferramentas de observabilidade;
• CLIs.

Existe um motivo para projetos como Docker, Kubernetes, Terraform, Prometheus e muitos componentes importantes do ecossistema cloud terem sido construídos em Go.

A linguagem se encaixa muito bem nesse tipo de software.

---

Terceiro pré-requisito: latência, throughput ou consumo de recursos importam?

Agora entramos em uma área em que a resposta precisa ser cuidadosa.

Go é rápido.

Mas "rápido" sem contexto não significa nada.

Para muitas aplicações web tradicionais, PHP, Node.js, Python, Ruby ou Java já entregam performance mais do que suficiente.

Se seu sistema atende 30 usuários simultâneos, reduzir uma operação de 12 ms para 3 ms talvez não tenha qualquer impacto econômico.

Mas há situações em que eficiência operacional começa a importar:

• dezenas ou centenas de milhares de requisições;
• grande quantidade de processos simultâneos;
• aplicações que permanecem residentes em memória;
• serviços replicados em muitas instâncias;
• processamento contínuo;
• custos de cloud relevantes;
• limites rígidos de latência.

Nesses casos, uma linguagem compilada como Go pode produzir ganhos bastante interessantes.

Mas aqui existe uma regra que vale ouro:

Antes de trocar de linguagem por performance, meça onde está o gargalo.

Seu problema pode estar no banco de dados.

Pode estar em uma API externa.

Pode estar em uma query sem índice.

Pode estar em serialização.

Pode estar numa arquitetura que realiza vinte chamadas onde deveria realizar duas.

Reescrever em Go não corrige arquitetura ruim por osmose.

---

Quarto pré-requisito: você quer simplicidade operacional?

Essa talvez seja uma das características de Go que mais me agradam conceitualmente.

A linguagem tem uma forte preferência por soluções explícitas.

O próprio ecossistema traz ferramentas oficiais que reduzem discussões que em outras comunidades viram quase religião.

Formatação?

gofmt.

Testes?

A biblioteca padrão já oferece suporte direto.

Profiling?

pprof.

Detecção de problemas?

go vet.

Gerenciamento de módulos?

go mod.

No Go 1.27, inclusive, o tooling continuou recebendo atenção: go fix, go doc, go mod tidy e o runtime receberam melhorias.

É uma linguagem que frequentemente escolhe padronização em vez de infinitas possibilidades.

Para quem trabalha em equipe, isso pode valer muito.

---

Quinto pré-requisito: você quer código que provavelmente será mantido por muita gente?

Go é deliberadamente pouco extravagante.

Isso é elogio.

O código tende a ser relativamente explícito e a linguagem evita possuir vinte maneiras sintaticamente elegantes de resolver a mesma coisa.

Em uma equipe grande, isso reduz a distância entre:

"Eu entendo a linguagem."

e:

"Eu entendo o estilo completamente particular em que este programador resolveu escrever a linguagem."

É uma vantagem importante em software de infraestrutura e backend.

Você pode abrir um projeto Go que nunca viu e, frequentemente, começar a identificar rapidamente:

• packages;
• structs;
• interfaces;
• handlers;
• goroutines;
• tratamento de erros;
• testes.

A previsibilidade ajuda manutenção.

---

E o famoso if err != nil?

Agora chegamos à parte em que os fãs de outras linguagens começam a rir.

Go historicamente usa tratamento explícito de erros.

Algo como:

resultado, err := executar()
if err != nil {
    return err
}

Você vai escrever isso bastante.

Em troca, o fluxo de erro normalmente fica muito visível.

É verboso? Às vezes.

É ruim? Depende do que você valoriza.

Go frequentemente prefere repetir algumas linhas a esconder comportamento importante atrás de abstrações excessivas.

Para determinados times, essa previsibilidade é ótima.

Para outros, irritante.

E está tudo bem.

---

Go 1.27: a linguagem continua evoluindo sem virar outra linguagem

Em agosto de 2026 foi lançado o Go 1.27.

A versão trouxe generic methods, melhorias na inferência de tipos, otimizações no runtime e mudanças relevantes na biblioteca padrão.

Uma delas é particularmente interessante para backend: o novo encoding/json/v2, acompanhado de encoding/json/jsontext.

A implementação traz opções mais modernas, defaults mais rigorosos e melhorias de desempenho em unmarshalling.

Outro ponto interessante é que o Go continua mantendo sua promessa de compatibilidade da série Go 1.

Isso é extremamente relevante em sistemas que precisam sobreviver durante anos.

A linguagem evolui, mas tenta não obrigar você a reconstruir seu projeto a cada nova moda sintática.

---

O mercado gosta de Go?

Go está longe de ser a linguagem mais usada do planeta.

E isso não é problema.

Na pesquisa de desenvolvedores do Stack Overflow de 2026, 16,5% dos respondentes disseram ter usado Go extensivamente no último ano.

Mais interessante, porém, é outra métrica: Go apareceu com 49,5% na categoria "Admired", que representa usuários que trabalharam com a tecnologia e querem continuar usando.

Ou seja: ela não lidera em adoção bruta, mas mantém um nível bastante saudável de satisfação entre quem efetivamente trabalha com ela.

Para uma linguagem com foco forte em backend, cloud e infraestrutura, é um sinal relevante.

---

Onde eu usaria Go sem pensar muito?

Se eu recebesse hoje alguns tipos de projeto, Go entraria imediatamente na lista de candidatos.

API de alto volume

Uma API que precise atender muitas requisições simultâneas, com regras bem definidas e grande volume de I/O.

Boa candidata.

Worker de fila

Consumir eventos, consultar APIs, transformar dados e publicar resultados.

Excelente cenário.

Gateway ou proxy

Receber requisições, aplicar regras, autenticar, redirecionar, limitar tráfego.

Go combina muito bem.

Serviço de sincronização

Imagine sincronizar:

• Mercado Livre;
• Shopee;
• Amazon;
• ERP;
• estoque local;
• transportadoras.

Você terá chamadas independentes, concorrência, retries, timeouts e muito I/O.

É quase uma propaganda de Go.

CLI

Aqui Go é particularmente agradável.

Você compila, distribui o executável e acabou.

Não precisa explicar ao usuário como configurar todo um runtime para rodar uma ferramenta de terminal.

Agente instalado em servidores

Monitoramento, métricas, coleta de logs ou automação local.

Novamente: excelente encaixe.

---

Onde eu provavelmente NÃO escolheria Go como primeira opção?

Essa parte é tão importante quanto todo o resto.

Um CRUD administrativo convencional

Se vou construir um painel administrativo com:

• autenticação;
• formulários;
• permissões;
• relatórios;
• e-mails;
• jobs;
• ORM;
• páginas;
• dezenas de regras de negócio;

eu não abandonaria automaticamente Laravel, Rails, Django ou outro framework produtivo para escrever tudo em Go.

O ganho técnico pode ser menor que a perda de produtividade.

Um Laravel bem arquitetado resolve esse tipo de sistema absurdamente rápido.

E esse tempo de desenvolvimento também custa dinheiro.

---

Um MVP que precisa estar no ar amanhã

Se a principal restrição é velocidade de validação, escolha a stack em que você ou sua equipe produzem mais rápido.

Performance prematura não paga boleto.

Usuário usando o produto paga.

---

Data science e machine learning

Python continua possuindo um ecossistema muito mais natural para treinamento, experimentação, notebooks e bibliotecas de IA.

Go pode servir APIs de inferência, gateways e infraestrutura ao redor do modelo.

Mas não seria minha primeira escolha para substituir Python no núcleo do trabalho científico.

---

Frontend

Pode até existir WebAssembly e experimentação.

Mas se a pergunta é qual tecnologia escolher para construir uma interface web convencional, TypeScript/JavaScript continuam sendo o caminho natural.

---

Então Go substitui PHP?

Não.

Essa pergunta, inclusive, parte de uma premissa que eu não gosto muito.

Linguagens não precisam se matar para justificar a própria existência.

Eu posso perfeitamente ter:

• Laravel cuidando do sistema administrativo;
• PostgreSQL armazenando os dados;
• Redis gerenciando cache;
• Go processando uma fila pesada;
• Python executando uma rotina de IA;
• TypeScript cuidando do frontend.

Isso não é bagunça necessariamente.

É arquitetura.

O erro é criar uma salada tecnológica sem necessidade.

Mas usar tecnologias diferentes porque cada uma resolve melhor uma parte específica do sistema pode ser extremamente racional.

Inclusive, para quem já trabalha fortemente com PHP, Go pode ser uma segunda linguagem muito interessante justamente porque complementa algumas áreas em que PHP tradicionalmente não é a escolha mais natural.

---

Uma arquitetura híbrida que faz bastante sentido

Imagine um sistema de integração de marketplaces.

O painel administrativo pode continuar em Laravel.

Usuários, permissões, configurações, dashboards e operações de backoffice permanecem onde o framework é altamente produtivo.

Mas você possui um serviço que precisa:

1. consumir milhares de mensagens de uma fila;
2. consultar diferentes APIs;
3. controlar limites de requisição;
4. fazer retries;
5. processar tarefas concorrentemente;
6. registrar métricas;
7. sobreviver como daemon por longos períodos.

Esse componente pode ser escrito em Go.

O painel continua usando a ferramenta que entrega produtividade.

O worker usa uma ferramenta cuja arquitetura combina profundamente com o problema.

É esse tipo de decisão que considero madura.

---

Um pequeno checklist: sua aplicação "pede" Go?

Antes de escolher a linguagem, eu faria estas perguntas:

• Existem muitas tarefas simultâneas?
• Grande parte do trabalho é I/O?
• O serviço precisa permanecer rodando continuamente?
• Ele precisa atender muitas conexões?
• Um executável simples facilitaria muito o deploy?
• Consumo de memória ou CPU representa custo relevante?
• Será um serviço independente?
• Observabilidade e profiling são importantes?
• A equipe valoriza uma linguagem pequena e padronizada?
• O sistema será mantido durante muitos anos?

Quanto mais respostas positivas, mais interessante Go se torna.

Agora faça o contrário:

• É um CRUD convencional?
• O tráfego é baixo?
• O framework atual resolve tudo?
• O maior custo é tempo de desenvolvimento?
• A equipe não conhece Go?
• Não existe qualquer problema real de concorrência ou performance?

Talvez você esteja tentando resolver um problema que não existe.

---

A melhor tecnologia continua sendo a que resolve o problema

Eu gosto muito da ideia de aprender Go.

Especialmente para quem já trabalha com sistemas web e quer avançar em:

• infraestrutura;
• serviços distribuídos;
• alta concorrência;
• networking;
• cloud;
• DevOps;
• ferramentas de linha de comando;
• backend de alto volume.

Ela força um contato mais direto com conceitos que alguns frameworks conseguem esconder bastante bem.

Mas eu não trocaria uma stack consolidada só porque Go aparece melhor em benchmark.

Software não vive dentro de benchmark.

Software vive em empresa, servidor, orçamento, equipe, prazo, manutenção e usuário.

E é exatamente por isso que Go é tão boa quando os pré-requisitos são atendidos.

Você não precisa forçar a linguagem.

Quando o problema certo aparece, ela praticamente se oferece sozinha.

---

Referências

• Documentação oficial do Go: https://go.dev/doc/
• Casos de uso oficiais: https://go.dev/solutions/use-cases
• Effective Go — concorrência e goroutines: https://go.dev/doc/effective_go
• Go 1.27 Release Notes: https://go.dev/doc/go1.27
• Go 1.27 announcement: https://go.dev/blog/go1.27
• Stack Overflow Developer Survey 2026 — Languages: https://survey.stackoverflow.co/2026/technology/data/languages