É improvável que qualquer linguagem substitua completamente o C. Nem mesmo o todo podereso C++ foi capaz desta façanha. O C, em particular, é o "assembly portável" padrão da computação.

Ele é suportado por uma variedade de compiladores fornecidos por diferentes fabricantes, como o compilador Intel C, compilador ARM C e IBM XLC. A presença de um compilador C é quase uma necessidade imperativa para vender um processador.

Além disso, sistemas baseados em Unix e POSIX (da qual o Linux é apenas a ponta do iceberg), fornecem uma API em C para interagir com o hardware. Portanto, enquanto esses sistemas estiverem em uso, o C continuará sendo insubstituível.

Ninguém vai mais vai entrar nesta briga porque ela já acabou. O C ganhou essa batalha entre 1980/90.

Enquanto não houver uma disrupção em nossos processadores e linguagens de máquina nenhuma outra linguagem ira tornar o C irrelevante.

Já tem boas respostas aí, mas vou dar meus 2 centavos de €. Até porque não deram muitas novas sugestões.

Concordo especialmente com o clacerda e kht.

Muitos projetos que precisam um pouco mais de baixo nível (controle sobre os recursos) usarão outras linguagens. Rust saiu na frente, outras tentaram e fracassaram em diversos graus, e tem novos competidores que vão abocanhar uma parte deste mercado.

Sempre foi assim, tecnologias são falhas, não podem ser melhoradas como um todo sem quebrar compatibilidade, e isso é um enorme problema, e surgem novos produtos para concorrer com sua atenção e ter seus espaço, em detrimento do que já existe com falhas. Se conseguir alcançar corações e mentes das pessoas terá algum nível de sucesso. Não existe uma tecnologia deste tipo que não será desafiada e perderá algum espaço ao longo do tempo.

Ao mesmo tempo, é extremamente difícil que uma tecnologia minimamente consolidada perca terreno tão grande assim. E não estou falando só do legado, que já bem dito por outros, não vai sumir. Estou falando de novos projetos, porque ainda faz sentido usar certas tecnologias existentes porque as novas não conseguem entregar 100% das características do que já existe entrega.

Nem vou falar do gosto e experiência, que contam também, afinal somos humanos e não robôs. Fazer o que não gosta ou o que não conhece bem dará resultado pior.

E leia o comentário sobre estradas para entender outro ponto importante (sim, você vai ter que ler tudo para achar).

Dito tudo isso...

Se a linguagem tem GC (tracing mesmo, nem falo de outros tipos determinísticos) ela não pode estar na mesma categoria de C ou C++. Mesmo opcional.

Pelo pouco que conheço de Crystal, não acho que ela compita tão diretamente com C. Muito menos com C++. É uma linguagem interessante, mas não é possível entregar tudo o que promete, e por isso, entre outras coisas, tem pouco sucesso. Entrega uma parte, mas acaba virando algo esquisito. Tem mercado para isso, e eu acho que compete mais com Go, até por ter GC.

Zig realmente compete com C, não com C++. Algumas pessoas apostam como melhor alternativa para C.

V é um experimento e algo que não deve ser levado a sério por enquanto. Duvido que será usada além de um grupo muito pequeno, não deve ser diferente de D. Escrevi sobre. Além disso ela tem GC, mesmo que digam que não tem (certos tipos de aplicação só funcionarão com GC).

D falhou por ter optado por um garbage collector. Também teve outros problemas na linguagem. Tentaram arrumar, mas era tarde demais.

Por isso, Go não é competidor direto de C. E também pelos motivos de Rust abaixo.

Rust falha porque não é tão eficiente em vários cenários. E por eficiência envolve várias coisas, por isso não falo em performance. Além disso, para certos projetos complexos ela não tem todo ferramental que C++ tem. Rust não é a panaceia que alguns acham que é, apesar de excelente linguagem. Aos poucos vão surgindo cada vez mais críticas sensatas, você troca de problema. E pode ser uma boa troca, mas não para tudo.

