Matt Godbolt a vanté Rust en démontrant ses atouts à travers le C++

• L’auteur, qui utilise C++ depuis plus de 20 ans, explique comment une conférence de Matt Godbolt l’a amené à redécouvrir les atouts de Rust
• En C++, les erreurs dues à la confusion de types ne sont pas correctement repérées par le compilateur, alors que Rust les bloque fermement à la compilation
• Au-delà de la simple sécurité mémoire, Rust adopte une conception qui aide aussi à éviter les mauvais usages des API
• En particulier, même pour le traitement des entrées à l’exécution, Rust impose une gestion explicite des erreurs, ce qui réduit les risques
• Au final, c’est un exemple qui montre que la conception d’un langage peut devenir un outil puissant pour empêcher les erreurs des développeurs

---

Introduction

• La conférence de Matt Godbolt, "Correct by Construction", met en lumière les problèmes de conception d’API en C++, ce qui rejoint aussi la philosophie de Rust
• C’est une bonne porte d’entrée pour comprendre les points forts de Rust

What's in a type — les limites du C++

• Une signature de fonction comme void sendOrder(const char *symbol, bool buy, int quantity, double price) est très sujette aux erreurs
• Lorsqu’on n’utilise que des types primitifs comme bool, int ou double, le compilateur n’émet pas d’avertissement même si un type est mal passé
• Un alias de type comme using Price = double ne permet pas de distinguer réellement les types
• En créant Quantity et Price avec des classes et des constructeurs explicit, le compilateur peut bien intercepter certaines erreurs, mais :
  • les valeurs négatives restent acceptées, et le problème n’apparaît qu’à l’exécution
  • avec static_assert et des templates, on peut forcer des vérifications à la compilation
  • mais des conversions à l’exécution comme atoi peuvent toujours provoquer un dépassement d’entier, sans que le compilateur le détecte

En quoi Rust est-il différent ?

• Avec une définition de fonction équivalente, Rust signale clairement les incompatibilités de types comme des erreurs au moment de la compilation
• Des nouveaux types comme struct Price(pub f64); struct Quantity(pub u64); se définissent simplement, et le blocage des entrées négatives fonctionne naturellement
• Des conversions de chaîne à l’exécution comme "string".parse::<u64>() exigent elles aussi une gestion explicite des erreurs
• Forcer le déballage d’une valeur avec .expect() peut provoquer un crash à l’exécution, mais le texte souligne que cela reste préférable aux erreurs silencieuses du C++

Conclusion

• Rust va au-delà de la simple sécurité mémoire : il protège les développeurs grâce à la prévention des mauvais usages d’API, aux vérifications à la compilation et à un système de types explicite
• Cela montre la force de la conception d’un langage pour prévenir les erreurs des développeurs avant qu’elles ne surviennent
• Les débutants en Rust peuvent avoir du mal avec le borrow checker, mais cette difficulté finit par se résoudre avec le temps
• C++ a beaucoup évolué au fil de son histoire, mais il reste difficile pour lui d’offrir la sécurité fondamentale et la clarté que propose Rust

Références

• Conférence : Correct by Construction: APIs That Are Easy to Use and Hard to Misuse
• Activités de Matt Godbolt et Compiler Explorer

[cronex]

La plupart des points souvent cités comme des défauts de C++ semblent en grande partie être maintenus à cause de la compatibilité avec le langage C.
Serait-il possible de faire évoluer le langage pour qu’on puisse développer en abandonnant cette compatibilité avec C ?

[coremaker]

Ça aurait été mieux s’ils n’avaient pas proposé unsafe.

[codemasterkimc]

Le langage fondamental = Rust

[GN⁺]

Commentaires Hacker News

• Le plus grand atout de Rust est son type Result, qui unifie la manière de propager les erreurs. Ce qui est séduisant, c’est qu’il n’y a pas à se soucier des exceptions ou de multiples façons de retourner des erreurs

  • Grâce au raccourci ? et à l’interface fonctionnelle de Result, la gestion des erreurs est agréable et facile à manipuler
  • Par rapport à la gestion complexe des erreurs en C++, le manque de cohérence est frustrant

• Il y a beaucoup de mécontentement vis-à-vis de C++. Le problème, en particulier, est qu’il faut se souvenir de nombreuses règles, et qu’en se trompant sur une seule, le code peut devenir vulnérable

  • Pour améliorer la sécurité de C++, il faudrait une approche similaire à la manière sûre de Rust

• Le code C++ écrit actuellement ressemble à du Rust. Il utilise des types explicites et robustes, ainsi qu’une gestion claire de la durée de vie

  • Le compilateur Rust aide davantage à détecter les bugs et à signaler les erreurs

• Le problème des conversions implicites en C++ relève davantage des bibliothèques que du langage lui-même

  • Il est possible d’implémenter en C++ des fonctionnalités similaires à Rust, mais cela nécessite le support des bibliothèques

• Rust n’a ni arguments nommés ni tuples nommés, ce qui rend l’usage de structures Args/Options peu pratique

• L’option -Wconversion permet de détecter certains problèmes de conversion, mais elle ne s’applique pas à tous les cas

  • Par exemple, convertir 1000.0 en 1000 est considéré comme ne causant pas de perte de précision

• L’un des points où Rust est meilleur est l’absence de conversions numériques implicites. En C++, il vaut mieux éviter atoi et utiliser à la place les fonctions de conversion de la STL

• Il n’existe pas encore en Rust ou en Golang de fonctionnalités comparables aux contraintes SQL, ni aux types personnalisés et validateurs de pydantic

• Si le podcast de programmation de Matt et Ben Rady, "Two's Complement", vous intéresse, cela vaut le coup d’y jeter une oreille