Por que as linguagens de programação raramente morrem — elas encontram novos nichos

O que realmente significa uma linguagem “morrer"

As pessoas dizem que uma linguagem de programação está “morta” quando para de aparecer nas redes sociais, cai em uma pesquisa de desenvolvedores ou não é ensinada no último bootcamp. Isso não é morte — é perda de visibilidade.

Uma linguagem está verdadeiramente “morta” só quando não pode mais ser usada na prática. Em termos reais, isso geralmente significa que várias coisas acontecem ao mesmo tempo: não há usuários reais, não há compiladores ou interpretadores mantidos e não há uma maneira razoável de construir ou executar código novo.

Uma definição prática de “morrer”

Se você quer uma checklist concreta, uma linguagem está quase morta quando a maioria destes itens é verdadeira:

• Sem implementações ativas (compiladores/interpretadores não rodam nos sistemas operacionais ou hardwares atuais)
• Sem toolchain viável (ferramentas de build, depuradores, gerenciadores de pacotes, editores estão quebrados ou abandonados)
• Sem movimento no ecossistema (bibliotecas não podem ser atualizadas, problemas de segurança não recebem patch)
• Sem código novo em contextos significativos (não apenas projetos hobby — trabalho real para por)

Mesmo assim, “morta” é rara. Código‑fonte e especificações podem ser preservados, forks podem reiniciar manutenção e empresas às vezes pagam para manter uma toolchain viva porque o software ainda tem valor.

A ideia principal: linguagens não desaparecem — elas mudam de forma

Mais frequentemente, linguagens encolhem, se especializam ou ficam embutidas em stacks mais novos.

• Encolhem: menos projetos greenfield, mas muito trabalho de manutenção.
• Especializam: uso concentrado em um domínio onde a linguagem ainda é eficiente ou confiável.
• Embutidas: a linguagem vira a camada “interna” — scripting, extensões, código cola ou dependência de runtime.

O que esperar no mundo real

Em setores diferentes você verá “vidas após a morte” distintas: sistemas empresariais mantêm linguagens antigas em produção, ciência preserva ferramentas numéricas comprovadas, dispositivos embarcados priorizam estabilidade e desempenho previsível, e a web mantém linguagens de longa duração relevantes por meio da constante evolução de plataformas.

Este artigo é escrito para leitores não técnicos e tomadores de decisão — pessoas escolhendo tecnologias, financiando reescrituras ou gerenciando riscos. O objetivo não é argumentar que toda linguagem antiga é uma boa escolha; é explicar por que manchetes sobre “linguagem morta” frequentemente perdem o que realmente importa: se a linguagem ainda tem um caminho viável para rodar, evoluir e ser suportada.

Software sobrevive a tendências

Linguagens de programação não sobrevivem porque vencem concursos de popularidade. Elas sobrevivem porque o software escrito nelas continua a entregar valor muito depois que as manchetes seguem em frente.

Um sistema de folha de pagamento que roda a cada duas semanas, um motor de faturamento que reconcilia faturas ou um agendador de logística que mantém armazéns abastecidos não é “cool” — mas é o tipo de software que uma empresa não pode perder. Se funciona, é confiável e tem anos de casos de borda incorporados, a linguagem por baixo ganha longa vida por associação.

Valor de negócio vence moda técnica

A maioria das organizações não corre atrás da stack mais nova. Elas tentam reduzir risco. Sistemas maduros costumam ter comportamento previsível, modos de falha conhecidos e um rastro de auditorias, relatórios e conhecimento operacional. Substituí‑los não é só um projeto técnico; é um projeto de continuidade de negócio.

Custos de mudança são reais (e frequentemente subestimados)

Reescrever um sistema funcional pode significar:

• Reciclar equipes (ou contratar expertise escassa)
• Migrar dados e reconstruir integrações
• Aceitar risco de downtime durante o corte
• Revalidar resultados, controles e requisitos de compliance

Mesmo se a reescrita for “possível”, pode não valer o custo de oportunidade. Por isso linguagens associadas a sistemas de longa duração — pense em mainframes, plataformas financeiras, controles de manufatura — permanecem em uso ativo: o software ainda ganha dinheiro.

Analogia: infraestrutura vs. gadgets

Trate linguagens de programação como infraestrutura e não como gadgets. Você pode trocar de celular a cada poucos anos, mas não reconstrói uma ponte porque um novo design está em voga. Enquanto a ponte suportar o tráfego com segurança, você a mantém, reforça e adiciona ramais.

