Para engenheiros novos em Rust, o tempo de espera do build supera os erros do borrow checker como principal atrito registrado nos dois primeiros meses

Hipótese

O relato habitual sobre o aprendizado de Rust coloca o borrow checker no centro: as primeiras semanas são gastas lutando contra erros de ownership e de lifetime, até que o modelo faça sentido. A hipótese é que esse relato descreve apenas a primeira fase. Quando os erros de ownership passam a ser rotina de corrigir, a principal queixa nos registros do próprio iniciante passa a ser a espera pelo compilador: builds completos após mudanças de dependências, builds incrementais lentos em crates grandes, execuções de testes que recompilam e builds de CI. O cargo check ameniza isso, pois a documentação do Cargo o descreve como uma compilação sem a etapa final de geração de código, o que é mais rápido que o cargo build; ainda assim, testes e binários exigem o build completo. A afirmação diz respeito ao ponto de cruzamento: em até dois meses de trabalho diário com Rust, as anotações sobre tempo de espera do build superam, no diário de atrito do iniciante, as anotações sobre erros do borrow checker.

Previsão

Nos diários de atrito semanais mantidos por engenheiros novos em Rust, a proporção de anotações classificadas como erros de ownership ou de borrowing é mais alta nas duas primeiras semanas e diminui a cada semana; a proporção classificada como espera de build ou de testes sobe e ultrapassa a de ownership até a oitava semana, no máximo. O cruzamento ocorre mais cedo em projetos maiores e mais tarde para engenheiros que trabalham com crates pequenos ou que vêm de C++ em vez de uma linguagem com garbage collector. Se, na oitava semana, as anotações de ownership ainda forem mais numerosas que as de espera de build para a maioria dos participantes, a hipótese é falsa.

Teste proposto

1. Recrutar engenheiros que estejam começando a trabalhar diariamente com Rust em uma base de código existente e registrar a linguagem anterior de cada um, o número de crates do projeto e o tempo de um build limpo na máquina do participante.
2. Pedir que cada um registre, ao fim de cada dia de trabalho, cada momento de atrito em uma linha, com uma categoria de uma lista fixa: erro de ownership ou borrowing, erro de tipo ou trait, espera de build ou testes, ferramentas, API de biblioteca, outro. Dar exemplos de cada categoria antes de o estudo começar.
3. Coletar os diários semanalmente por dez semanas; calcular, por pessoa e por semana, a proporção de anotações em cada categoria e a semana do cruzamento, se houver.
4. Fazer a verificação cruzada com dados objetivos sempre que possível: códigos de erro do compilador a partir do log de diagnósticos do editor e durações de build a partir do relatório gerado por cargo build --timings.
5. Apresentar as trajetórias individuais, e não uma curva agregada, já que a afirmação trata de quando o cruzamento acontece para a maioria das pessoas.

Estado

Nenhum resultado é alegado. Diários de atrito medem o que as pessoas percebem, e uma espera é percebida de modo diferente de um erro; a verificação cruzada do passo 4 mostra se as proporções registradas acompanham as contagens reais. Dez semanas com um punhado de engenheiros podem mostrar se o cruzamento existe e aproximadamente quando ocorre, mas não o momento exato.