Acho que é extremamente inútil comparar as linguagens deste artigo, muito embora eu tenha deixado bem claro em uma provocação no título ser este o objetivo. Mas não é o objetivo. Não tem como comparar C++ com Rust. Simplesmente porque um deles é uma sombra do cópia e cola do C. Sei disso muito bem, parece birra de criança. Mas vamos para o aspecto técnico. E não para o bate boca de um desenvolvedor com longa estrada em C e C++ que quer descontar a má sorte sobre Rust. Vamos lá.

Dias desses estava acompanhado o quanto as linguagens estão se assemelhando com as linguagens que sempre existiram antes delas. E como essa volta ao modo que sempre deu certo parecer ser um ciclo familiar. Em 1972, C ganhou vida para ser uma versão ‘menos’ Assembly do Assembly. É uma linguagem considerada complicada por quem é graduado e um monstro por quem não é. Dá para entender. Ela exige conhecimento de computador e matemática, afugentando a maioria dos devs que são em sua maioria, não se sinta ofendido(a), entusiasta da área de tecnologia.

A área de tecnologia é vista como muitos como uma extensão do picadeiro Geek. É Vibe ser TI. Não me entendam novamente a mal. É legal parece ser um desenvolvedor descolado. Sim, por quê não? Mas ser um dev em JS não é ser um Dev. Sei, não me xinguem. Você continua sendo um solucionador de problemas. Mas não está manipulando as coisas pela engenharia dela, e sim pela superfice. Você não tem controle do que a linguagem faz e não pode mudar isso. Precisa esperar que alguém lance uma lib para melhora sua vida. Você concorda comigo? Você concorda comigo.

Python é uma linguagem de prototipação, mas acho que ninguém parece entender o que é isso de fato. Muitos investiram seu tempo e dinheiro para aprender Python. Eu lembro quando estava na faculdade em 2008, e um evento na Semana de Ciência e Tecnologia trouxe um quadro chamado Pycon. Não me lembro da edição. Mas parecia ser uma revolução. Meus professores mais antiquados fecharam a cara para essa novidade. Mas apesar disso, não concordo 100% em olhar para tecnologia. Mas olhar com a visão técnica e não pela vibe. O segundo é perigoso.

Python não é uma linguagem de programação de construção, para a gente traduzir diretamente da palavra inglesa BUILD. Você não tem um .exe nativo. Tem uma coisa chamada Pyinstaller que é um falso positivo de .exe. Ele não gera um executável. Como o Java não gera executável. Cria uma coisa chamada .JAR. Mas ele precisa de um instalador criado normalmente em C ou C++ para gerar o binário. E .dlls necessárias. Sem isso, Python não existe como executável. Mas naturalmente você deve entender que não existe muitos programas em Python .exe. O que existe são software prototipados em Python e depois passados a limpo em outra linguagem e nela finalizado.

Eu não sou contra tecnologia. Mas contra a miopia de que muitas pessoas podem desenvolver ao adotá-las. Eu posso estar sendo míope ao adotar por tanto tempo C\C++? Talvez. Mas tudo que perdura por muito tempo, parece funcionar. E C foi criado há 50 anos, Assembly foi criado em 1940. E C++ nos anos 80. Eles estão mais tempo de vida do que a maioria dos devs tem de idade. E são os verdadeiros engenheiros de quase toda tecnologia que usamos hoje em dia. Então se está funcionando, por que mudar?

Então eu comecei a garimpar uma tecnologia que o autoset do Javascript, o tal do Typescript que compartilha algumas similaridades com a sitnaxe do Rust. E adivinham, eu experimentei e notei uma coisa estranha. Ambos batem numa tecla familiar. Typescript e praticamente JAVA. E RUST é praticamente C. Mas eu devo dizer algo, JAVA é mais completo que TYPESCRIPT e C é mais completo e legível que RUST. O comparativo alí no título não é do C e sim do C++. Mas o comparativo real é C vs RUST. Mas eu não dirai comparativo. Eu diria C = RUST. Você concorda?

RUST não é POO, assim como C não é POO. C possui STRUCT e sim você pode simular POO com ele. Não é como ter classes. E sim por um lado isso ajuda em muito. Mas C++ quando usa classes duplica o tamanho da memória. C por sua vez impede isso. As boas práticas em C permite ter os resultados do RUST. A diferença em minha opinião é que RUST parece complicar isso sem necessidade. Vou dar alguns exemplos de sintaxe:

Em RUST você não precisa fazer chamadas de libs como em JS. Eu acho isso nada legível e pode parecer, mas na hora de fazer manutenção o bicho costuma pegar porque você não sabe quais dependências estão em jogo ali. Mas em C e C++ você faz o #include e sabe o que está acontecendo no código. Em C++ você pode até em alguns casos dispensar, pois a linguagem faz isso por você. Mas C não tem desculpa, senão fizer declaração, simplesmente ele não roda o código. E isso nos permite uma sensação de ‘entendimento’ de mecanismo.

Em RUST você não precisa definir o tipo básico das variáveis, mas isso muda quando se trata de parâmetro de função e 8uando você precisa definir constantes. Para mim isso se torna um pouco confuso. Pois você tem regras que não parecem seguir uma lógica. Por que você precisa definir o tipo de dado aqui, mas ali não precisa? Em C\C++ você DEVE definir. Então você tem essas sintaxes.

