En face avec toi sur tout ces points

Sur la syntaxe je pense que c'est l'héritage de OCalm et de la programmation fonctionnelle plus que des contraintes mémoires liés aux borrow-checker.

Pour le noyaux linux, il est difficile de comprendre le choix de Linus. Certains parlent de pressions venant des GAFAMS (réduction des coûts car à terme nombres de dev Rust > nombres de dev C ou des enjeux en lien avec les licences GPL/MIT). Linus semblait parlé du fait qu'attiré de nouveaux dev en C était difficile est que Rust allait faciliter la chose.
Je suis sceptique, car au delà de C et du Rust, le dev système c'est plus une affaire d'élements très bas-niveau que d'un langage de programmation.
Mais je suis d'accord, Rust dans l'intégration du noyau risque de poser des soucis (c'est déjà le cas) car le modèle mémoire du noyau Linux n'est pas celui de Rust. (et la même logique s'applique pour tous les aspects en lien avec l'execution parallèle (threads, asynchrone, mulitprocessing...)).
A mon sens, il aurait était plus intéressant pour le noyau de faire évoluer son langage C.
Pour le Rust comme kernel, il y a le projet RedOx.

"En Rust le type indique l'intension et les contraintes lié à une allocation mémoire, alors qu'en C/C++ on a juste un pointeur."

Et par curiosité, quelle version du C++ tu utilises ? Parce que je suis d'accord pour le "vieux C++". Mais ce n'est plus le cas avec le C++ moderne. Les pointeurs ne sont plus censé se trimballer seul maintenant, et surtout, sauf cas particulier, on en a rarement besoin.

Ah oui, mélanger la notion de pointeur en C avec celle du C++, c'est pas comparable. Le pointeur C et C++ sont sémantiquement la même chose, mais la manière de les utiliser à largement changer.

"L'exemple qui me vient en premier est les pointeurs en C/C++ vs Rc, RefCell, Arc, Mutex, RwLock en Rust."

C'est quoi le rapport entre un pointeur et Arc, Mutex et autres ? On mélange des choux et des carottes là, non ?

*"Effectivement on utilisait du "vieux C++", les choses ont évolué en C++. Mais pas toutes les bases de codes, tout le monde n'a pas envie de faire du C++ moderne, et n'est pas obligé.
C'est une des raisons pour laquelle je préfère Rust, il y a une contrainte de "qualité de code" supérieur."*

Mais ne pas faire de C++ moderne, sauf cas particulier, est idiot ! C'est comme utiliser de l'essence au plomb alors qu'il y a mieux.
La qualité d'un code ne dépend pas d'un langage mais du développeur. En revanche qu'on se sente plus à l'aise avec Rust ou le C++ pour faire un code de qualité, c'est plus une question de goût et de couleur.

La qualité d'un code ne présume absolument pas de sa fiabilité. Voici un bon exemple : https://github.com/RustCrypto/block-ciphers. Autant de dire qu'utiliser ce code dans autre chose qu'un projet de hobbyiste, c'est prendre des gros risques.
Pourquoi ? Car Rust ne peut pas garantir l'execution en temps constant ni l'assembleur produit.
Ce qui fait la confiance d'une libraire, ce n'est pas uniquement la qualité de son code. J'ai bien plus confiance dans BLAS que dans n'importe quelle code, quand bien même Rust garanti l'absence de bug mémoire dans son implémentation.


*"Le rapport que je fais, c'est que dans les deux cas c'est le moyen d’accéder à une allocation mémoire.
Si le C++ moderne incite à ne plus utiliser directement les pointeurs, c'est encore possible, et très présent dans les bases de code historique."*

Je reformule ma question. En quoi un Mutex est un access à la mémoire ? Sémantiquement ça ne fait pas de sens.

"En Rust (non Unsafe) il n'y a pas de pointeur, une allocation mémoire est encapsulé dans un objet qui contraint (et explicite) la façon dont on pourra accéder à la donnée (modification ou pas, multi-thread ou pas"

Oui comme en C++ avec le concept du RAII. Alors certes, on n'a pas les même garanti que Rust à la compilation, mais on les a à l'execution.

Le vieux C++ doit disparaître des codes et surtout de l'enseignement de la programmation aux nouvelles générations. Le vieux C++ est révolu et ne doit perdurer que les endroits où les MaJ d'un code n'est pas simple et sans conséquence.

"Pas seulement, Rust (et sont écosystème) apporte plus d'outils pour aider à faire du code de qualité."

Comme en C++ où il existe une multitude d'outils. Le Rust a l'avantage d'avoir compris que ce genre d'outils sont nécessaire à avoir dans un langage plus récent.

"Et ça fait une importante différence, car à l'exécution, c'est plus compliqué à tester, et parfois difficile d'être certain que c'est bien testé."

C'est bien vrai, mais un peu de nuance sur ce point. Les sécurités de Rust sur les accès mémoires sont partiels. Une vrai vérification est un problème NP-hard et là Rust aurait un temps de compilation mésosphérique. Le borrow-checker couvre les cas les plus courants et normalement, si on ne fait pas de saloperies, ça marche dans 100% des cas. Mais le système de vérification peut-être mis en échec et ça seul un test réel pourra permettre de le détecter.

Et là, il est très naturel dans un code C++ sérieux (qu'importe pro ou sérieux) d'avoir des checks mémoires forts sur la stack ou sur la heap lors des phases de dev et de tests. Est-ce plus naturel de faire tourner un valgrind avec Rust qu'avec du C++ ? Je ne sais pas pour ma part mais pour les codes Rust qui font du unsafe ou FFI, je n'ai pas souvenir d'un projet sur Github d'importance utilisant ce genre de vérifications.

" (en dehors des usages ou la compilation est un problème, type "scripting dynamique" par exemple)."

En dehors du HPC, de toute approche parallèle plus complexe qu'un fork-join, de la crytographie, du jeux vidéos... Rust est très bon là où la sécurité mémoire est critique (e.g, équipement réseau, pare-feu, noyau...). Mais si la sécurité mémoire n'est pas une priorité, Rust devient moins utile/interessant comme solutions.

"Et sur quoi tu te bases pour dire que Rust est nettement moins répandu que Python ?"

La faible migration de projet vers Rust (les offres en C++ sont largement supérieure à Rust en France). Le faible classement dans l'index TIOBE, et le fait que le C/C++ domine toujours depuis 10 ans alors que Rust peine encore à prendre la place.
Quand Python est arrivée, en 10 ans il a pris la place de Matlab, IDL et consort dans les milieux académiques et industrielle. Matlab est encore enseigné dans les écoles d'ingénieurs au coté de Python mais de plus en plus de prof. passe à Python. Idem pour les universités.
Quand à Rust, bah il commence à sortir le bout de son nez.

Tu parlais du Rust dans le jeu vidéo. Je ne l'ai pas vu détroner significativement le C++ dans ce domaine. En revanche, j'ai vu Python faire office d'alternative à Lua.

Comparer Rust SO avec TIOBE ne renseigne pas sur la même information. TIOBE fonctionne sur "Le nombre de pages web retournées par les principaux moteurs de recherche lorsqu'on leur soumet le nom du langage de programmation". Donc clairement à l'échelle du Web, on parle moins de Rust que des autres langages, pourtant personne ne nie que Rust à le vent en poupe.

Pour SO, comparer Rust, Javascript et Python me laisse dubitatif sur les questions posés. bref, ce genre de sondages a la même valeur que "80 % des sympatisants d'un parti politique sont pour Mr X à la tête du parti". Et pourtant Mr X se prendre une branlée aux élections présidentielles.

Pour le jeux vidéo, où verrais-tu l'usage de Rust ?

Pour le jeux vidéo nous verrons à l'usage. Mais on trouve bien des moteurs en Go, en C# alors pourquoi pas en Rust.

John Kelsey, Bruce Schneier, David Wagner, and Chris Hall. Side channel cryptanalysis of product ciphers.Journal of Computer Security, 8(2-3):141–158, 2000.

21. Paul C. Kocher. Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems. In
Advances in Cryptology – CRYPTO 96, volume 1109 of LNCS, pages 104–113. Springer, 1996.

22. Robert Könighofer. A fast and cache-timing resistant implementation of the AES. In Tal Malkin, editor,CT-RSA, volume 4964 of Lecture Notes in Computer Science, pages 187–202. Springer, 2008.

Parmi quelques exemples en tête.


ça n'a rien à voir avec la manière dont Rust ou le C gère la mémoire à la fin tout est un pointeur (même en Rust). ça a avoir avec la conversion du Rust/C en assembleur.

Et prouver qu'un code est en temps constant ne se fait pas avec dudect-bencher. Il manque des fonctionnalités essentielles pour quelque chose d'aussi sérieux que de la cryptographie.

Est-ce que Rust plus problématique que le C ? Dans l'absolue oui car il n'est pas possible créer des librairies en Rust pour figer le code. Ainsi, si je produis une crate pour un chiffrement sensible, je ne dispose d'aucune garanti que le code généré ne vas pas changer, suite par exemple à une MaJ du compilateur (e.g., modification d'un cmov avec jmp). Sur ce point, le C est légèrement plus robuste car on peut, dans une certaine mesure, figé des choses en disant au compilo "Touche pas à ça petit con".
L'autre défaut à mon sens, c'est que l'inclusion d'asm en Rust n'apporte aucune garanti à ma connaissance que le compilateur ne va pas modifier l'ordre des instructions, en C tu peux garantir ceci.
En pratique, la seule façon d'être robuste (en Rust comme en C) et d'utiliser une lib "de confiance" (comme tu l'as mentionné dans ton précédent poste).

Le défaut majeure de Rust est cette manie à vouloir tout réécrire. Très bien, si ça fait plaisir à des personnes de coder en Rust et de moderniser de vieilles choses en C/C++, allez-y. Mais vouloir reprogrammer du chiffrement en Rust (comme AES), c'est prendre un risque si jamais c'est mal fait.

Si tu couples avec l'effet NPM de Rust et ses crates, tu arrives à quelque chose où des implémentations cryptographiques vulnérables vont se retrouver cacher au fin fond d'un empilement de crate pour des services exposés sur le Web. C'est pas comme si on n'avait pas le retour d'expérience avec NPM ou Pip.

Mitigons ce point par le fait que les algorithmes de chiffrements modernes (i.e, plus récent qu'AES) tel que Chacha20 sont conçus pour éviter une partie des défauts de l'AES et de ce type d'attaque, car les LUT n'existent plus dans le design et repose que sur des opérations que l'on sait produire en temps constant.


Concernant les liens et les sources, tu as les trois papiers (mais tu as déjà capté l'idée) et le reste n'est que de la logique qui a déjà été éprouvé avec le C (cf. RSA et l'exponentiation modulaire).


Conclusion de mon point. Si je dois utiliser du chiffrement en Rust (e.g. AES) , je chercherai idéalement une lib de référence (e.g., standard ou certification FIPS). A défaut quelque chose qui s'appuie sur des librairies éprouvées dans d'autres langages. Dans le pire des cas, une implémentation reposant uniquement sur l'usage des instructions AES-NI. Tout le reste, en dehors d'un projet perso sans conséquence, je ne voudrais même pas l'inclure.


Ultime conclusion: Rust est un langage "memery safe" (même s'il y a des limites) contrairement au C ou C++. Mais Rust et le C ne sont pas langages "constant time".