Je suis un fervent défenseur de Rust et de l’idée qu’il est temps qu’on abandonne C et C++. Malgré les avantages indéniables que Rust procure à la programmation, beaucoup ne sont pas de cet avis et pensent qu’il est possible de produire des logiciels sûrs avec C++, à condition d’utiliser ce qu’on appelle Modern C++. Voyons un peu pourquoi ces allégations ne sont que le reflet d’un déni plein de mauvaise foi.

Entêtement

J’avais déjà un exemple montrant que les outils fournis par C++ moderne ne nous protègent pas assez contre les bugs mémoires idiots. C’est en lisant un article d’Alex Gaynor qu’il m’est apparu évident qu’à cause de l’obligation de rétro-compatibilité, C++ est dans une impasse.

Toutes tentatives d’amélioration du langage est destinée à l’échec à cause de la syntaxe déjà très chargée et le recours à toujours plus de template sans améliorer les messages d’erreur des compilateurs rends le tout très indigeste et décourage l’adoption de ces nouveaux outils qui sont censées nous aider à produire du C++ safe.

Cet entêtement à ajouter des fonctionnalités dans un langage déjà tellement chargé de trucs à l’ergonomie discutable ne mènera jamais à un langage dans lequel on peut avoir confiance, vu que les humains ne se donneront pas la peine de faire l’effort de les utiliser. C’est pourquoi l’approche prise par Rust qui nous oblige à écrire du code safe est une voie bien plus réaliste pour supprimer les bugs de gestion mémoire qui, rappelons le, peuvent mener, au mieux, à des crash ou des failles de sécurités, et au décès si le dit code est sur des appareils critiques (santé, avion…), au pire.

Déni

Des développeurs C++ en plein déni

Ensuite, il y a les gens qui sont dans le déni. J’ai eu un collègue qui est un expert en C et qui lit l’assembleur en guise de journal le matin… Le C++ lui passe totalement au dessus, comme toute tentative d’abstraction d’ailleurs. J’ai l’impression que pour lui, pas besoin d’architecture, ni de librairie, la réutilisation passant par des fonctions utilitaires qu’il va copier-coller d’un projet à l’autre… Ajoutons à cela son style de code (quasiment pas d’espace sur chaque ligne, variables à une lettre en majorité), je me dis que s’il disparaît pour une raison ou une autre, reprendre son taf va donner de bonnes crise de nerfs…

Je ne pensais même pas qu’il puisse encore exister ce genre de codeur, véritable bidouilleur du dimanche qui applique des méthodes artisanales sur un projet industriel. Ce type de personne refusera de facto d’admettre que leur façon de faire est mauvaise et n’auront ni le courage, ni l’envie, d’admettre l’intérêt d’une techno comme Rust. Même pris la main dans sac à commettre du code unsafe, ils répondront qu’ils savent ce qu’ils font et que là, ça marche.

Ce gars est un exemple assez extrême, mais des gens qui pensent « qu’ils savent ce qu’ils font » ou autre déclinaison sur le thème de « ce n’est pas le language le problème, c’est les programmeurs qui ne sont pas assez bons » est bien ancré dans la population. Il suffit de sortir des forums de la bienveillante communauté des Rustaceans et de lire les commentaires d’articles qui mentionnent Rust. C’est un véritable déni collectif.

Déni d’autant plus risible que beaucoup dégainent comme argument contre Rust, les outils d’analyse statique de code et autre Valgrind pour détecter les fuites mémoires… J’ai envie de leur dire : « C’est bien tout ça, mais justement, Rust a tout ça d’intégré dans son compilateur, tout le temps. », mais je suis certain qu’ils trouveraient un autre moyen de se justifier.

Conclusion

Où je veux en venir avec tout ça ? Qu’encore une fois, à cause d’un facteur de path dependency, on va se traîner des failles de sécurité à tout va. Dans un monde où on a des fuites de données tous les mois, où on connectera même les WC sur Internet (en fait, c’est déjà fait), la sécurité devrait être la priorité absolue dans l’industrie, et elle ne pourra être atteinte sans changement radical sur les outils qui sont utilisés pour écrire les logiciels qui nous entourent. Le langage de programmation étant le premier d’entre-eux, évidemment.

Je peux sembler très négatif, sûrement à cause du rejet de Rust de la part de ce collègue, mais tout n’est pas sombre et je vois des choses se produire : Amazon et Microsoft qui sponsorisent officiellement Rust, Intel qui est impliqué dans le design du langage pour faciliter l’écriture de BIOS et autres firmwares en Rust…

Du progrès donc, en espérant que la cadence s’accélère jusqu’à qu’il devienne évident dans la tête des gens que non, on ne peut pas écrire de code safe en C/C++ sur un projet de taille industrielle, que les outils d’analyses sont lourds à mettre en place et donc, dans la majorité des cas, on ne les utilisera pas : on ne lance Valgrind que lorsqu’on a des crash du à un épuisement de la mémoire (en production, tant qu’à faire).