Absolutamente nada dura para sempre, a história tá aí para provar. Então sim, um dia essas linguagens vão morrer. Quando ninguém sabe, mas é óbvio que vai acontecer.
Dito isso: por mais que 99% das pessoas vão negar (com o coração, sem argumento técnico e sem pensar racionalmente. Só porque é apaixonado pela linguagem e se ver na obrigação de "defendê-la"), o fato é que a linguagem C tem vários problemas de segurança que nunca serão corrigidos porque o próprio comitê que mantém o ISO/IEC 9899 não quer fazer isso. E quem programa na linguagem não quer que isso seja feito também.
E estamos em 2023, segurança já é o fator mais importante e a tendência é das pessoas continuarem dando cada vez mais importância à isso.
O argumento de que "C é rápido" já caiu por terra uma vez que multicore já é o padrão, até nos computadores domésticos é comum ter processadores quadcore ou até octacore. E a linguagem C se aproveita muito mal de múltiplos cores, permitindo que linguagens que sejam boas em paralelismo consigam performar muito melhor do que C (por isso o backend do WhatsApp é escrito em Erlang e não em C). E por isso Go fez tanto sucesso no desenvolvimento backend em sistemas que exijam alta performance.
Então "C é rápido" era uma verdade nos anos 90 e até mesmo no começo do século 21. Mas o pessoal não tá se atualizando, não sabem que a mudança já começou há pelo menos uma década.
Existem outros argumentos previsíveis que eu sei que o pessoal vai usar, então já vou responder eles aqui:
"É só uma modinha"
Linguagens com memory safety já existiam antes da linguagem C. Isso que, na sua cabeça, é algo "novo" e "modismo" é mais velho do que a linguagem C.
Veja Lisp por exemplo, uma linguagem memory safe que existe desde 1960. Ela é 12 anos mais velha do que C.
Então não, não é "modinha". Só porque você ouviu falar do assunto ontem não quer dizer que ele tenha começado ontem. É só você que está atrasado mesmo, pegou o bonde andando.
"Ah, mas C gera código ASM enxuto. Compare o código ASM de C com o de Rust"
Eu já fiz isso. E isso era uma vantagem imensa nos anos 90. Mas como estamos em 2023, uma rotina que gasta 15 ciclos de clock a menos é desprezível quando o programa consegue performar melhor em múltiplos cores. Ao invés de ser "mais lento", ele é mais rápido. Por mais contraditório que seja, gasta mais ciclos de clock em uma rotina ou outra torna o programa mais rápido se, no geral, ele performa melhor em múltiplos cores.
Esse argumento se dá por um efeito de visão de túnel. A pessoa fica focada demais em 20 instruções Assembly e como elas estão alinhadas no início da linha de cache, e se esquece de avaliar a performance do programa como um todo.
E lembrando que não é mais verdade que C tem "o melhor" compilador. Pois o GCC pode (e vai) suportar compilar Rust também.
"C não tem falhas de segurança, a culpa é do programador"
Na imaginação das pessoas é assim que funciona, mas na vida real não. Veja este post da Google:
Como indica no post, conforme é diminuído o uso da linguagem C no Android as falhas de segurança encontradas no código também diminuem. Não dá para afirmar que é "coincidência", seria um argumento muito desesperado.
E se quer mais evidências consulte a página do CVE de projetos famosos escritos em C. Veja por exemplo do Linux: https://www.cvedetails.com/vulnerability-list/vendor_id-33/Linux-Linux-Kernel.html
Você verá que todo ano são encontradas vulnerabilidades do mesmo tipo. Você vai ver com frequência use-after-free, buffer overflow, integer overflow, buffer over-read (ou out-of-bounds read) etc.
Várias vulnerabilidades relacionadas à memory safety, todo ano.
Aí fica a questão para quem acredita ser o único programador no planeta que dá conta de escrever código C sem falhas de segurança: será que os programadores da Google e do kernel Linux são ruins, por isso eles cometem esses erros? Ou será que o fator comum, a linguagem, tem a ver com isso?
Porque as pessoas acham que é "culpa do programador"
Eu também pensava assim há uns 4 anos atrás. Mas eu fiz uma coisa impensável: eu estudei sobre o assunto. Eu estudei sobre Programming Language Theory e estudei sobre exploração de binários. E munido de conhecimento eu fui capaz de perceber que sim, a linguagem C tem muitos problemas de segurança.
Quem não consegue perceber isso é quem é como eu era há 4 anos atrás: ignorante no assunto.
Acontece que você precisa de conhecimento para ser capaz de ver as falhas de segurança. Sem o conhecimento adequado você não vai vê-las. E como dizem: "o que os olhos não veem o coração não sente".
O problema: encontrar/explorar vulnerabilidades em binários é difícil
Por isso todo mundo (sem exceção) que programa em C cai na ilusão de que é o único programador no planeta que dá conta de escrever código em C sem falhas de segurança, e que todos os outros são "burros" e "incompetentes", e dizem: "a culpa é deles, não da linguagem."
Porque é difícil encontrar vulnerabilidades em binários, muito mais difícil do que encontrar em sistemas WEB por exemplo. Então a pessoa tem que realmente se dedicar à estudar exploração de binários por uns bons anos para conseguir fazer isso.
Daí como o coleguinha não consegue (por falta de conhecimento e competência) encontrar vulnerabilidades no código C dele, ele simplesmente assume que se não consegue é porque não existem.
É como uma pessoa tentando procurar bactérias à olho nu nas mãos dela. Se não tá vendo é porque não existem, então para quê lavar as mãos antes de comer?