É assim que muitas empresas tratam software crítico: mantém, moderniza nas bordas e mantém a base comprovada rodando — frequentemente na mesma linguagem por décadas.

Sistemas legados mantêm linguagens em uso ativo

Um “sistema legado” não é um sistema ruim — é simplesmente software que está em produção tempo suficiente para se tornar essencial. Pode rodar folha de pagamento, pagamentos, inventário, instrumentos de laboratório ou registros de clientes. O código pode ser antigo, mas o valor de negócio é atual, e isso mantém as “linguagens legadas” em uso ativo no software empresarial.

Por que reescritas são mais arriscadas do que parecem

Organizações frequentemente consideram reescrever uma aplicação de longa duração numa stack mais nova. O problema é que o sistema existente geralmente contém anos de conhecimento conquistado:

• Regras de negócio ocultas que nunca foram totalmente documentadas
• Casos de borda descobertos só quando clientes reais e dados reais entraram em produção
• Comportamento de compliance (trilhas de auditoria, relatórios, retenção) que foi validado ao longo do tempo

Quando você reescreve, não está apenas recriando funcionalidades — está recriando comportamento. Diferenças sutis podem causar quedas, erros financeiros ou problemas regulatórios. Por isso sistemas em mainframe e COBOL ainda suportam workflows críticos: não porque equipes amem a sintaxe, mas porque o software é comprovado e confiável.

Modernização incremental é o caminho comum

Em vez de uma reescrita “big bang”, muitas empresas modernizam por etapas. Mantêm o núcleo estável e substituem pedaços gradualmente:

• Envolver serviços antigos com APIs
• Migrar módulos específicos deixando o restante intacto
• Mover acesso a dados ou interfaces para componentes mais novos
• Usar interoperabilidade de linguagem para conectar runtimes antigos e novos

Essa abordagem reduz risco e dilui custo ao longo do tempo. Também explica a longevidade de linguagens: enquanto sistemas valiosos dependerem de uma linguagem, habilidades, ferramentas e comunidades continuam existindo ao seu redor.

Estabilidade pode ser vantagem competitiva

Codebases mais antigos costumam priorizar previsibilidade sobre novidade. Em ambientes regulados ou de alta disponibilidade, estabilidade “sem graça” é uma característica. Uma linguagem que consegue rodar o mesmo programa confiável por décadas — como Fortran na ciência ou COBOL nas finanças — pode permanecer relevante justamente porque não muda rapidamente.

Ecossistemas e tooling são equipamento de sobrevivência

Uma linguagem de programação não é só sintaxe — é o ecossistema ao redor que a torna utilizável dia após dia. Quando as pessoas dizem que uma linguagem está “morta”, muitas vezes querem dizer: “é difícil construir e manter software real com ela”. Um bom conjunto de ferramentas evita isso.

Tooling que mantém uma linguagem prática

Compiladores e runtimes são a base óbvia, mas a sobrevivência depende do banco de trabalho cotidiano:

• Gerenciadores de pacotes e registros facilitam reusar bibliotecas, aplicar patches de segurança e padronizar builds entre equipes.
• IDEs e plugins de editor reduzem atrito com autocomplete, refatoração, pular para definição e depuração.
• Linters e formatadores ajudam equipes a escrever código consistente e detectar erros cedo.
• Runners de teste e integrações de CI transformam “funciona na minha máquina” em releases repetíveis.

Mesmo uma linguagem antiga pode se manter “viva” se essas ferramentas continuarem mantidas e acessíveis.

Melhor tooling pode gerar novo interesse

Um padrão surpreendente: upgrades de tooling muitas vezes revivem uma linguagem mais do que novos recursos de linguagem. Um servidor de linguagem moderno, compilador mais rápido, mensagens de erro mais claras ou fluxo de dependências mais suave podem fazer um código legado parecer acessível novamente.

Isso importa porque recém‑chegados raramente avaliam uma linguagem no vácuo — eles avaliam a experiência de construir algo com ela. Se a configuração leva minutos em vez de horas, comunidades crescem, tutoriais se multiplicam e contratar fica mais fácil.

Estabilidade: LTS e caminhos conservadores de atualização

