Chez les ingénieurs découvrant Rust, le temps d'attente des builds dépasse les erreurs du borrow checker comme principale friction consignée dans les deux premiers mois

Hypothèse

Le récit habituel de l'apprentissage de Rust place le borrow checker au centre : les premières semaines se passent à lutter contre les erreurs d'ownership et de durée de vie (lifetime) jusqu'à ce que le modèle s'éclaire. L'hypothèse est que ce récit ne décrit que la première phase. Une fois que corriger les erreurs d'ownership devient une routine, la plainte dominante dans les propres relevés d'un nouvel arrivant devient l'attente du compilateur : builds complets après un changement de dépendance, builds incrémentaux lents dans les gros crates, exécutions de tests qui déclenchent une recompilation, et builds d'intégration continue. cargo check atténue ce problème, puisque la documentation de Cargo le décrit comme compilant sans l'étape finale de génération de code, ce qui le rend plus rapide que cargo build, mais les tests et les binaires nécessitent toujours le build complet. L'affirmation porte sur le point de bascule : en l'espace de deux mois de travail quotidien en Rust, les entrées portant sur le temps d'attente des builds dépassent en nombre les entrées portant sur les erreurs du borrow checker dans le journal de friction d'un nouvel arrivant.

Prédiction

Dans des journaux de friction hebdomadaires tenus par des ingénieurs découvrant Rust, la part des entrées classées comme erreurs d'ownership ou d'emprunt (borrowing) est la plus élevée au cours des deux premières semaines et diminue semaine après semaine ; la part classée comme attente de build ou de test augmente et dépasse la part liée à l'ownership au plus tard à la huitième semaine. Le point de bascule survient plus tôt dans les projets de plus grande taille et plus tard pour les ingénieurs qui travaillent dans de petits crates ou qui viennent du C++ plutôt que d'un langage à ramasse-miettes. Si, à la huitième semaine, les entrées liées à l'ownership dépassent encore en nombre les entrées liées à l'attente des builds pour la plupart des participants, l'hypothèse est fausse.

Test proposé

1. Recruter des ingénieurs qui commencent un travail quotidien en Rust sur une base de code existante, et consigner leur langage précédent, le nombre de crates du projet et un temps de build à froid sur leur machine.
2. Demander à chacun de consigner, à la fin de chaque journée de travail, chaque moment de friction sous forme d'une ligne avec une catégorie tirée d'une liste fixe : erreur d'ownership ou d'emprunt, erreur de type ou de trait, attente de build ou de test, outillage, API de bibliothèque, autre. Donner des exemples par catégorie avant le début de l'étude.
3. Recueillir les journaux chaque semaine pendant dix semaines ; calculer, par personne et par semaine, la part des entrées par catégorie et la semaine de bascule, le cas échéant.
4. Recouper avec des données objectives lorsque c'est possible : les codes d'erreur du compilateur tirés du journal de diagnostics de l'éditeur, et les durées de build tirées du rapport que produit cargo build --timings.
5. Rapporter des trajectoires par personne plutôt qu'une courbe agrégée, puisque l'affirmation porte sur le moment où la bascule se produit pour la plupart des personnes.

Statut

Aucun résultat n'est avancé. Les journaux de friction mesurent ce que les personnes remarquent, et une attente n'est pas remarquée de la même façon qu'une erreur ; le recoupement de l'étape 4 montre si les parts consignées suivent les comptages sous-jacents. Dix semaines avec une poignée d'ingénieurs peuvent montrer si le point de bascule existe et approximativement quand, mais pas son instant précis.