Déja, cela https://matklad.github.io/2020/09/20/why-not-rust.html
Suivant cela de loin, j'ai quand même quelques reflexion/questionnement ouverte concernant rust, ainsi que sa récente apparition dans le kernel:
Déjà, premièrement, est-ce une bonne idée de mettre l'intelligence dans le système, ici dans le compilateur, en informatique ce qui marche le mieux est quand même ce qui l’externalise le plus, eg. le système internet.
Deuxièmement, et cela reprend le premier point. On s'éloigne du fonctionnement de la machine i.e. du fonctionnement du CPU, est-ce au compilateur de restreindre l'ABI pour éviter des corruptions sur le flux d'instruction ou de donnée sur les CPU? Ici, on garde l'ancienne arch von-neumann des cpu, avec la structuration logique des programmes en assembleur actuelle, mais on verrouille ce que l'on peut faire écrire par le compilateur. Est-ce qu'il n'y a pas d'autres trucs à aller creuser en dessous. Car bon un CPU, c'est un truc reprogrammable par essence, donc potentiellement toujours hackable.
Troisièmement, c'est quoi ce truc, cargo, qui te télécharge tout un rootfs à lui tout seul pour te build un helloword. Avec gcc, je n'ai besoin que de la libc compilée dans la même ABI que le compilateur et qui est déjà présente sur l'OS (en tout cas pour Linux avec gcc) dans le cas d'une compilation native, et ce n'est pas beaucoup plus compliqué dans le cas d'une compilation croisé ou canadienne, où il faut compiler le gcc target avec le gcc host qui a lui-même êtes compilé avec le gcc natif.
Quatrièmement, plus un langage s'éloigne du fonctionnement de la machine, plus ceux qui l'utilisent ont peu de connaissance du fonctionnement de la machine, et plus ils écrivent des trucs lourd et tordu, potentiellement source de bug. Ici on diffère peut-être le problème plus loin. Le coup de rust est secu, mouai bof, a la place d'être libre de faire ce que tu veux, tu n'as plus que 3 choix, mais c'est toujours à toi de faire le bon.
Cinquièmement, Qu'est-ce qu'il y arrivera le jour où il y aura les premières CVE sur la logique de fonctionnement de rust. Devra-t-on encore plus blinder l'usage du programmeur pour blinder rust et son cargo? quid de la rétrocompatibilité entre les vieilles API et les nouvelles à venir.
Bref, je ne sais pas, je ne m'y suis pas intéressé plus que cela, je suis encore un peu dubitatif
— Permalink