Longevidade também vem de não quebrar usuários. Releases de suporte a longo prazo (LTS), políticas claras de deprecação e caminhos de atualização conservadores permitem que empresas planejem upgrades sem reescrever tudo. Quando atualizar parece seguro e previsível, organizações continuam investindo na linguagem em vez de fugir dela.

Documentação é parte do ecossistema

Docs, exemplos e recursos de aprendizagem são tão importantes quanto código. Guias claros de “comece aqui”, notas de migração e receitas do mundo real abaixam a barreira para a próxima geração. Uma linguagem com documentação forte não apenas perdura — ela continua adotável.

Padrões e compatibilidade retroativa reduzem risco

Uma grande razão para linguagens persistirem é que elas parecem seguras para construir. Não “seguras” no sentido de segurança, mas no sentido de negócio: equipes podem investir anos em software e esperar razoavelmente que ele continue funcionando, compilando e se comportando da mesma forma.

Entidades de padronização e especificações estáveis

Quando uma linguagem tem uma especificação clara e estável — muitas vezes mantida por um órgão de padronização — ela fica menos dependente de um único fornecedor ou time de compilador. Padrões definem o que a linguagem significa: sintaxe, bibliotecas centrais e comportamento em casos de borda.

Essa estabilidade é importante porque grandes organizações não querem apostar suas operações no “quequer que a versão mais nova decidiu”. Uma especificação compartilhada também permite múltiplas implementações, o que reduz lock‑in e facilita manter sistemas antigos rodando enquanto se moderniza gradualmente.

Compatibilidade retroativa é um recurso empresarial

Compatibilidade retroativa significa que código antigo continua funcionando com compiladores, runtimes e bibliotecas mais novos (ou ao menos há caminhos de migração bem documentados). Empresas valorizam isso porque reduz o custo total de propriedade:

• Menos reescritas emergenciais quando plataformas atualizam
• Menos tempo gasto retestando funcionalidades inalteradas
• Menor esforço de treinamento para equipes que mantêm codebases de longa duração

Comportamento previsível é especialmente valioso em ambientes regulados. Se um sistema foi validado, organizações querem que atualizações sejam incrementais e auditáveis — não uma requalificação total porque uma atualização da linguagem mudou semanticamente algo.

A alternativa: mudanças quebradoras que drenam confiança

Mudanças frequentes que quebram compatibilidade afastam pessoas por um motivo simples: transformam “atualizar” em “novo projeto”. Se cada versão nova exige tocar milhares de linhas, reconfigurar dependências e perseguir diferenças sutis de comportamento, equipes adiam upgrades — ou abandonam o ecossistema.

Linguagens que priorizam compatibilidade e padronização criam um tipo de confiança entediante. Esse “entediante” muitas vezes é o que as mantém em uso ativo muito depois que o hype acaba.

Interoperabilidade permite que linguagens se conectem a stacks novos

Uma linguagem não precisa “vencer” toda nova tendência para continuar útil. Frequentemente ela sobrevive conectando‑se ao que estiver em voga — serviços web, requisitos modernos de segurança, ciência de dados — por meio da interoperabilidade.

Bibliotecas e runtimes como adaptadores

Linguagens antigas podem acessar capacidades modernas quando existe um runtime mantido ou um conjunto de bibliotecas bem suportado. Isso pode significar:

• Chamar APIs web (REST/GraphQL) por bibliotecas HTTP
• Usar criptografia moderna via implementações validadas em vez de reinventar
• Delegar trabalho de machine learning para ferramentas externas mantendo a lógica de negócio existente

Por isso “antigo” não é automaticamente “isolado”. Se uma linguagem consegue falar com o mundo externo de forma confiável, ela pode continuar fazendo trabalho valioso dentro de sistemas que evoluem constantemente.

FFI, explicado sem jargão

FFI significa foreign function interface. Em termos simples: é uma ponte que permite que código escrito numa linguagem chame código escrito em outra.

Essa ponte é importante porque muitos blocos fundamentais e performance‑crítica estão escritos em C e C++, então conseguir chamar C/C++ é como ter acesso a um banco universal de componentes.

Padrões comuns de interoperabilidade

Um padrão é chamar bibliotecas C/C++ a partir de linguagens de mais alto nível. Python usa extensões C para desempenho; Ruby e PHP têm extensões nativas; muitas linguagens novas também oferecem compatibilidade com C‑ABI. Mesmo quando o código da aplicação muda, essas bibliotecas C frequentemente permanecem estáveis e amplamente suportadas.

