# A escolha de linguagem de programação A escolha de uma linguagem de programação raramente é uma decisão apenas técnica. Ela afeta custo de manutenção, capacidade de contratação, velocidade de entrega, risco operacional e a facilidade com que o time consegue sustentar o sistema ao longo dos anos. Em 2026, com agentes de IA gerando uma parcela crescente do código, esse cálculo ganhou uma camada adicional: a linguagem também influencia o quanto o código gerado é verificável, revisável e alinhado às restrições do projeto. A premissa continua a mesma: a escolha não deve ser pautada por modismo ou por sintaxe aparente. Deve ser pautada pelo alinhamento entre características técnicas, domínio do problema e capacidade da equipe de sustentá-la. --- ### Critérios que pesam na decisão Líderes de engenharia costumam equilibrar três grupos de fatores: 1. **Custo de construir e evoluir:** Facilidade de aprendizado, produtividade do time, qualidade do ecossistema de bibliotecas e ferramentas, e tempo de onboarding de novos engenheiros. 2. **Custo de operar:** Desempenho, consumo de recursos, previsibilidade de latência, facilidade de deploy e comportamento sob carga. 3. **Externalidades de longo prazo:** Disponibilidade de profissionais no mercado, risco de *lock-in*, maturidade do suporte, e o quanto a linguagem favorece (ou dificulta) verificação automatizada e revisão. Frameworks recentes de decisão tratam a escolha de linguagem como **decisão econômica**: o que importa não é só o tempo até o primeiro deploy, e sim o custo total por mudança aceita ao longo do ciclo de vida. --- ### O que os dados de uso mostram (2021-2025) Antes de olhar para adequação técnica, vale observar como a participação das linguagens evoluiu nos últimos anos. %[https://datawrapper.dwcdn.net/YW78f/1/] | Linguagem | 2021 (%) | 2022 (%) | 2023 (%) | 2024 (%) | 2025 (%) | Variação (p.p.) | | :--- | :--- | :--- | :--- | :--- | :--- | :--- | | **JavaScript** | 64.9 | 65.3 | 63.6 | 62.3 | 66.0 | +1.04 | | **SQL** | 47.0 | 49.4 | 48.6 | 51.0 | 58.6 | +11.52 | | **Python** | 48.2 | 48.0 | 49.2 | 51.0 | 57.9 | +9.66 | | **TypeScript** | 30.1 | 34.8 | 38.8 | 38.5 | 43.6 | +13.41 | | **Java** | 35.3 | 33.2 | 30.5 | 30.3 | 29.4 | -5.95 | | **C#.NET** | 27.8 | 27.9 | 27.6 | 27.1 | 27.8 | -0.06 | | **C++** | 24.3 | 22.5 | 22.4 | 23.0 | 23.5 | -0.81 | | **C** | 21.0 | 19.2 | 19.3 | 20.3 | 22.0 | +0.99 | | **PHP** | 21.9 | 20.8 | 18.5 | 18.2 | 18.9 | -3.08 | | **Go** | 9.5 | 11.1 | 13.2 | 13.5 | 16.4 | +6.85 | | **Rust** | 7.0 | 9.3 | 13.0 | 14.1 | 14.8 | +7.77 | | **Kotlin** | 9.1 | 9.1 | 9.0 | 9.2 | 10.8 | +1.64 | | **Swift** | 5.1 | 4.9 | 4.6 | 4.6 | 5.4 | +0.30 | *Fonte: Análise de Dados Agregados (2021–2025)*. JavaScript manteve a liderança. TypeScript, SQL e Python registraram os maiores ganhos de participação. Go e Rust avançaram de forma consistente. Java e PHP recuaram, enquanto C# permaneceu estável. Esses números não indicam qual linguagem "é melhor", mas sim movimentos de adoção. A decisão de engenharia continua dependendo do domínio, do custo de sustentação e da capacidade do time — não apenas da popularidade. --- ### Mapeamento prático das linguagens mais relevantes Com base em características técnicas consolidadas e no uso observado em produção: | Linguagem | Principais propósitos | Cenários de destaque | Facilidade | Produtividade | Confiabilidade | | :--- | :--- | :--- | :--- | :--- | :--- | | **C/C++** | Sistemas operacionais, drivers, engines, embarcados | Controle total de memória e latência muito baixa | Baixa | Média | Média (gestão manual) | | **Rust** | Sistemas, infraestrutura, WebAssembly, componentes críticos | Substituição segura de C/C++ sem garbage collector, via ownership | Baixa | Média | Altíssima | | **Go** | Serviços em nuvem, microsserviços, ferramentas de infraestrutura | Concorrência nativa, alta vazão, binários estáticos leves | Alta | Altíssima | Alta | | **Java** | Sistemas corporativos de grande porte, financeiro, legado Android | Estabilidade, retrocompatibilidade e ecossistema maduro | Média | Média/Alta | Altíssima | | **C#** | Ecossistema Microsoft, jogos (Unity), aplicações empresariais | Desenvolvimento rápido no ecossistema .NET, boa integração com ferramentas | Média | Altíssima | Altíssima | Este mapeamento serve como referência de adequação: * **C/C++** permanece onde o controle de recursos e a latência são requisitos duros. * **Rust** ganha espaço onde segurança de memória e determinismo importam, mesmo com curva de aprendizado elevada e mercado de contratação mais restrito. * **Go** se consolidou em backend e infraestrutura pela simplicidade operacional, concorrência simples e deploy previsível. * **Java** continua sendo a base de grande parte dos sistemas empresariais de longa duração, com ecossistema e pool de talentos amplos. * **C#** oferece produtividade alta e confiabilidade sólida, especialmente em ambientes já alinhados ao ecossistema Microsoft/.NET. --- ### O que Fazer vs. O que Não Fazer #### 🚫 O que NÃO Fazer 1. **Não escolha linguagem por modismo** *Exemplo do que não fazer:* "Todo mundo está usando Rust, vamos usar Rust." *O que acontece na prática:* A linguagem pode ser tecnicamente excelente, mas se o time não tem experiência, o custo de onboarding e a curva de aprendizado comprometem a entrega. *Alternativa correta:* Avalie o domínio do problema, a capacidade da equipe e o custo total de sustentação. 2. **Não ignore a verificabilidade** *Exemplo do que não fazer:* Escolher uma linguagem apenas pela velocidade de geração de código com IA. *O que acontece na prática:* Código gerado rapidamente, mas difícil de verificar e revisar. O custo de supervisão aumenta. *Alternativa correta:* Considere a combinação linguagem + toolchain + processo de verificação. 3. **Não trate a escolha como única e imutável** *Exemplo do que não fazer:* "Escolhemos Java em 2015 e nunca mais revisitamos." *O que acontece na prática:* O domínio, a escala e a composição do time mudaram. A linguagem pode não ser mais a mais adequada. *Alternativa correta:* Revise periodicamente. A linguagem certa em 2022 pode não ser a mais adequada em 2026. #### ✅ O que FAZER 1. **Trate a escolha como portfólio, não como religião** *Exemplo do que fazer:* Reconhecer que muitos sistemas maduros são poliglotas por necessidade. *Resultado prático:* Flexibilidade sem perda de controle e sem multiplicar linguagens sem critério de sustentação. 2. **Meça o custo de contratação e de onboarding** *Exemplo do que fazer:* Analisar a facilidade de encontrar e treinar profissionais na linguagem escolhida. *Resultado prático:* Decisão realista, baseada na capacidade real da equipe. 3. **Avalie o custo por mudança aceita** *Exemplo do que fazer:* Levar em conta que a geração rápida de código só reduz custo se a verificação, a revisão e a operação acompanharem. *Resultado prático:* Foco no custo total do ciclo de vida, não apenas na velocidade inicial. 4. **Externalize as restrições** *Exemplo do que fazer:* Deixar intenções de arquitetura, padrões e limites explícitos, especialmente quando agentes participam da implementação. *Resultado prático:* Agentes operam dentro de limites claros, reduzindo surpresas. 5. **Revise periodicamente** *Exemplo do que fazer:* Reavaliar a escolha da linguagem conforme o domínio, a escala ou a composição do time mudarem. *Resultado prático:* Alinhamento contínuo com o contexto atual do negócio. --- ### O que muda com o uso de agentes de IA Quando uma parcela relevante do código passa a ser gerada por agentes de IA, alguns critérios técnicos ganham peso especial: * **Verificabilidade mecânica:** Linguagens e toolchains que permitem provar mais propriedades sem executar a aplicação inteira (tipos estritos, análise estática forte, testes rápidos e determinísticos) reduzem o custo de supervisionar o que o agente produz. * **Tamanho e complexidade da toolchain:** Quanto mais camadas existem entre o código-fonte e o artefato em execução, mais pontos existem para o agente errar com confiança. Ambientes mais simples tendem a facilitar o ciclo de feedback. * **Defaults que falham de forma fechada:** Sistemas em que o comportamento padrão é restritivo (em vez de permissivo) ajudam a conter erros quando o volume de mudanças sobe. Isso não significa que uma linguagem é intrinsecamente "melhor para IA", mas sim que a combinação **linguagem + toolchain + processo de verificação** altera diretamente o custo de manter a qualidade em alta velocidade. --- ### Implicações para CTOs e líderes técnicos 1. **Trate a escolha como portfólio, não como religião.** Muitos sistemas maduros são poliglotas por necessidade. O risco está em multiplicar linguagens sem critério de sustentação. 2. **Meça o custo de contratação e de onboarding.** Uma linguagem excelente no papel torna-se cara se o time não consegue contratá-la ou treiná-la em tempo razoável. 3. **Avalie o custo por mudança aceita.** Geração rápida de código só reduz custo se a verificação, a revisão e a operação acompanharem. 4. **Externalize as restrições.** Independentemente da linguagem, intenções de arquitetura, padrões e limites precisam estar explícitos — especialmente quando agentes participam da implementação. 5. **Revise periodicamente.** A linguagem certa no passado pode não ser a mais adequada hoje se o domínio, a escala ou a composição do time mudaram. --- ### Conclusão A linguagem de programação continua sendo uma das decisões de maior impacto no custo total de engenharia. O erro mais comum não é escolher uma linguagem "errada" em abstrato, mas escolher sem considerar domínio, capacidade de sustentação e o custo real de evoluir o sistema ao longo do tempo. > *"Em um cenário em que código se torna mais abundante, a pergunta deixa de ser apenas 'qual linguagem gera mais rápido?' e passa a incluir 'qual combinação de linguagem, toolchain e processo nos permite confiar no que está sendo produzido?'"* --- ### 📚 Fontes da Pesquisa 1. **Análise de Dados Agregados de Uso de Linguagens (2021-2025)** Dados de participação de linguagens de programação no período, com destaque para crescimento de TypeScript (+13.41 p.p.), SQL (+11.52 p.p.) e Python (+9.66 p.p.), e recuo de Java (-5.95 p.p.) e PHP (-3.08 p.p.). 2. **Mapeamento técnico consolidado de propósitos e cenários** Características técnicas de C/C++, Rust, Go, Java e C# baseadas em uso observado em produção, incluindo facilidade, produtividade e confiabilidade. 3. **Discussões de líderes técnicos sobre fatores de custo de ciclo de vida** Critérios práticos para decisão de linguagem: custo de construir e evoluir, custo de operar e externalidades de longo prazo. 4. **Observações recentes sobre verificabilidade e agentes de código** Como a combinação linguagem + toolchain + processo de verificação altera o custo de manter qualidade quando a geração de código por agentes acelera. --- ### 📖 Leituras Recomendadas Quem quiser aprofundar o tema de forma estruturada — do contexto à governança de agentes — pode consultar a série *Engenharia de Software Assistida por IA*, em especial os volumes **II – Fundamentos que a IA Não Substitui** e **IV – Arquitetura e Design de Soluções na Era da IA**. 💡 **Destaques:** * 🏷️ Cupom de **30% OFF** nos eBooks: `LEIA30` * 📖 Disponível também no **Kindle Unlimited**! 👉 **Série eBook completa:** %[https://link.amazon/B09KdiptI] 📖 **Livros Físicos (capa comum):** * 📘 [Volume I – A Nova Realidade da Engenharia de Software](https://link.amazon/B0f01A62q) * 📙 [Volume II – Fundamentos que a IA Não Substitui](https://link.amazon/B0bOT75io) * 📗 [Volume III – Engenharia de Requisitos na Era da IA](https://link.amazon/B0ciMaCFt) * 📕 [Volume IV – Arquitetura e Design de Soluções na Era da IA](https://link.amazon/B0e8Z2sbn) * 📓 [Volume V – Delegação Técnica para IA](https://link.amazon/B0eBJJBKm) * 📔 [Volume VI – Supervisão e Auditoria de Código Gerado por IA](https://link.amazon/B0iK7wRo0) * 📒 [Volume VII – Aplicações Reais](https://link.amazon/B0cPlnWBN) * 📗 [Volume VIII – Engenharia de Contexto e Governança de IA](https://link.amazon/B0dmK7jno) 🔗 **Página do autor na Amazon:** %[https://link.amazon/B0igkvwcK] --- #EngenhariaDeSoftware #LinguagensDeProgramacao #ArquiteturaDeSoftware #CTO #DecisaoTecnica #Go #Rust #Java #CSharp #Cpp #TypeScript #Python #SQL #Verificabilidade #FuturoDaEngenharia