Executando verificação de segurança...
-4

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?

Carregando publicação patrocinada...