Outro padrão é embutir interpretadores. Em vez de reescrever um grande sistema, equipes embutem uma linguagem de script (como Lua, Python ou motores JavaScript) dentro de uma aplicação existente para adicionar configurabilidade, sistema de plugins ou iteração rápida de recursos. Nessa configuração, a linguagem embutida é um componente — poderosa, mas não todo o produto.

A interoperabilidade redefine “sobrevivência”: uma linguagem pode seguir essencial como código de cola, camada de extensão ou núcleo estável que delega tarefas modernas a módulos especializados.

Indústrias e regulação criam nichos pegajosos

Algumas linguagens persistem porque indústrias específicas valorizam estabilidade mais do que novidade. Quando um sistema movimenta dinheiro, roteia chamadas de emergência ou monitora dispositivos médicos, “funcionar de forma previsível” é uma característica que você não troca levianamente.

Domínios de alto risco recompensam confiabilidade sem graça

Finanças é o exemplo clássico: core banking e processamento de pagamentos frequentemente rodam enormes codebases bem testadas onde downtime é caro e mudanças de comportamento são arriscadas. Linguagens associadas a software empresarial de longa duração — como COBOL em mainframes ou Java em grandes sistemas transacionais — permanecem ativas porque já demonstraram processar volumes massivos com resultados consistentes.

Telecom é similar: redes de operadoras dependem de operação contínua, ciclos longos de hardware e upgrades cuidadosamente gerenciados. Tecnologias que suportam comportamento determinístico e ferramentas operacionais maduras tendem a ficar.

Em aeroespacial e defesa, certificação atua como filtro de sobrevivência. Padrões como DO‑178C tornam mudanças custosas, então equipes preferem linguagens e toolchains com fortes propriedades de segurança, desempenho previsível e ecossistemas favoráveis à certificação. Por isso Ada e subconjuntos controlados de C/C++ ainda aparecem.

Saúde acrescenta outra camada: segurança do paciente e rastreabilidade. Para software médico e dispositivos (frequentemente alinhados com IEC 62304 ou expectativas da FDA), documentar requisitos, testes e histórico de mudanças importa tanto quanto a conveniência do desenvolvedor.

Regulação, auditorias e certificação desaceleram a troca

Regimes regulatórios e auditorias (pense SOX, PCI DSS, HIPAA ou equivalentes setoriais) empurram organizações para tecnologias bem entendidas, bem documentadas e mais fáceis de validar repetidamente. Mesmo que uma linguagem nova seja “melhor”, provar que é segura, compatível e operacionalmente controlável pode levar anos.

Ciclos de compras e contratos de suporte travam ecossistemas

Grandes empresas compram contratos de suporte de vários anos, treinam pessoal e padronizam stacks aprovados. Ciclos de compras podem sobreviver a tendências tecnológicas, e reguladores muitas vezes esperam continuidade. Quando uma linguagem tem um ecossistema maduro de fornecedores, suporte de longo prazo e pipeline de talento, ela mantém seu nicho.

O resultado: linguagens sobrevivem não só por nostalgia, mas porque suas forças — segurança, determinismo, desempenho e comportamento operacional comprovado — combinam com as restrições de indústrias reguladas e de alta consequência.

Educação e pesquisa mantêm ideias vivas

Uma linguagem não precisa dominar vagas de emprego para continuar viva. Universidades, livros didáticos e laboratórios de pesquisa mantêm muitas linguagens circulando por décadas — às vezes como material de ensino principal, às vezes como a “segunda linguagem” que os estudantes usam para aprender uma nova maneira de pensar.

Linguagens como ferramentas de ensino para paradigmas

Em sala de aula, linguagens frequentemente servem como exemplos claros de um paradigma em vez de rota direta para emprego:

• Cursos de programação funcional usam linguagens que tornam imutabilidade e funções de ordem superior naturais.
• Cursos de lógica e programação declarativa usam linguagens que forçam a expressão do o que se quer, não como computá‑lo.
• Cursos de sistemas usam linguagens que expõem memória, tipos e detalhes de compilação para que estudantes aprendam o que abstrações de alto nível escondem.

Esse papel de “ferramenta de ensino” não é prêmio de consolação. Ele cria um fluxo constante de desenvolvedores que entendem ideias da linguagem — e que podem depois trazer essas ideias para outras stacks.

