Rust, une alternative fiable?

Bonsoir à tous, Voilà plusieurs mois que je prospecte sur internet dans le but de me trouver un langage à apprendre et à étudier de fond en comble, en apprendre les arcanes: en somme un projet à long terme. Il y a quelques jours, suite au post de Dominus carnufex sur le Rust, mon intérêt pour ce langage se raviva : en effet, je vais être amené a faire de la programmation système et des drivers (réseaux notamment) et j'en avais marre de voir le couple C/ C++ revenir encore et encore. Mon interrogation fut la suivante: le Rust, selon vous, peut-il présenter un successeur un concurrent une alternative viable à long terme au C++ et est-il adapté à l'utilisation que j aimerai faire ? J'ai déjà commencé à m intéressé au Rust et j aime beaucoup sa philosophie sécurité et proche de la machine.

Oui.

Merci bien de cette réponse cela me réconforte dans mon opinion même si je trouve l apprentissage de ce langage assez compliqué

Boire ou conduire, il faut choisir.

Bon je suppose que si personne n a de conseils / remarques constructives, je vais clore ce sujet …

Tu as posé une question extrêmement générale. Nécessairement, tu obtiens une réponse très générale. Si tu as des questions plus précises, on se fera un plaisir d’y répondre, mais encore faut-il les poser.

Qui plus est se plaindre de ne pas avoir réponses au bout de 11h en ayant posté vers minuit. Les gens dorment de temps en temps. De patience, faire preuve tu dois. Et je rejoins l'avis de Dominus: essaye d'être plus précis dans tes questions.

Je ne plains pas ^^. J'ai juste compris que ma question ne méritait pas de meilleure réponse que "oui" et que je fus en tort de la formuler comme cela. Donc ma question est résolue et tant pis pour moi si ce n'est pas la réponse que j'attendais

Bon déjà Rust a un système de FFI qui marche bien, cf l'article de Dominus Carnufex qui vient d'être retiré de la bêta. C'est bien pour s'interfacer avec du C, et tu peux faire des trucs bas-niveau aussi. En plus, le système de types de Rust t'empêche de créer des race conditions sur des accès à des variables, de causer des erreurs de segmentation partout, et puis c'est agréable à écrire je trouve. Il y a des types très utiles pour gérer les erreurs (Option<T>). Le compilateur a des messages d'erreurs absolument géniaux et te propose même de les expliquer (rustc --explain). Les outils de Rust sont pratiques: Cargo gère ta compilation pour toi, mais aussi les paquets (ce qu'on appelle des crates en Rust). Je vais pas tout détailler mais Rust est clairement mon langage favori, entre autres pour ses emprunts au fonctionnel.

Le bouquin est bien fait. Jette un oeil, notamment aux parties sur la FFI et les blocs unsafe. C'est tout à fait adapté à ce que tu veux en faire (et même prévu pour).

Vas-y sans hésiter, Rust c'est cool.

Et d'ailleurs, peut-on considéré le rust comme un langage relativement bas niveau? Au moins du niveau d abstraction du C++? Sinon effectivement le compilateur est génial parce qu'il ne laisse absolument rien passer.

