7 min de leitura ·

[DISCUSSÃO] O Rust realmente é ruim?

Esse post é, na verdade, uma resposta e também um complemento mais bem avaliado aos meus 2 posts que fiz há mais ou menos 1 ano aqui na plataforma. Também estou voltando a escrever aqui no TabNews depois de um tempão.

Os posts são, especificamente:

Contexto

Após ter lido os outros dois posts que este deve responder (se não leu, tudo bem. De qualquer forma explicarei aqui), você deve ter percebido o meu grande pé atrás com a linguagem de programação Rust (https://rust-lang.org) e como ela aplica a suposta "solução" para a programação de sistemas.

Os dois posts anteriores mencionam principalmente a questão da sintaxe e da forma que os lifetimes funcionam na linguagem e como deveriam ser melhorados. Eu ainda acredito que estas mudanças são necessárias. Mas aqui vou complementar com mais coisas sobre o design da linguagem em si e como sua filosofia não adequa exatamente ao perfil de uma linguagem realmente preparada para produção séria.

Parte 1: Uso indevido da linguagem

É visto que, nos ultimos tempos, a linguagem Rust sofreu uma grande explosão de popularidade em diversas áreas da programação, o que causou a nova comunidade expandida a se interar ainda mais à linguagem.

A primeira coisa que começou a aparecer são os frameworks Web. Que, ainda que não sejam completamente inúteis, são utilizados em uma linguagem quase que completamente fora do escopo Web e que não comporta o perfil de programador web de nenhuma forma.

Um exemplo muito interessante é o framework Loco. Ele foi feito com a intenção de se parecer ao máximo com o framework Rails (para Ruby). O que claramente não se adequa a uma linguagem de sistemas, que é o Rust.

O uso indevido da linguagem Rust gera uma pressão para os desenvolvedores da linguagem a "generalizar" a linguagem e lentamente deixar de apontar para a direção inicial do design da mesma. O que com certeza causa um overhead absurdo.

Outros exemplos de usos "indevidos" ou anti-naturais do Rust que causam overhead na linguagem:

Ferramentas de linha de comando “de escritório”
Muitos CLIs modernos são escritos em Rust apenas pela promessa de segurança e velocidade, mas o tipo de tarefa é semelhante ao que um Java, Go ou mesmo Python fariam sem perda significativa.
Processamento de dados e pipelines
Rust aparece em projetos de ETL, parsing de arquivos ou servidores de fila. É um ambiente controlado, sem exigência de acesso direto ao sistema. A linguagem funciona, mas não é exatamente seu território natural.

Parte 2: Segurança em troca da sanidade do programador

Rust embarca com seu compilador um sistema denominado "Borrow Checker", que trabalha em conjunto com o Type Checker para garantir a segurança da memória dinâmica alocada durante a execução do programa, com o objetivo de evitar vazamentos de memória (Memory Leak) e outros problemas comuns ao utilizar memória dinâmica.

O borrow checker possui outras funções mas que não contruibuem exatamente para o tema abordado aqui neste post. Caso esteja interessado em saber como o borrow checker funciona, leia o artigo oficial.

Ownership não funciona

O ownership e o borrow checker do Rust estabelecem regras rígidas para evitar erros, mas também cria dependência de um modelo que nem sempre se encaixa em estruturas de dados complexas ou em sistemas que exigem decisões finas sobre desempenho e tempo de vida. O controle manual, apesar de exigir responsabilidade, continua oferecendo uma liberdade que muitas aplicações demandam.

Controle direto de desempenho
A alocação e liberação podem ocorrer exatamente quando necessário, sem depender de políticas da linguagem ou da interferência de análises do compilador. Isso evita realocações inesperadas, cópias adicionais ou barreiras de sincronização artificiais.

Quantas vezes você já não se deparou tendo que dar .clone() em tudo para evitar reescrever todo o design do seu programa?

Responsabilidade explícita
A memória é um recurso físico. Tê-la sob gestão direta mantém as decisões estruturais nas mãos de quem conhece o comportamento do sistema, em vez de depender de restrições de linguagem que funcionam bem apenas em certos estilos de código.

O controle do tempo de vida de memória dinâmica sem depender de designs específico de software é essencial para manter a sanidade de quem desenvolve o software.

Quem já utilizou Rust já passou raiva tendo que escrever e reescrever tantas coisas sem realmente trabalhar na ferramenta que está a desenvolver realmente. Mas só para que o programa em si consiga compilar.

Além de tirar a sua atenção no que você realmente precisa fazer. Ele ainda te força regras estritas sobre como você deve escrever seu código em nome da "segurança".

Parte 3: Javascriptização do Rust

A ideia de que Rust está se “javascriptizando” expressa um incômodo legítimo: a linguagem nasceu com vocação de sistemas, mas seu ecossistema começa a acumular sinais de dispersão. O ponto central não é que Rust esteja virando JavaScript no sentido literal, e sim que o ambiente ao redor da linguagem tende a adotar hábitos que reduzem sua sobriedade técnica. Esse movimento merece crítica justamente porque contrasta com a proposta inicial de Rust: oferecer controle, precisão e parcimônia.

A partir daí, o problema vira excesso de dependências pequenas, gerando cadeias desnecessárias e diluição do propósito técnico. A tendência de encapsular demais também afasta o programador dos custos reais de memória e concorrência, criando um estilo que pouco lembra o trabalho de sistemas. E o uso crescente de Rust em áreas de alto nível reforça esse desvio, espalhando práticas que priorizam conveniência em vez de rigor.

A crítica desta parte do post está mais voltada ao crates.io do que a linguagem em si. Lá a gente encontra muitas bibliotecas extremamente pacatas -- extremamente similar ao que o npm e outros gerenciadores de pacote do JavaScript passam nos ultimos anos (claro que não da forma tão aguda, mas que com certeza não é ideal):

num_cpus: Retorna o número de CPUs da máquina
url: Utilitário para parsear URLs
textwrap: Funções simples para quebrar/formatar texto.
postfix_assert: Adiciona métodos de assertividade “inline” (ex: x.assert_some() ao invés de assert!(...)) — basicamente syntax sugar para o assert!.
Entre outros...

Além disso, há críticas recorrentes da comunidade — por exemplo, no fórum da linguagem — quanto à facilidade de adicionar dependências. Um comentário resume bem o problema:

“Whenever I look at a crate on crates.io, I notice that even some very simple crates will have a large amount of dependencies.” (Fonte)

Tradução: "Sempre que analiso um crate no crates.io, percebo que até mesmo alguns crates muito simples possuem uma grande quantidade de dependências."

Parte 4: Coisas boas do Rust

Depois de fazer tantas críticas negativas ao Rust, é bom mencionar as diversas coisas que são definitivamente louváveis na linguagem.

Sistema de Edições

Ao invés de considerar a evolução linguagem em versões (como 1.31.0, 1.56.0, 1.85.0), o Rust classifica em Edições baseadas no ano de lançamento das mesmas (Edição 2018, Edição 2021, Edição 2024), que consideram somente features e mudanças na linguagem ao invés de correções de bugs e mudanças na codebase.

Você pode também utilizar edições iguais para compiladores de diferentes versões e também edições diferentes no mesmo compilador. O que facilita a sua instalação do compilador na sua máquina.

Por exemplo, a versão do compilador X pode conter um bug. Depois de corrigido, a versão do compilador muda para Y mas a edição (a padronização) da linguagem continua igual.

É algo que os compiladores de C e C++ também fazem e chamam de standards (como C99 ou C++23) mas não de forma tão compreensível e organizada como o Rust.

Biblioteca padrão organizada e rica

Diversas tarefas em Rust são muito acomodadas na biblioteca padrão do Rust
de forma compreensível e muito bem documentada, como a forma de Ler arquivos ou de trabalhar com multiplos processos. Além dos recursos de tipagem com os Sum Types que são extremamente úteis (como o Result<T, E> e o Option<T>)

Todas estas características da biblioteca padrão são bastante coerentes para uma linguagem de sistema e providenciam certa comodidade ao utilizar estas ferramentas.

Ferramentas integradas de qualidade

Junto com o compilador. o Rust traz duas ferramentas muito úteis:

Rustup: Ferramenta de gerenciamento de instalações do Rust e também de geração de documentação local, que ajuda demais no desenvolvimento de ferramentas que não são tão bem documentadas.
Cargo: Gerenciador de projetos e de pacote muito bem arquitetado e mantido. Com funções de teste unitário e até formatação / correção de código

Conclusão

Fiz esse post para causar mesmo (rsrsrs). Aqui é para ter discussão (obviamente que civilizada) sobre o que cada um acha da linguagem.

Como o criador do C++, Bjarne Stroustrup já dizia:

"There are only two kinds of languages: the ones people complain about and the ones nobody uses."

Então significa que o Rust tá bem!

Obrigado por ler e se sintam livres em comentar por aqui. Obrigado.

maniero

2 dias atrás

Parabéns pela excelente análise.

Rust é ótima... para algumas tarefas, em geral quando normalmente seria usado C ou C++. Toda tentativa de usar Rust no lugar de outras linguagens, é quase certo que será um uso indevido, apesar de funcionar.

De fato, não deveria ser usado para web no lugar não só de JS, como de outras linguagens que compilam para WASM. Não estou dizendo que nunca deva fazer algo cliente web, mas em geral é a ferramenta errada.

É claro que fazer um renderizador para web ou um servidor HTTP, Rust se encaixa bem. Mas não é disso que estava sendo falando.

O uso inadequado de uma linguagem porque é o que a pessoa conhece é um dos erros mais frequentes. Embora algumas vezes esse erro não cause grandes problemas. não é algo pior em Rust do que outras, pelo menos não é fácil medir uma diferença.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

nfoj

3 dias atrás

Olá, achei o texto interessante, queria comentar o ponto da Javascriptizacão do Rust, acredito que isso é algo natural em muitas linguagens.
Essa e apenas minha percepção, mas ao longo dos anos muitas linguagens passaram a adotar mais e mais possibilidades para solucionar problemas diversos e muitos desenvolvedores passaram a usar qualquer linguagem para solucionar qualquer problema.
Digo isso pois ja vi desenvolvedor javascript usando a linguagem para desenvolver para desktop e defendendo a ideia como algo ótimo, mas sabendo que tem outras que fazem isso melhor.
O próprio python segue sendo usado em tudo que é canto, mesmo nao tendo um desempenho tão bom, o Qtile mesmo é um Tile window manager bem conhecido e que tem um desempenho inferior quando comparado a outros, mas segue sendo usado e crescendo.
Acredito que é algo natural, acabamos usando p conhecimento que temos para desenvolver soluções para diversas situações, mesmo não sendo o ideal, resolvemos o problema.
O rust eu vejo indo pelo mesmo caminho, acho a linguagem bem divertida de se estudar, ainda não tenho nenhum projeto em produção, mas tenho acompanhado o crescimento e tenho visto que ela segue crescendo de forma orgânica, mesmo sem mercado as pessoas estão estudando e criando novos projetos, mesmo a curva de aprendizado sendo ingrime as pessoas seguem estudando e usando.
Não sei, acho que como falei vejo que ela está seguindo um caminho natural que muitas outras ja seguiram, essa é minha percepção.
No final é apenas mais uma caixinha de ferramentas, basta apenas aprender a usar.

gilsonfabiano

2 dias atrás

Meus 3 cents.

Dificilmente eu respondo, mas o texto é muito bem escrito e a discussão é valida.
Porém o que muitos esquecem é a filosofia proposta pelos criadores que a linguagem segue para seu propósito.
Uma linguagem nasce para resolver um problema específico, com isso (na sua filosofia) nasce suas regras (algumas mutáveis e outras não). Hoje muitos desenvolvedores só seguem o hype e esquecem de ver o propósito da linguagem (se ela resolve o seu problema) e a usa em qualquer lugar para qualquer fim.

Como dizem por aí, um canhão também mata uma mosca, mas será que é a ferramenta correta?

O Rust é a bola da vez, vários desenvolvedores vindo de outros ecossistemas trazendo tudo de bom e ruim juntos.

Enfim, volto a dizer, pensem na filosofia e proposta da linguagem. Se os criadores querem que você use x, y, z. Vejam antes se aquilo faz sentido para a proposta e não para seu gosto pessoal.

abdielsouza

2 dias atrás

O Rust não é ruim, o fã clube que é kkkk

Programmer404

3 dias atrás

Eu passei o ano inteiro usando Rust. Eu vim do JavaScript (e já passei por diversas linguagens como Golang, Java e um pouquinho de C++ e C).

Eu discordo sobre a sua afirmação sobre Rust não ser adequado para Web... Um servido Web é literalmente o exercício final do Livro do Rust, reforçando a sua presença nesse ecossistema.

Sobre WEB

Claro que, não há muitos servidores web que precisam de Rust. A maioria dos casos um go já resolve. Um exemplo seria web server de redes sociais que requerem alta concorrência e performance. O ecossistema Rust entrega isso.

Sobre CLI

Sobre criar CLI, é, novamente recomendado no site oficial do Rust! E sim, Rust é muito bom nisso. Você pode fazer com JavaScritpt ou seja lá qual linguagem. Quando se utiliza Rust para CLI, não é para coisas simples. Infelizmente estão utilizando para coisas banais (o que não é pecado, mas o ganho em relação a outras linguagens é mínimo). Eu mesmo já criei alguns CLI para aprender a linguagem e uso pessoal.

Sobre as crates supostamente inúteis:

Bem, você não disse que são inúteis, mas como veio logo em seguida a um comentário sobre duplicação de crates, irei assumir que estava implícito.

textwrap formata texto de forma robusta, o que é essencial para formatação de logs, outputs em CLI, e coisas do tipo. Fazer isso manualmente é trabalhoso. Essa crate é uma mão na roda para quem realmente entende o seu proposito.

Trabalhar com Strings não é para amadores. Requer um trabalho cuidado para não ter bugs de lógica ou tornar a aplicação lenta por clone() em excesso(que não é necessário se você sabe o que tá fazendo ou se refinar bem a arquitetura da aplicação).

url manipulação de URL não é algo que possa ser feito de forma leviana e é necessário fazer de forma precisa. Isso incluí: formatar urls, obter segmentos da urls e coisas do tipo para processar corretamente. Fazer isso na mão pode (e com certeza vai em algum momento) criar um bug que pode lhe custar muito...

num_cpus essencial para quem usar Docker ou precisar fazer algum calculo matemático. Outro ponto é em tomada de decisões baseado no hardware da máquina. Portável para os sistemas operacionais mais populares (incluí outros ambientes como WASM).

postfix_assert útil se quiser um code style específico, mas nada grandioso.

É inevitável:

Até agora não encontrei nenhuma crate extremamente semelhante, mas isso é inevitável em QUALQUER ecossistema. Infelizmente sim, há crates inúteis, mas algumas realmente são simples, porém poderosas como o num_cpus.

Claro que não é perfeito:

Rust tem problemas sim, todo mundo tem, toda linguagem tem, e etc... Acontece que alguns são dramatizados. O borrow por exemplo, não achei nada tão complicado. É difícil de se adaptar rapidamente, mas não é nada tão dramático quanto fazem aparecer.

"ownership não funciona"

Ownership é apenas um CONCEITO para ilustrar como o borrow check se comporta. Não acho que o borrow check limita nada, apenas exige que você modele o problema diferente. As vezes é realmente um pé no saco e você só quer partir o teclado no meio, quando é especialmente algo simple , mas conforme você se acostumar com a linguagem é natural.

É apenas a minha opinião:

As comunidades são uma loucura em todo mundo. Se você fala bem demais algo você é defensor, se fala mal de algo é militante.

Eu gostaria de frisar que esta é a minha experiência com a linguagem. 1 ano usando não é muito tempo, mas já uma boa experiência. Esta pode não ser a sua, e tudo bem.

marcdantas

Autor

3 dias atrás

Eu estou utilizando Rust mais ou menos desde 2018 quando o Rust começou a tomar uma proporção maior e durante os primeiros anos de uso eu gostava bastante da linguagem e acreditava que era uma das melhores linguagens do mundo.

O problema é que quando vc começa a fazer projetos realmente sérios vc percebe o quão difícil é trabalhar com o Rust sem precisar se adequar a segurança dele.

O argumento de "você se acostuma", "é assim mesmo" é mais que inválido. Você está literalmente negando um estilo de código para seguir uma regra estúpida de design da linguagem. Isso é literalmente forçar o programador a programar do jeito que você (criador da linguagem) quer.

Eu tenho uma frase que mantenho na minha cabeça para nao enlouquecer:
"Eu odeio todas as linguagens igualmente"

Assim eu não me apego a nenhuma linguagem específica e começo a defendê-la com unhas e dentes. Coisa que 99% dos "programadores" da atualidade fazem hoje em dia e é nojento.

Outra coisa que esqueci de comentar no post é que o Rust está se tornando uma propaganda política bem forte no mundo open-source. Outra coisa bem ruim de se existir em um ambiente que não tem necessidade de envolver o tema.

teknolista

3 dias atrás

Minha percepção de Rust é que seus mantenedores procuraram incorporar as lições aprendidas de outras linguagens, e isto foi muito bem visto pela comunidade de programadores. Rust permanece invicto como a melhor linguagem de programação por muitos anos, e todos elogiam o quanto a linguagem e seu ecossistema são bem organizados.

Mas, por outro lado, a experiência de desenvolvimento (DX) da linguagem é péssima, bem pior que a de C e C++. E sua comunidade evita falar sobre isso, consideram heresia. Para muitos isso é fundamental; por isso, preferem se manter em outras linguagens como Python, PHP, Ruby ou TypeScript.

. Eu li os outros posts. Tem sido uma jornada... :)