Carbon parece que será um bom competidor para C++, mas não para C. E eles escolheram não "consertar" alguns defeitos de C++, porque será? Esse pessoal da Google é tudo burro? Ou será que eles sabem que os competidores atuais falham por ter consertado defeitos demais e que isso torna essas linguagens "ideais" inadequadas para certos cenários?

Não se esqueça que Objective C tentou ser essa linguagem.

Dê uma olhada em Nim. Já dei mais uma pra briga, mas não vou falar de outras porque são bem pouco conhecidas ou fogem muito da categoria. Nim entra mais na categoria de Crystal, ou Go, não é tão competidora de C, só coloquei para não ter um exemplo.

Tá bom, vai um exemplo de desconhecida: Odin. Jai poderá ser outra se ver a luz do dia.

Eu tenho um projeto de linguagem (não implementada) que competiria em parte com C e C++, mas ela usa um modelo de memória que torna inviável certos tipos de aplicação que C ou C++ vão bem. Mas só C tem a feature de estabilidade, e isso não pode ser considerado algo pequeno.

Faz sentido para você?

Espero ter ajudado.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Talvez para aplicações novas, algumas dessas linguagens atraiam nichos específicos. Mas temos que lembrar que existe um enorme legado em C e C++, que não pode ser ignorado.

Por exemplo, C é usada atualmente para fazer programas extremamente complexos como o Kernel do Linux (e também do iOS, Android, OSX, Windows, etc), os interpretadores/compiladores de várias linguagens (por exemplo, PHP, Python, etc, e muitas outras tem partes em C ou C++), programas "famosos" como o Git, SQLite e outros bancos de dados (Oracle, MySQL, PostgreSQL, etc) e muito, muito mais.

É simplesmente inviável abandonar todo esse código legado e reescrever tudo em outra linguagem. Mesmo a reescrita parcial adicionaria uma complexidade que provavelmente não vale a pena.

Uma das vantagens do C (além de ser o assembly portável da computação, como já disseram), é ser estável e não cair em modinhas: é uma linguagem estabelecida o suficiente pra não precisar aderir a nenhum hype para se manter relevante (ao contrário das outras, que precisam justamente do hype pra chamar a atenção, e muitas vezes acabam adicionando coisas desnecessárias).

Devemos começar a nos perguntar sobre os porquês de acharmos que essas linguagens precisam deixar de serem relevantes.

Aplicações movidas a C e C++ estão ai rodando e nos servindo muito bem, obrigado. Assim como muitas aplicações em mainframe, que parecem que nunca serão substituidas. E deveriam?

Por que reinventar a roda? Só pra usar a linguagem da moda (que na maioria das vezes não oferece a mesma maturidade e segurança)?

Vivemos na era do hype. A cada cinco minutos, alguém grita "eureka" no github. E isso é bom. É assim que novas coisas surgem. Mas quem, de fato, rodam aplicações que custam dinheiro, há de pensar 200 vezes em fazer um movimento duvidoso.

No fim, a velha máxima da computação resiste firme aos bons tempos. Se está funcionando, não importa se está escrito em COBOL, C ou React: apenas não mexa.

Nosso mundo de TI é suscetível a hypes e estamos passando por mais um. Rust (ou outra linguagem) não irá substituir o C/C++.

Cada linguagem terá seu campo de atuação e seu sucesso e essa "guerra" não existe de fato.

Rust, apesar de suas qualidades e do hype não substituirá o C++.

Me lembro quando o Delphi fazia sucesso, o Object Pascal era "o substituto do C++".

É importante levar em conta que linguagems são ferramentas, use a certa para o trabalho certo.

Eu mesmo enxergo o Golango muito mais produtivo e rápido pra desenvolvimento Web que o Rust.

Crystal e Zig eu não sei. Mas V irá gerar um equivalente em C que será compilado para gerar o executável. Se C deixasse de existir agora, nenhum progama em V poderia ser compilado. O Mesmo para Nim e outras linguagens.

Vale a pena ainda estudar para C ainda? Por que nem vaga mais de C eu vejo e na faculdade o pessoal ensina é Java

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:

• Memory Safe Languages in Android 13

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?