Usando (e amando) Rust por cerca de 10 anos: pontos frustrantes que percebi

Uso Rust há cerca de 10 anos e realmente amo essa linguagem. Mas também existem alguns pontos frustrantes. Abaixo está a lista.

1. O problema de Result<T, E>

O tratamento de erros do Rust é excelente por ser claro e obrigatório. No entanto, na prática, ele traz muitos incômodos.

• Dificuldade para autores de bibliotecas: o processo de criar novos tipos de erro e convertê-los é trabalhoso. Sempre que se adiciona uma dependência, é especialmente chato ter que incluir o tipo de erro de cada função no tipo de erro wrapper.
• Trabalho extra no código de aplicação: mais importante do que saber exatamente por que uma função falhou é propagar o erro para cima e mostrar o resultado ao usuário. Diferentemente do Java, o Rust não fornece backtrace durante a propagação, o que dificulta identificar a causa do problema.

2. A flexibilidade do sistema de módulos

O sistema de módulos do Rust é flexível demais e, por isso, muitas vezes acaba sendo inconveniente.

• Flexibilidade excessiva: é possível reexportar tipos ou ajustar com granularidade os níveis de acesso, mas isso pode acabar expondo por engano tipos que você não queria tornar públicos.
• Problema da orphan rule: dividir um projeto em vários crates é algo recomendado, mas a orphan rule às vezes atrapalha.

3. Tempo de compilação e ferramentas de IDE

O tempo de compilação do Rust e a verificação de erros nas ferramentas de IDE são lentos demais.

• Tempo de compilação longo: em projetos grandes, ao modificar uma função, o crate inteiro é recompilado, o que é muito ineficiente.
• Resposta lenta da IDE: o Rust analyzer dá a sensação de reindexar o projeto inteiro a cada tecla digitada, e isso é especialmente problemático em projetos grandes.

Conclusão

Rust é minha linguagem favorita, mas esses pontos frustrantes também existem. Fico curioso para saber se outros usuários estão passando pelos mesmos problemas.

[ranolp]

No caso do tratamento de erros, fica prático instalar e usar snafu/thiserror em bibliotecas e eyre/anyhow em aplicações.

[y15un]

As dificuldades de quem escreve bibliotecas: [..snip..] Toda vez que você adiciona uma dependência, ter que adicionar o tipo de erro de cada função ao tipo de erro wrapper é especialmente incômodo.

Sinto isso profundamente. Já perdi as contas de quantas vezes criei um enum de erro específico do crate e fiquei escrevendo impl From<ExtError> for Error para os tipos de erro puxados das dependências, pensando "que saco" a cada vez...

[eususu]

Talvez seja porque eu ainda não consegui começar direito, mas queria sentir esse tipo de decepção.
Obrigado pelo ótimo texto~

[undercat]

Obrigado pelo ótimo artigo!

[tsboard]

Sobre os longos tempos de compilação, acho que o comentário abaixo pode ajudar, então estou adicionando aqui: (by pr4wl)

Se o Rust analyzer estiver fazendo uma recompilação longa toda vez que algo muda, isso provavelmente acontece porque os recursos ou variáveis de ambiente usados ao compilar a aplicação são diferentes. Por padrão, o RA usa o mesmo diretório de destino do cargo build para armazenar os artefatos de build, e se forem feitos builds incompatíveis entre si, ele continuará fazendo o build completo repetidamente.

Esse problema pode acontecer com frequência especialmente no Bevy, quando o recurso bevy/dynamic_linking é usado no build, mas não no Rust analyzer.

A solução mais simples é instruir o RA a usar um diretório de destino diferente. Mais detalhes sobre isso podem ser encontrados em rust-analyzer.cargo.targetDir.

Outra solução é configurar tudo para que todos os recursos e variáveis de ambiente sejam iguais, permitindo reutilizar os artefatos de build uns dos outros. Mas isso pode ser complicado.