Protótipos de pesquisa semeiam recursos mainstream

Academia e grupos de pesquisa industrial frequentemente constroem novos recursos de linguagem primeiro em protótipos de pesquisa: sistemas de tipos, pattern matching, técnicas de garbage collection, sistemas de módulos, modelos de concorrência e abordagens de verificação formal. Esses protótipos podem viver em linguagens de pesquisa por anos, mas os conceitos posteriormente influenciam linguagens mainstream via artigos, conferências e implementações open source.

Essa influência é uma razão pela qual linguagens antigas raramente desaparecem por completo: mesmo quando a sintaxe não é copiada, as idéias persistem e reaparecem em novas formas.

Uso educacional tem impacto no mundo real

A adoção educacional também cria efeitos práticos fora da sala de aula. Formandos levam bibliotecas, interpretadores, compiladores e ferramentas para o mundo; escrevem blogs, constroem comunidades open source nichadas e às vezes implantam o que aprenderam em domínios especializados.

Portanto, quando uma linguagem permanece comum em cursos e pesquisas, ela não está “morta” — está moldando como software é projetado.

Algumas linguagens ficam porque ainda são a melhor ferramenta

Nem toda linguagem sobrevive por nostalgia ou código legado. Algumas permanecem porque, para certos trabalhos, ainda fazem a tarefa melhor — ou com menos surpresas desagradáveis — do que alternativas mais novas.

Desempenho e previsibilidade vencem novidade

Quando você está no limite do hardware ou executando a mesma computação milhões de vezes, pequenas sobrecargas viram tempo e dinheiro reais. Linguagens que oferecem desempenho previsível, modelos de execução simples e controle fino de memória tendem a continuar relevantes.

Isso explica por que “proximidade com hardware” aparece repetidamente como razão de longevidade. Se você precisa saber exatamente o que a máquina fará (e quando), uma linguagem que mapeia limpidamente para o sistema subjacente é difícil de substituir.

Exemplos onde o “antigo” ainda é o melhor na categoria

Fortran para computação numérica é um exemplo clássico. Em cargas científicas e de engenharia — grandes simulações, álgebra linear, computação de alto desempenho — compiladores e bibliotecas Fortran foram otimizados por décadas. Equipes muitas vezes se importam menos com sintaxe e mais com resultados estáveis e rápidos que batem com pesquisas validadas.

C para sistemas embarcados persiste por razões semelhantes: é perto do metal, amplamente suportado em microcontroladores e previsível no uso de recursos. Quando há memória limitada, restrições de tempo real ou hardware customizado, esse controle direto importa mais do que conveniências de desenvolvedor.

SQL para consulta de dados perdura porque casa com o problema: descrever quais dados você quer, não como buscá‑los passo a passo. Mesmo com novas plataformas de dados, muitas mantêm interfaces SQL porque é uma linguagem compartilhada entre ferramentas, equipes e décadas de conhecimento.

Mentalidade do “ferramenta-certa-para-o-trabalho"

Uma cultura de engenharia saudável não força uma linguagem a fazer tudo. Ela escolhe linguagens como escolheria ferramentas: com base em restrições, modos de falha e manutenção a longo prazo. É assim que linguagens “antigas” continuam práticas — porque ainda são a opção mais confiável em seus nichos.

Como linguagens ganham revivals e novos nichos

Uma linguagem não precisa “ganhar” as paradas de popularidade para ter uma segunda vida. Revivals geralmente acontecem quando algo ao redor da linguagem muda — como ela roda, como é empacotada ou onde ela se encaixa em fluxos de trabalho modernos.

Gatilhos comuns para um revival

A maior parte dos retornos segue alguns padrões repetíveis:

• Um novo runtime ou alvo de compilação que torna a linguagem mais rápida, mais segura ou mais fácil de implantar (por exemplo, melhores JITs, opções de native‑image ou targets WebAssembly)
• Um ecossistema de pacotes mais forte: gerenciador de dependências moderno, documentação melhor e bibliotecas curadas que removem atritos do dia a dia
• Governança clara: roadmap estável, releases previsíveis e uma fundação confiável que reduz o risco para equipes
• Adoção corporativa (ou patrocínio) que financia trabalho em tempo integral em tooling, performance e suporte de longo prazo

Como um “novo nicho” se forma

