Escolha da linguagem
O que muda de verdade entre Node, Python, Go, Java e C# em modelo de execução, ecossistema e operação.
Escolher a linguagem de um backend raramente é uma questão técnica pura. Os critérios que mais pesam costumam ser a equipe, as bibliotecas disponíveis para o problema e o custo de operar, nessa ordem. Desempenho entra quando a carga é grande ou o trabalho é pesado de CPU.
Os critérios, em ordem de peso
| Critério | Pergunta | Por que pesa |
|---|---|---|
| Equipe | O que as pessoas já dominam? Quem é fácil contratar? | Uma linguagem nova custa meses de produtividade e erros de quem está aprendendo |
| Ecossistema | Existem bibliotecas maduras para o que o sistema faz? | Reescrever uma biblioteca de pagamentos, PDF ou aprendizado de máquina custa mais que qualquer diferença de velocidade |
| Tipo de carga | O trabalho é esperar entrada e saída, ou calcular? | Para entrada e saída, as cinco atendem bem; para CPU, as diferenças aparecem |
| Operação | Memória, tempo de partida, tamanho do artefato | Pesa em serverless, escala a partir de zero e muitos serviços pequenos |
| Longevidade | A linguagem e o framework estarão bem mantidos daqui a dez anos? | Sistemas de negócio vivem muito mais que a moda |
| Integração | O resto da empresa usa o quê? | Bibliotecas internas, ferramentas e conhecimento compartilhado |
Pontos fortes e cuidados de cada uma
| Linguagem | Forte em | Cuidados |
|---|---|---|
| Node / TypeScript | APIs e serviços de entrada e saída; mesma linguagem no frontend e no backend; ecossistema enorme | Uma thread só: CPU pesada trava tudo; o ecossistema de pacotes exige atenção a dependências |
| Python | Dados, aprendizado de máquina e IA; automação; produtividade e legibilidade | Paralelismo de CPU exige vários processos; código Python puro é mais lento; tipos são opcionais |
| Go | Serviços de rede e infraestrutura; binário único, pequeno e de partida rápida; concorrência simples | Menos abstrações; tratamento de erros explícito e repetitivo; ecossistema menor para domínios de negócio |
| Java | Sistemas corporativos grandes e de vida longa; ecossistema maduro (Spring); ferramentas de diagnóstico excelentes | Mais memória e partida mais lenta; desempenho pleno só depois do aquecimento |
| C# | Sistemas corporativos, especialmente em ambientes Microsoft e Azure; desempenho alto; linguagem moderna | Ecossistema de código aberto menor que o do Java fora do mundo Microsoft |
Cenários comuns
| Situação | Escolhas que costumam funcionar | Por quê |
|---|---|---|
| API de produto web, equipe de fullstack | Node com TypeScript | Mesma linguagem e tipos no frontend e no backend |
| Serviços que usam modelos de IA, dados e análises | Python | O ecossistema de dados e IA está nele |
| Ferramentas de infraestrutura, proxies, agentes | Go | Binário único, pouca memória, partida instantânea |
| Sistema corporativo grande, muitos desenvolvedores, vida longa | Java ou C# | Tipagem forte, ferramentas maduras, frameworks estáveis |
| Funções serverless chamadas com pouca frequência | Go, Node ou Python | Partida rápida, pouca memória |
| Processamento pesado de CPU: imagens, cálculos | Go, Java, C#, ou Python chamando bibliotecas nativas | Execução nativa ou JIT, paralelismo real |
Uma ou várias linguagens
Microsserviços permitem uma linguagem por serviço, e isso parece uma vantagem. Na prática, cada linguagem a mais multiplica:
- bibliotecas internas (autenticação, logs, métricas, clientes de outros serviços) que precisam existir em cada uma;
- imagens base, atualizações de segurança e configurações de container;
- conhecimento necessário para quem está de plantão.
A maioria das empresas se sai melhor com uma linguagem principal, e uma segunda para um nicho claro, como Python para dados e IA ou Go para ferramentas de infraestrutura.
Mitos comuns
| Afirmação | O que de fato acontece |
|---|---|
| "Linguagem X é mais rápida, então o sistema será mais rápido" | Em sistemas de entrada e saída, consultas e rede dominam o tempo; uma consulta sem índice custa mais que qualquer diferença de linguagem |
| "Python não escala" | Instagram, Reddit e muitos outros rodam Python em grande escala; escala é arquitetura, e não linguagem |
| "Java é lento" | Depois do aquecimento, a JVM está entre os runtimes mais rápidos; o custo real está na memória e na partida |
| "Node não serve para backend sério" | Serve muito bem para entrada e saída; sofre com CPU pesada, como qualquer laço de eventos |
| "Go é sempre a escolha mais eficiente" | É eficiente em memória e partida; o ganho some se o gargalo é o banco, e o ecossistema de negócio é menor |
Resumo da decisão
- Comece pela equipe e pelo ecossistema; desempenho decide só em casos específicos.
- Entenda o modelo de concorrência da linguagem escolhida e as armadilhas dele.
- Considere memória e partida se o sistema usa serverless, escala a partir de zero ou muitos serviços pequenos.
- Prefira uma linguagem principal, com uma segunda só para um nicho claro.
- Desconfie de benchmarks que não se parecem com a sua carga.
O próximo nível mostra como cada runtime enxerga os limites de um container, com os resultados medidos, e como configurar cada um.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Escolher a linguagem do meu próximo serviço
Preciso escolher a linguagem de um novo serviço e quero tomar a decisão com critérios claros. Faça estas perguntas, uma por vez, e espere as respostas: - O que o serviço faz: API de produto, processamento de dados, integração, infraestrutura? - Que linguagens a equipe domina, e quem precisará manter o serviço? - Quais bibliotecas serão essenciais? - Como ele vai rodar: containers sempre ligados, serverless, escala a partir de zero? - Que volume de carga e que latência são esperados? - Que linguagens o resto da empresa usa? Com as respostas, avalie as opções para o meu caso pelos critérios de equipe, ecossistema, tipo de carga, operação, longevidade e integração. Seja honesto sobre quando a diferença entre as opções é pequena. Termine com a recomendação e os riscos dela.
Uma linguagem ou várias
Estamos discutindo se cada microsserviço pode usar a linguagem que a equipe preferir. Quero entender os custos e benefícios. Explique: 1. Os benefícios de permitir várias linguagens. 2. Os custos que se multiplicam: bibliotecas internas, imagens base, segurança, observabilidade, plantão, contratação. 3. Quando uma segunda linguagem se justifica, com exemplos de nichos comuns. 4. Como definir uma política de linguagens sem travar a inovação. Pergunte quantos serviços e equipes existem, e recomende uma política para o meu caso.
Avaliar um benchmark entre linguagens
Vou colar abaixo um benchmark ou um artigo que compara o desempenho de linguagens ou frameworks. Quero avaliar se a conclusão vale para o meu caso. Verifique, e para cada item diga o que o benchmark fez e o que isso significa: 1. A carga se parece com a de um backend real, com banco e serialização, ou é um "olá mundo"? 2. Os limites de CPU e memória foram respeitados pelos runtimes testados? 3. Houve aquecimento suficiente para runtimes com JIT? 4. Os servidores e frameworks testados são os usados em produção? 5. Foram apresentados percentis altos e erros, ou só médias? 6. O gerador de carga disputava recursos com o servidor? Termine dizendo o que o benchmark permite concluir e o que não permite. Benchmark: [cole aqui]