RUST:

let nome = “Mundo Pauta” ou let nome : String \ nome : &str (o primeiro caso permite alteração do valor e o segundo caso é mutável. No entanto o let mut nome já muda isso. Já const nome não permite a devida mudança. Não sei se vocês compreendem o que isso de fato ajuda em gerenciar memória. Mas são regras para impedir ‘alocação indevida’. Os chamados valores vazios. Pois bem. Em C você tem um tipo de STRING que é definido como const char, normalmente declarado como um ponteiro e referenciado com a variável precedida de &. Até aqui você pode entender o seguinte, este const char permite alteração de variável sem precisar definir que ela é uma variável.

A pergunta fica, porque let é na prática constante, let mut é a variável e o const é uma constante? Em RUST isso existe para garantir que você só mude um valor mediante uma regra de liberação de memória. O problema é que você precisa entender cada mecanismo para não errar. E o debug dificilmente te impede de errar. Pois ela impede de compilar se estiver errado. Em C se estiver errado, ele vai compilar assim mesmo. E se você não tiver um IDE, ele vai executar assim mesmo com o erro. Porque depende de você entender isso por consciência.

C:

const* char nome = “Mundo Pauta”;

C++:

std::String nome = “Mundo Pauta”;

Em RUST a mudança de valor de String segue uma regra um pouco complexa. Ela precisa referenciar o valor da seguinte forma String::from(“value”); para um tipo de let mut nome : String. Perceberam o quanto isso é ilegível? O que está acontecendo ali? Bem, em C você pode ter estouro de pilha se você fizer um char ler uma string. Por isso uma const char permite um char se tornar um vetor. Em Rust você não tem contato com essa informação. Ele está mais para um ‘protetor’ dos problemas de memória. E para isso faz um caos na sintaxe.

Eu estudei RUST e pensei que ele fosse uma GRANDE REVOLUÇÃO. Fora ele ser uma combinação sintática de PYTHON, JAVA, JAVASCRIPT E C e funcionar como se fosse uma JVM do JAVA e que não gera um .exe. Me faz pensar que talvez as pessoas estejam aplaudindo uma tecnologia que é um JAVA ++? Seria uma evolução da tecnologia da Sun? O Cargo é uma espécie de gerenciador de pacotes + compilador. Ele funciona como o vcpkg do C, pip do python e o npm do Javascript. A diferença é que o compilador dele em console fora do IDE é bem completo. Seria o meu único elogio. Ele dispensa o uso do IDE. É o depurador mais completo que eu já vi usando instaladores simples.

Depois de um tempo você mesmo consegue depurar códigos de C\C++ sem muitas dicas. Mesmo eu já fiz códigos em notepad em C executei ele usando o gcc++ 8ue é um comando de build e run do compilador do C\C++. E já corrigir problemas sem precisar de um depurador. Mas o RUST atende a regra de controle para garantir memória e não vazamento, por uma única razão e não é inédita. Ela faz igual ao C#. Ela impede a execução se alguma regra estiver fora do escopo. Por exemplo, se você escrever nomeCompleto como variável, ele acusa erro. Fala de algo chamado snake. Em C, C++ isso não existe. Ele obriga você a escrever em caixa baixa nomes de variáveis variáveis e em caixa alta nome de constantes, o padrão do C.

C:

#define PI 3.14156

Mas tem uma diferença. Em Rust definir uma constante é alocar memória em uma variável. Em C você definia a constante em um comando para o processador. Ele não usava um espaço de memória. E isso poupava o uso dela. Em C++ isso também não existe e funciona igual ao RUST. Usando inclusive o const na frente.

Já li que muitos dizem que RUST tem problema de memória. Na realidade eu preciso discordar de uma coisa. Ele tem controle máximo de memória. Para isso ele criou regras rigidas de como um código precisa ser escrito. Lá você cria um src com o comando de cargo new <nomedoprojeto> e então vai criar um main.js e em cargo.toml ele vai criar o nome do pacote. E reconhecer que o main.rs é o comando de programa principal. Igual tem no C. O int main(). Mas tem uma diferença. Você não pode criar o seu int main, você tem que criar funções (fn) e elas erem chamadas no int main. Em C, você pode criar libs com int main própriop. E isso ser executado como um CORE (núcleo próprio) de libs.

Neste caso, RUST é seguro porque ele LIMITA os seus passos. E não porque ele é SUPER SEGURO. C já tem como assegurar. MALLOC. A maioria tem problemas porque desconhece totalmente como um computador funciona. Ao meu ver, RUST parece aquele carinha seguro, gente boa. Mas o problema dele é justamente outro. Ele é o cara comportado, com sapatos lustrados. Mas se sair a exceção, ele cai por terra. Esse tipo de código é engessado e como não sabemos que includes estão envolvidos, precisando ir no toml para ver, isso torna o código com dificuldade de manutenção e ESCALABILIDADE. Não se enganem não estou falando que não é, mas que será complicado atualizar esses códigos no futuro.

E POR FIM, se C tem problemas. Por quê RUST foi escrito em C?