Près de 10 ans d’utilisation (et d’amour) de Rust : les points décevants que j’ai constatés

Cela fait environ 10 ans que j’utilise Rust, et j’adore vraiment ce langage. Mais il y a aussi quelques points décevants. En voici la liste.

1. Le problème de Result<T, E>

Le fait que la gestion des erreurs en Rust soit claire et contraignante est excellent. Mais à l’usage, cela s’avère souvent peu pratique.

• Difficultés pour les auteurs de bibliothèques : créer de nouveaux types d’erreur et les convertir est fastidieux. Chaque fois qu’on ajoute une dépendance, devoir ajouter le type d’erreur de chaque fonction à un type d’erreur enveloppe est particulièrement pénible.
• Lourdeur dans le code d’application : ce qui importe, ce n’est pas tant pourquoi une fonction a échoué que de propager l’erreur vers le haut et d’afficher le résultat à l’utilisateur. Contrairement à Java, Rust ne fournit pas de backtrace pendant cette propagation, ce qui rend difficile l’identification de la cause du problème.

2. La flexibilité du système de modules

Le système de modules de Rust est parfois trop flexible, au point d’en devenir peu pratique.

• Flexibilité excessive : on peut réexporter des types ou ajuster finement les niveaux d’accès, mais cela peut conduire à exposer par erreur des types qu’on ne voulait pas rendre publics.
• Le problème de la règle d’orphelin : il est recommandé de diviser un projet en plusieurs crates, mais la règle d’orphelin devient parfois un obstacle.

3. Temps de compilation et outils IDE

Le temps de compilation de Rust et la vérification des erreurs dans les outils IDE sont trop lents.

• Temps de compilation longs : dans les gros projets, modifier une seule fonction entraîne la recompilation de toute la crate, ce qui est très inefficace.
• Lenteur de réponse de l’IDE : Rust analyzer donne l’impression de réindexer le projet à chaque frappe, ce qui est particulièrement problématique sur les gros projets.

Conclusion

Rust reste mon langage préféré, mais ces points décevants existent malgré tout. Je me demande si d’autres utilisateurs rencontrent les mêmes problèmes.

[ranolp]

Pour la gestion des erreurs, il est pratique d’installer et d’utiliser snafu/thiserror pour les bibliothèques, et eyre/anyhow pour les applications.

[y15un]

La difficulté des auteurs de bibliothèques : [..snip..] Chaque fois qu’on ajoute une dépendance, devoir ajouter le type d’erreur de chaque fonction au type d’erreur wrapper est particulièrement pénible.

Je ressens vraiment ça jusque dans les os. Ce n’est pas une ou deux fois que je me suis dit « c’est chiant à mourir » en créant un enum d’erreurs propre à la crate et en écrivant à chaque fois impl From<ExtError> for Error pour les types d’erreur remontés depuis les dépendances...

[eususu]

C’est peut-être parce que je n’ai pas encore vraiment commencé, mais j’aimerais bien ressentir ce genre de déception.
Merci pour ce bon article~

[undercat]

Merci pour cet excellent article !

[tsboard]

J’ajoute le commentaire ci-dessous, qui pourrait vous être utile concernant les temps de compilation longs : (par pr4wl)

Si Rust analyzer effectue une longue recompilation à chaque modification, c’est probablement parce que les fonctionnalités ou les variables d’environnement utilisées diffèrent de celles employées pour construire l’application. Par défaut, RA utilise le même répertoire cible que cargo build pour stocker les artefacts de build, et si des builds incompatibles sont effectués, cela déclenchera en permanence un build complet.

Ce problème peut notamment survenir fréquemment avec Bevy si vous utilisez la fonctionnalité bevy/dynamic_linking pour le build, mais pas dans Rust analyzer.

La solution la plus simple consiste à indiquer à RA d’utiliser un autre répertoire cible. Vous trouverez plus de détails à ce sujet dans rust-analyzer.cargo.targetDir.

Une autre solution consiste à configurer toutes les fonctionnalités et variables d’environnement de manière identique afin qu’ils puissent réutiliser mutuellement leurs artefacts de build. Cependant, cela peut être délicat.