Discussion :

[Uther]

Oui enfin la c'était visiblement surtout quelque quidams lambda sur Github qui venaient sans doute de découvrir Rust peu après sa sortie, et qui ne connaissent visiblement pas grand chose, les utilisateurs de Rust sont généralement les premiers a s'en moquer.
Y'a pas de vraie demande de fond à tout réécrire en Rust.

[Aurelien.Regat-Barrel]

Hello

Je profite de ce topic pour partager mon point de vue et recueillir le vôtre. Pour info je suis spécialisé C++ et n'ai qu'une connaissance légère de Rust. Mais je m'intéresse pas mal à comment ce langage évolue et comment il est adopté dans l'industrie car de manière générale je suis passionné par comment les langages interagissent entre eux.

En lisant certains messages, je crois qu'il est important de préciser que ce qui fait le succès d'un langage ce n'est pas (simplement) ses qualité intrinsèques. C'est peut être même un aspect secondaire. Son écosystème et le support (financier) qu'il reçoit sont des facteurs essentiels : bibliothèques disponibles, IDE / debug / profiling, intégration avec d'autres systèmes, portabilité, etc... Donc surtout ne pas réduire un langage à sa syntaxe quand on veut comparer les utilisations (penser à comment javascript s'est imposé comme langage n°1!). Et donc le fait qu'il reçoive du soutient de la part de Microsoft est une très bonne chose pour le langage.

Un autre point à rappeler est que Rust n'est pas le premier langage à s'attaquer à C/C++ en apportant des innovations qui sont, objectivement, intéressantes. J'ai personnellement lu moultes démonstrations expliquant pourquoi ADA, Objective C, Eiffel, D, Nim... sont de meilleurs langages que C++. Mais il y a un petit détail : C++ est un langage avec un spectre d'utilisation extrêmement large dans plusieurs secteurs aux contraintes très différentes. Le remplacer sur certains segments est une tâche accessible, remplacer le langage de manière large est une tout autre histoire. Et il me semble que Rust occupe aujourd'hui la position de challenger que d'autres ont occupé avant lui (le langage D en particulier, qu'il a à mon avis tué) et peine à en sortir. Non pas qu'il n'en sortira jamais, mais il peine.

Et à mon avis c'est lié au segment sur lequel on le positionne presque systématiquement : la sécurité. Et c'est pas vraiment le plus porteur. Pour rappel les discussions sur la sécurité ne sont pas nouvelles : PASCAL se vantait d'être beaucoup plus secure que le C, et puis au final nos composants système les plus critiques (OS, drivers...) sont écrits en C... tandis que PASCAL n'est plus... De plus - et c'est pas un détail - il existe des solutions logicielles pour fiabiliser des programmes en C et C++. Le hic est qu'elles sont souvent payantes, à vil prix. Mais pour les structures qui ont ces besoin c'est acceptable. Et pour les domaines où ça ne suffit pas, genre l'aérospatiale, les personnes concernées avec qui j'ai pu en discuter ne juraient en général que par ADA, ou alors des solutions style Frama-C.

Donc pour moi Rust a un peu le cul entre deux chaises : pour les environnements critiques genre aérospatiale, il est face à plus qualifié que lui. Et pour les autres cas d'usage, et bien il a quand même un gros côté overkill. En particulier face à un langage comme Go et son approche "get the shit done". En effet y a quand même beaucoup de boites qui arrivent à correctement développer des logiciels en C ou C++ sans vraiment être troublées par des problèmes de sécurité : leurs problèmes au quotidien sont ailleurs. Oui certains bugs constatés ne se seraient pas produits avec Rust, mais ce n'est pas ce qui gêne le plus en pratique car l'outillage hyper mature aide à rattraper beaucoup de choses. Ca me parait important de le souligner car je trouve qu'au niveau communication sur Rust il y a une trop forte focalisation sur cet aspect dont au final peu de monde accord une forte importance. Je donne un exemple réel : dans une conf un mec répond à une question sur pourquoi il faudrait choisir Rust en expliquant pendant plusieurs minutes commet Rust offre de super garanties de sécurité en termes de programmation multi-thread etc... Puis il demande s'il a répondu à la question => "heu... nous on n'utilise pas de threads alors je sais pas". A trop se focaliser sur un aspect parmi tant d'autres, ça peut vite se retourner contre le langage en réduisant la perception de son champ d'application réel.

Enfin, pour qui essaye de suivre l'intégration de Rust dans Firefox, Mozilla n'envoie pas des signaux très positifs. Pour moi là ils ont clairement merdé quand leur comm. Ca a pris beaucoup plus de temps qu'annoncé, l'effet "silver bullet" tant vanté n'a pas vraiment eu lieu, et aujourd'hui le navigateur est en sérieuse difficulté face à ses concurrents intégralement propulsés en C++ : pas de quoi rassurer un décideur. C'est difficile d'avoir les raisons précises de ces difficultés, mais de ce que j'ai pu trouver comme information (j'ai du chercher sur les blogs perso de certains développeurs...) ça confirme ce que j'ai dit au début : développer une brique logicielle dans un coin est une chose. Intégrer cette brique dans des systèmes existants est une autre paire de manches. Et dans un environnement où à peu près tout repose sur C et C++, et bien ces 2 langages ont un avantage. La news ci-dessus vient rappeler cette dépendance en tout un tas de couches de compatibilité / intégration, et c'est avec ce genre de "détails" (qui se multiplient sur les gros projets) que commencent à se diluer tous les avantages qu'on a pu gagner ailleurs.

Par exemple j'ai lu le témoignage de développeurs qui au début ont été enthousiastes avec Rust, et puis ont fini par jeter l'éponge face à ses lacunes dans le domaine de la 3D en particulier. L’écosystème C++ dans ce domaine est colossal, et un nouveau langage ne peut pas rivaliser avec de multiples bibliothèques qui ont souvent +20 ans de développement ininterrompu dans des domaines très pointus. Sans parler, semble-t-il, de la prise de tête que c'est de coder des structures de données complexes telles des arbres ou des graphes.

Face à C, je suis aussi assez dubitatif - mais pour d'autres raisons. D'abord parce que C++, malgré sa possibilité de l'utiliser comme un meilleur C, n'est pas parvenu à convaincre les développeurs récalcitrants. Ceux que j'ai pu fréquenter travaillaient tous dans le domaine embarqué, et avaient comme point commun d'être très à l'aise avec des concepts bas niveau de hardware et d'électronique, de masquage de bits, etc... et par contre de très vite décrocher quand on commence à parler d'abstraction, POO, patterns, etc... Je ne suis même pas arrivé à les convaincre de l'utilité d'une classe vector ou string par rapport à une gestion manuelle ou via des macros. C'est une autre façon de penser le code, et c'est pourquoi je vois mal n'importe quel langage les convaincre. Y'a que Go semble-t-il, qui en séduit quelques uns (Ken Thompson doit y être pour quelque chose).

Donc au final désolé si je casse un peu l'ambiance, mais j'essaye de faire la part des choses entre ce qu'on aimerait qu'il se passe, et ce qu'il peut réellement se produire. Faire basculer des équipes de développement vers un nouveau langage ne répond pas aux mêmes critères de décision que choisir un langage pour un projet perso from scratch sur github. C'est un peu comme comparer 20 ans de vie de couple avec un flirt d'été Par le passé y'a eu des vagues d'enthousiasme et d'intérêt pour des langages comme D, F#, Haskell. Ces langages ont innové et ont clairement apporté quelque chose à tous ceux qui les ont étudiés à en devenir super fan. Avec aussi, il faut le dire je crois, ce petit côté "ça c'est un vrai langage pour les vrais programmeurs" qui en pratique se marie assez mal avec le pragmatisme de l'industrie.

Personnellement je suis très content que Rust soit là et contribue à faire progresser notre métier. Mais j'ai l'impression qu'on se dirige plus vers un marché de niche qu'une adoption massive du langage. Et les quelques retours d'expérience qui commencent à circuler tendent à confirmer cela.

Je pense en effet que c'est honorer une techno que d'en reconnaitre les limites, pour éviter de la mettre dans des situations où elle n'est pas adaptée et peut causer des dégats / déceptions. Paradoxalement, plus on connait les faiblesses et lacunes d'un langage, plus il devient fiable car sa zone de risque se clarifie. Et je trouve que c'est quelque chose qui manque encore beaucoup au sujet de Rust : des retours contrastés sur son emploi. Beaucoup de discours sont dithyrambiques, on a l'impression de lire des plaquettes commerciales : pas vraiment de quoi rassurer sur la maturité du langage. Donc si vous avez des retours d'expérience plus nuancés sur la base d'une utilisation sérieuse je suis preneur !

Ceci étant dit, j'aimerais conclure ce message un peu "douche froide" par ce qui est pour moi l'essentiel : le fait d'aimer un langage est une raison suffisante pour pratiquer ce langage. J'ai mis plusieurs années à comprendre que l'affinité qu'on peut avoir avec un langage n'est pas quelque chose de rationnel, mais relève plutôt du goût et des couleurs. Partant de là, y'a pas à rationaliser pourquoi on préfère ce langage. Car chaque langage capture une certaine façon de penser les choses, et quand on est se découvre en phase avec l'une d'elle alors y'a juste à se laisser porter afin de d'explorer tout ce qu'il y a à découvrir avec cette façon de faire. On en retire forcément quelque chose. Et à y réfléchir, c'est quand même plus sympa de choisir un langage sur un coup de coeur !

J'attends vos réactions en espérant avoir blessé personne

[Uther]

J'attends vos réactions en espérant avoir blessé personne

Bien au contraire, la vocation d'un langage n'est pas d'être utilisé par tout le monde pour tout les usage. Il n'y a pas de raison de se sentir blessé par une critique constructive d'un langage : on parle d'un outil pas d'une personne de sa famille.

Votre analyse est très pertinente. Je vais forcément répondre aux points ou j'ai des choses a redire, mais je tiens à préciser que je la partage globalement.

le langage D en particulier, qu'il a à mon avis tué

Je ne suis pas sur que Rust ait vraiment tué D. Malgré sa plus longue histoire, D n'a jamais réussi à percer. La niche qu'il visait en priorité, celle du langage compilé relativement performant mais qui fait quelque concessions pour la simplicité (notamment le GC), a surtout été prise par le Go.

Et à mon avis c'est lié au segment sur lequel on le positionne presque systématiquement : la sécurité. Et c'est pas vraiment le plus porteur. Pour rappel les discussions sur la sécurité ne sont pas nouvelles : PASCAL se vantait d'être beaucoup plus secure que le C, et puis au final nos composants système les plus critiques (OS, drivers...) sont écrits en C... tandis que PASCAL n'est plus... De plus - et c'est pas un détail - il existe des solutions logicielles pour fiabiliser des programmes en C et C++. Le hic est qu'elles sont souvent payantes, à vil prix. Mais pour les structures qui ont ces besoin c'est acceptable. Et pour les domaines où ça ne suffit pas, genre l'aérospatiale, les personnes concernées avec qui j'ai pu en discuter ne juraient en général que par ADA, ou alors des solutions style Frama-C.

Je suis assez d'accord que le positionnement sur la sécurité dans la communication autour de Rust à ses limites. Ça a l'avantage de le présenter sous son coté le plus singulier, le système d'ownership intégré au langage étant sans vrai équivalent dans les autres langages. Mais il est vrai que c'est aussi un problème car ce n'est pas la préoccupation principale de la majorité des développeurs.

Il semble d'ailleurs que les créateurs de Rust essaient de plus en plus à mettre en valeur les avantages de Rust au delà de la sécurité. Réduire Rust à la sécurité, c'est réducteur (désolé du pléonasme). Il a beaucoup d'autres avantages par rapport a certains de ces concurrents dans la programmation système, même s'ils sont moins singuliers. On a par exemple une très bonne gestion des dépendances, le pattern matching, ...
Du plus, en dehors de la gestion de la sécurité mémoire, il est globalement bien plus simple que le C++ (modularité, constructeurs, héritage,...)

Donc pour moi Rust a un peu le cul entre deux chaises : pour les environnements critiques genre aérospatiale, il est face à plus qualifié que lui.

Ada a des avantages indéniables par rapport à Rust a niveau de la sécurisation en général notamment au niveau de la validation des paramètres bien qu'il ne couvre pas non plus tout ce qui est couvert par Rust au niveau de la sécurité mémoire.
Misra-C, à surtout l'avantage d'être un standard bien défini, mais au final c'est juste des règles d'utilisation du C, pas un langage en soi. Ça revient d'ailleurs en bonne partie à demander au programmeur d'éviter lui même des choses que Rust empêche complètement de par sa nature. Un Misra-Rust serait aussi utile.

Après ça ne me choque pas de voir que Rust n'est pas encore adopté dans ces domaines, ils ne travaillent pas aux mêmes échelles de temps que le reste de l'informatique. Le gros problème de Rust pour les environnements critiques, c'est surtout qu'il est jeune et continue d'évoluer dans un domaine par essence très conservateur. Il y a un effort en cours qui vise a produire une version de Rust plus stable et mieux spécifiée dédiée aux environnements critiques, mais tout ça prend du temps.

Enfin, pour qui essaye de suivre l'intégration de Rust dans Firefox, Mozilla n'envoie pas des signaux très positifs. Pour moi là ils ont clairement merdé quand leur comm. Ca a pris beaucoup plus de temps qu'annoncé, l'effet "silver bullet" tant vanté n'a pas vraiment eu lieu, et aujourd'hui le navigateur est en sérieuse difficulté face à ses concurrents intégralement propulsés en C++ : pas de quoi rassurer un décideur.

Sur le cas de Firefox je n'ai pas du tout la même vision, vous pourriez être plus précis sur ce qui vous donne cette impression. Mozilla n'a jamais annoncé qu'il allait remplacer totalement C++, encore moins promis de délai. Ils ont juste intégrés des briques en Rust en remplacement de certaines partie du moteur. L’intégration de Rust dans Gecko s'est quand me relativement bien passée et donne plutôt satisfaction, même si l'introduction d'un nouveau langage donne forcément du travail.
Quant à la difficulté de Firefox en terme de part de marché, c'est difficile de la rattacher à Rust. C'est surtout du a l'omniprésence de Chrome. Firefox était en difficultés en terme de part de marché, comme tous les concurrents de Chrome, bien avant le choix d'intégrer du code en Rust. C'est le dernier gros moteur web fonctionnel qui n'est pas dérivé de Webkit. Même Microsoft a jeté l'éponge avec son moteur qui était pourtant lui aussi en pur C++.

[Invité]

Hello

Je profite de ce topic pour partager mon point de vue et recueillir le vôtre...

Salut, Merci pour ce retour. Je suis assez d'accord avec tes analyses.

Pour moi, un autre point qui joue contre Rust, c'est sa communauté apparente. Avant de me faire lyncher, je précise que c'est mon ressenti personnel et que c'est souvent le cas dès qu'un langage apparait, ce n'est pas spécifique à Rust. Je code très peu en Rust mais je connais quelques personnes qui en font régulièrement. Certains l'utilisent comme un outil et c'est généralement très intéressant de discuter avec eux. Mais il y a aussi pas mal de fanboys qui vendent du rêve pas toujours justifié.

Juste comme ça, je veux bien croire que Rust a probablement le meilleur support de wasm mais il faudrait m'expliquer en quoi il est meilleur que Emscripten. De même, pourquoi un OS en Rust c'est une démonstration probante alors qu'un OS en Lisp c'est a priori louche ? Quant à la gestion mémoire forcément correcte en Rust alors que C++ ne garantit rien, il faudrait quand même rappeler que ça vient au prix d'un effort d'apprentissage, que ça ne corrige pas magiquement les sections unsafe, et surtout il faudrait préciser de quel C++ on parle car il y a une différence entre le C++85 et le C++20. Et aussi arrêter de croire que dès qu'on pose une question sur Rust, on est forcément un vieux dev C++ qui a peur d'avoir à évoluer.

[Uther]

Juste comme ça, je veux bien croire que Rust a probablement le meilleur support de wasm mais il faudrait m'expliquer en quoi il est meilleur que Emscripten.

Tout d’abord, c'est très simple d'accès car intégré directement à la suite de compilation. Le backend wasm est installable, soit avec emscripten (et sa couche de compatibilité avec la libc) ou sans (plus léger) en une ligne de commande, aussi facilement que celui pour x86,x86_64, ou arm.
Ensuite il y a l'outil wasm-bindgen qui permet au code Rust d'interagir de manière très simple et naturelle avec le code JavaScript et les API Web.
Enfin c'est pas lié au langage lui même mais Rust une assez grosse communauté qui travaille sur des projets WASM.

De même, pourquoi un OS en Rust c'est une démonstration probante alors qu'un OS en Lisp c'est a priori louche ?

A part le fait d'être écris en Rust, Redox n'a rien de particulier a signaler par rapport a un OS classique écris dans un langage de bas niveau. Le compilateur Rust fait plus de vérification que le C avant de générer le code, mais les exécutables produits sont similaires.

Un OS en Lisp me parait plus louche parce que, même si je suis pas un expert du langage, il me semble qu'il a besoin d'un interpréteur pour fonctionner. Si l'OS est totalement écrit en Lisp, y compris le kernel, ça voudrait dire que l'interpréteur est au cœur de l'OS, en ring 0, ce qui est atypique et a probablement des impacts lourds.
En tant qu’exploit technique, c'est très intéressant, mais je doute qu'on puisse arriver à quelque chose de performant et fiable en restant sur cette base. Je suis très curieux de savoir comment ils gèrent le matériel en LISP, qui à ma connaissance n'est pas adapté pour ça.

Pour info, il existe un projet d'OS, qui vise à fonctionner intégralement avec une VM WebAssembly en Ring 0. Il a beau être écris en Rust, ce projet me parait encore plus louche qu'un OS en Lisp, bien que là aussi j'apprécie l'originalité de la démarche.

Quant à la gestion mémoire forcément correcte en Rust alors que C++ ne garantit rien, il faudrait quand même rappeler que ça vient au prix d'un effort d'apprentissage, que ça ne corrige pas magiquement les sections unsafe, et surtout il faudrait préciser de quel C++ on parle car il y a une différence entre le C++85 et le C++20.

L'effort d'apprentissage supplémentaire du Rust est réel par rapport a des langages comme Go ou Java, où le Garbage Collector résout la plupart des soucis sans avoir a se poser de question.
Mais en comparaison à C++ il est a relativiser. Apprendre a faire du C++ moderne de manière sécurisée, nécessitera le même d'effort d'apprentissage.

Et aussi arrêter de croire que dès qu'on pose une question sur Rust, on est forcément un vieux dev C++ qui a peur d'avoir à évoluer.

Vu que je me sens un peu visé, bien que j'ai essayé d'être on ne peu plus clair là dessus : Je ne considère pas les développeurs C++ comme des vieux aigris. Je suis juste surpris que certaines remarques à propos du Rust laissent sous-entendre une peur du "grand remplacement".
L'intérêt de Rust en fonction des situations doit bien sur être discuté (comme toute technologie), et le C++ n'est pas près de disparaître.

[Invité]

Un OS en Lisp me parait plus louche parce que, même si je suis pas un expert du langage, il me semble qu'il a besoin d'un interpréteur pour fonctionner. Si l'OS est totalement écrit en Lisp, y compris le kernel, ça voudrait dire que l'interpréteur est au cœur de l'OS en ring 0, ce qui est atypique et a probablement des impacts lourds...

Je ne suis pas un expert lisp non plus mais SBCL est capable de compiler du code et a des performances plutôt correctes (entre 1.1 et 6.8 fois C++ si on en croit le classique benchmark qui ne prouve rien mais que tout le monde cite https://benchmarksgame-team.pages.de.../sbcl-gpp.html). Après je suis d'accord que c'est juste un proto et que ça ne va pas concurrencer linux, c'était juste pour nuancer la remarque comme quoi faire un OS avec autre chose que du C serait un exploit.

Pour le reste, merci pour les infos, je suis assez d'accord avec toi, en fait.

[Kulvar]

Mon gros problème avec Rust, c'est que je trouve sa syntaxe dégueulasse.

J'ai essayé d'apprendre le langage, mais je trouve la syntaxe à gerber.

[Uther]

Il y a une grosse part d'habitude dans le ressenti de la syntaxe d'un langage. Au début avec l'habitude du Java / C++, le langage Rust me paraissait bizarre sur certains points. Maintenant, c'est vraiment le C++ que je trouve mal fichu par rapport au Rust.