Ben tu peux faire les deux: tout ce que tu peux faire en C tu peux le faire en Rust (quitte à mettre des blocs unsafe pour montrer au compilateur que c'est sale et qu'il faut pas être aussi strict dans le bloc) mais tu peux aussi faire des trucs haut niveau (il y a de l'OO par exemple, des itérateurs, etc etc). L'idée c'est d'écrire tes bouts de code sales quelque part puis bâtir des abstractions se reposant dessus pour simplifier l'usage.

tant pis pour moi si ce n'est pas la réponse que j'attendais

Tu aurais préféré « Non » ?

Bon, sérieusement, je suis beaucoup plus sceptique que les fans de Rust sur sa capacité à remplacer le C++ ou le python (sisi, je l'ai lu celle-là ; pour python, je ne crois pas une seconde qu'il soit sur le même segment que Rust). Je dirai en gros qu'il fait avoir un petit bagage fonctionnel à cause de certains mécanismes sous-jacents (les options, par exemple) et que pas mal de refléxes d'autres langages ne marchent pas en Rust ce qui complique pas mal son apprentissage. J'ai un peu de mal à voir précisément quels marchés Rust vise, mais la jeunesse du langage est surement en cause.

Malgré cela, la programmation système fait probablement parti des domaines dans lesquels Rust apporte un vrai plus, et a des chances de percer.

Vas-y sans hésiter, Rust c'est cool.

Moi, j'ai vite déchanté.

Tu as fait quoi pour déchanter ?

Remplacer Python je suis d'accord que c'est pas du tout le même créneau, mais pour moi c'est exactement celui du C++. Pour ce qui est du fonctionnel, je suis pas d'accord: tout est expliqué dans la doc' dans la partie sur la gestion des erreurs, et même si un programmeur fonctionnel reconnaîtra Option<T> comme étant une monade et un foncteur, les autres comprendront facilement à quoi correspond and_then() et map. Il ne faut pas exagérer non plus.

Je te concède qu'il y a une courbe d'apprentissage et qu'il faut s'adapter, mais franchement je trouve que le jeu en vaut la chandelle.

(ceci dit, en tant qu'amateur de fonctionnel, je suis déçu par certains aspects de Rust comme l'absence de HKT)

Pour quelles raisons as-tu vite déchanté? Et qu'est-ce exactement que la programmation système, j'ai cru comprendre que cela s opposait a la programmation logicielle et qu'elle ne traite pas des données: elle consiste à créer des kernel et des modules pour les systèmes d'exploitation ou c'est tout à fait différent?

Les raisons de mon désenchantement sont là, et un échange que j'avais trouvé intéressant continue jusqu'à message d'Eusèbe de la page suivante.

J'avais écrit cela en étant un peu frustré, mais l'idée est là. Pour ma part, n'ayant pas fait de fonctionnel à l'époque, la pente était trop rude. J'ai aussi l'impression que la rudesse de la courbe d’apprentissage est au mieux négligée, au pire niée, par la communauté.

En lisant ton explication j'ai eu l'impression que tu n'avais pas bien lu la doc', en particulier la partie sur la gestion des erreurs (pour autant qu'elle ait existé à l'époque), et que tu as grillé les étapes.

Rust a une courbe d'apprentissage plutôt élevée alors forcément griller les étapes est une très mauvaise idée.

J'espère bien qu'en 10 mois la doc a évolué… J'étais parti sur le tuto officiel de l'époque, et le coup des Options, c'était pas clair. Si je me suis fait avoir, je ne serais pas le seul.

À l'heure actuel, je ne recommande pas Rust pour ceux qui n'ont pas déjà un bon bagage en programmation. Et j'attends de voir comment évolue sa communauté. Mais je crains que la difficulté d'apprentissage soit un frein majeur à l'adoption de Rust.

Bah regarde la documentation et dis-nous ce que tu penses ? L'actuelle est bien je trouve mais c'est vrai que Rust demande des connaissances préalables.

J'ai regarder rapidement, typiquement, la page de vec. La langage pousse à fond le patern matching quand on utilise des vecteurs, mais cela n'apparait pas directement dans la doc. Ni dans la partie vecteur du Book. Il faut aller dans la doc de Option. Lors de l'apprentissage, c'est pas terrible, et même lors de l'usage, je pense.

Les autres critiques que je faisais étaient que je trouve bizarre d'être si rigide quand on fait un pop et aussi laxiste que les autres langages quand on récupère un élément directement (avec les crochets). Problème de cohérence. Ainsi que les messages d'erreur du compilateur complètement illisibles à l'époque (liée à la jeunesse du langage) – toi tu les dis géniaux, donc j'imagine qu'ils ont fait de gros progrès.

Je dirai que Rust a du potentiel. On verra ce que ça donne.

Je pense sincèrement que n’importe quel langage demande un bagage préalable si tu n’as pas un cours qui te prend par la main pour l’apprendre (ce que le book de Rust n’est pas, on est bien d’accord). C’est bien pour ça que le SdZ avait été créé à l’époque. Et quel que soit le langage, il n’y a pas grand chose à attendre des créateurs du langage : par exemple, ce n’est pas Peyton-Jones qui a écrit Learn You a Haskell…

Maintenant, il est évident qu’avoir un bagage en programmation fonctionnelle aide pour apprendre Rust. Mais je ne pense pas que la programmation fonctionnelle en soi rende l’apprentissage du langage plus facile qu’un bagage en POO. Je m’explique.

Rust est très loin d’être un langage fonctionnel. Même s’il en utilise des bouts, comme le type Option ou le filtrage par motifs, sur de nombreux aspects, les réflexes de la programmation fonctionnelle n’y sont pas applicables, entre autres pour les raisons suivantes.

• Il n’y a pas de HKT et au rythme où ça avance, je doute qu’il y en ait un jour.
• Il n’existe pas d’interface unique permettant de passer des fonctions en argument ou en valeur de retour (y’en a quatre différentes, quand même…).
• Ces deux points transforment en calvaire la création de toute monade digne de ce nom.
• Le système de fonctions constantes est absolument moisi, même s’il y a plus d’espoir de le voir devenir quelque chose de correct que pour les HKT.
• La programmation idiomatique utilise généralement des boucles sur des itérateurs plutôt que des map ou de la récursion.

Tout ça pour dire que quelqu’un qui ne connaîtrait que la programmation fonctionnelle s’en prendrait plein la gueule avec le système d’objets, aussi rudimentaire soit-il, l’absence de tout un tas de trucs pratiques, les itérateurs, etc. Toutes choses qui ne poseront aucune difficulté à qui vient du monde OO.

Ce qu’il se passe, c’est que sauf rares exceptions, les gens qui ont un bagage en programmation fonctionnelle ont aussi un bagage dans un paradigme plus courant.

Les autres critiques que je faisais étaient que je trouve bizarre d'être si rigide quand on fait un pop et aussi laxiste que les autres langages quand on récupère un élément directement (avec les crochets).

Je ne vois pas ce qu’il y a de si bizarre, en fait. Il n’y a pas de types dépendants en Rust : le type donne juste une indication de type et ne contient aucune information sur les données effectivement contenues. Comme ce n’est sans doute pas très clair, prenons un exemple.

Le type Vec<T> se contente de dire « ceci est une collection qui peut contenir des objets de type T ». Et les fonctions d’accès, que ce soit [] ou get prennent en entrée « une collection qui peut contenir des objets de type T ».

Si on avait des types dépendants, on pourrait définir un truc comme Vec<T, N ∈ ℕ>, soit « une collection qui prend un nombre entier positif ou nul d’objets de type T ». Et un vec![1, 2, 19] aurait pour type Vec<i64, 3>. Et surtout, la fonction pop aurait pour type Vec<T, N ∈ ℕ*> -> (Vec<T, N-1>, T). Et il deviendrait alors impossible de passer un vecteur vide à la fonction.

Sauf erreur de ma part, ce genre de choses est possible en Idris, par exemple. Mais on voit bien que si on combine ça avec de la mutabilité, ça commence à devenir vraiment sale…

Du coup, dans la mesure où le système de typage ne permet pas en soi d’interdire de passer à la fonction un objet du bon type mais contenant les mauvaises données, et qu’il n’y a aucune intention de le faire, eh ben on laisse au programmeur sa responsabilité. Tu as ainsi un accesseur rapide mais risqué [] et un accesseur plus lent mais sans risque get.

Ainsi que les messages d'erreur du compilateur complètement illisibles à l'époque (liée à la jeunesse du langage) – toi tu les dis géniaux, donc j'imagine qu'ils ont fait de gros progrès.

Vu ce que tu décris dans ton message d’origine, les messages d’erreurs sont toujours les mêmes plus ou moins. Là où on n’est pas d’accord, c’est quand tu dis qu’ils sont illisibles. Le message d’erreur que tu as rencontré pointait exactement le problème rencontré, dès la première ligne, et avec une formulation qui ne laissait aucune place au doute :

Le trait Display n’est pas implémenté pour le type Option.

Je conçois qu’étant nouveau, on puisse ne pas connaître le trait Display, voire le type Option (encore que, comme le pointait Eusèbe, si tu utilises une fonction qui renvoie un type Option sans te renseigner sur ce que c’est, c’est toi le fautif…).

Mais alors, tu cherches dans la doc ce que c’est que ce Display. Dont l’explication n’est pas très claire, on est d’accord, mais qui redirige immédiatement vers cette page où tout est expliqué en détail et, a minima, tu comprendras qu’il y a un problème avec l’affichage.

Maintenant, on ne peut pas vraiment faire mieux comme message d’erreur.

• La fonction Vec::pop() renvoie un Option, c’est prévu pour et parfaitement légal.
• Rien ne t’oblige à déstructurer ton Option, tu peux parfaitement continuer à travailler directement dessus, il n’y a donc aucune raison que le compilateur râle à ce sujet.
• Il est parfaitement légal de passer n’importe quelle variable à la macro println!(), ne serait-ce que parce que les macros ne vérifient pas les types (même si on l’utilise comme une fonction, il faut voir ça plus comme une macro C qui va te remplacer ça par un bloc dégueulasse chargé du formatage et de l’affichage).
• La fonction chargée de réaliser le formatage dans le cas général n’existe pas pour Option → erreur, et message lié.