Novos nichos surgem quando uma linguagem se torna o melhor ajuste para uma determinada superfície, mesmo que não seja a linguagem principal da aplicação.

Alguns caminhos comuns:

• Scripting dentro de apps: embutir uma linguagem para plugins, personalização, mods de jogo ou automações
• Ferramentas de infraestrutura: CLIs, sistemas de build, configuração, policy‑as‑code e helpers de deploy
• Código de cola para stacks novos: uma linguagem vira ponte conveniente entre sistemas, APIs e serviços

Quando um nicho se estabelece, ele pode se autoalimentar: tutoriais, bibliotecas e pipelines de contratação começam a se alinhar com esse caso de uso.

Catalisadores comunitários (e por que hype não basta)

Mantenedores open source e eventos comunitários importam mais do que recebem crédito. Alguns mantenedores dedicados podem modernizar tooling, manter releases em dia e responder a problemas de segurança. Conferências, meetups e “hack weeks” criam momentum compartilhado — novos contribuidores aparecem, boas práticas se espalham e casos de sucesso são documentados.

O que não cria longevidade por si só: hype. Uma onda de atenção sem tooling confiável, governança e vitórias em produção geralmente esfria rápido. Um revival pega quando resolve um problema recorrente melhor que as alternativas — e continua fazendo isso ano após ano.

Orientação prática: escolher linguagens para trabalho de longo prazo

Escolher uma linguagem para trabalho de longo prazo não é prever qual ficará na moda. É escolher uma ferramenta que continue operável, mantenível e contratável conforme seu produto e organização mudam.

Critérios que envelhecem bem

Comece por restrições que você pode verificar em vez de opiniões:

• Mercado de contratação: quão fácil é achar desenvolvedores experientes localmente ou remotamente? Verifique também se juniores estão aprendendo — um pipeline de entrada contínuo importa.
• Maturidade de bibliotecas: bibliotecas centrais são estáveis e bem documentadas? Dependências críticas têm mantenedores ativos e práticas de release claras?
• Alvos de deploy: onde isso precisa rodar — navegadores, mobile, embarcado, serverless, mainframes, ambientes air‑gapped? Algumas linguagens brilham só em certos alvos.
• Necessidades de integração: ela fala com os sistemas que você já tem (bancos, filas, provedores de identidade)? Interop e bindings podem importar mais que elegância.

Meça custo total, não só preferência do desenvolvedor

A escolha de linguagem afeta custos que não aparecem num demo hello‑world:

• Tempo de treinamento: rampa para novos contratados e times cross‑funcionais
• Carga de manutenção: debugging, upgrades, gestão de dependências, fricção de tooling
• Suporte a longo prazo: disponibilidade de releases LTS, patch de segurança, opções de suporte (vendor/comunidade)

Uma linguagem “mais barata” pode ficar cara se exigir especialistas nichados ou reescritas frequentes.

Táticas para reduzir risco antes do compromisso

Reduza incerteza com passos pequenos e deliberados:

• Construa um protótipo focado no requisito mais difícil (performance, compliance ou integração).
• Prefira migração gradual em vez de reescrita big‑bang.
• Use pontes de interoperabilidade (FFI, APIs estáveis, protocolos compartilhados) para poder trocar componentes sem substituir tudo.

Se seu maior risco é “com que rapidez validamos essa abordagem?”, ferramentas que aceleram protótipos podem ajudar — especialmente quando você quer algo que depois seja mantível como um codebase normal. Por exemplo, Koder.ai é uma plataforma de vibe‑coding que permite equipes construir protótipos web, backend e mobile via chat e então exportar o código‑fonte (React no front, Go + PostgreSQL no backend, Flutter para mobile). Usada com cuidado, isso pode reduzir o tempo entre ideia e prova de conceito, mantendo um caminho de saída via código exportado e refatoração incremental.

Checklist reutilizável

Antes de consolidar uma stack, confirme:

• Conseguimos contratar para ela dentro do nosso prazo e orçamento
• Bibliotecas críticas são maduras e mantidas ativamente
• Ela suporta nossos alvos de deploy hoje e provavelmente no próximo ano
• Integra bem com nossos sistemas existentes
• Existe uma história de LTS/suporte (comunidade ou vendor)
• Provamos a parte de maior risco com um protótipo
• Temos um plano de saída (interop, limites modulares, caminho de migração)