Les d�tracteurs du Rust s�unissent autour de l�initiative Fil-C : Un impl�mentation s�curis�e du C

C'est une compilation avec des bound checks et un garbage collector. �a va pas plaire � tout le monde. En plus il faut modifier un peu les sources.

A toujours �tre assister on perd en comp�tence ! �� c'est un paradigme

Que pensez-vous de cette multiplication d�impl�mentations dites s�curis�es du langage C ?

Je ne suis pas contre, on a plusieurs id�e explor�e tel que "rustiser" C++ (je n'ai plus le nom du projet), ici ajouter un GC et des bound check ou encore (je ne suis pas vraiment s�r de �a) ajouter une notion d'ownership avec Zig. Peut-�tre que qu'une id�e novatrice s'imposera, ou peut �tre que l'on aura un �ni�me langage. La plus grosse contrainte est la compatibilit� avec l'existant et je ne pense pas qu'il y a de solution miracle.

Pourquoi le langage C pourrait encore avoir de longues ann�es devant lui ? Simple r�sistance au changement ?

Tout simplement parce qu'il y a une �norme base de code en C, tout transcripter en un langage � m�moire s�re demandera beaucoup de temps donc d'argent. Ajoutons aussi que la simplicit� de C permet aussi d'�crire "facilement" un compilateur pour une plateforme personnalis�e. C ne nous quittera pas de sit�t n'en d�plaise � ses d�tracteurs.

Le C a-t-il vraiment besoin d�un rempla�ant en mati�re de programmation syst�me ?

Je dirai que oui, les cyberattaques sont de plus en plus sophistiqu�es, une petite erreur simple peut permettre un contr�le � distance et garantir qu'une �norme base de code sera 100% safe demande un temps monstrueux (amusez � faire de la preuve formelle avec coq sur absolument tout un programme, je suis presque s�r que �a sera plus long que de r��crire le code en un langage � m�moire s�re). On peut aussi compter le temps perdu pour d�bugguer un probl�me m�moire.
Ce n'est que mon avis, mais il faut un langage � m�moire s�r qui ne sacrifie pas significativement les performances. D'une part, cela garanti une absence de type de faille de facto, d'autre part, cela am�liorera la productivit� et permettra de se focaliser plus sur les aspects de logique et moins sur de la technique.

Le probl�me avec le C n�est-il pas plut�t le mauvais usage que certains d�veloppeurs en font ?

Est-ce de la faute du d�veloppeur de ne pas avoir pr�vu tous les cas possible et impossible ? Est-ce de la faute du manager d'avoir mit une deadline qui a r�duit les campagnes de test ? Est-ce la faute de ces grandes entreprises qui font des b�n�fices �normes sur les communaut�s libre et open source sans pour autant investir dans celle-ci pour am�liorer le code ? Est-ce la faute du langage qui permet de se tire une balle dans le pied ?
La r�ponse est: un langage, c'est un choix technique et comme tout choix technique il y a des avantages et des inconv�nients. Choisir le C c'est avoir de tr�s bonne performance au prix de devoir g�rer la m�moire soit m�me et les risque accrus d'un plantage ou de faille de s�curit�. Je ne bl�merais ni les dev, ni le langage si leur programme plante tous les vendredi 13, soir de pleine lune lorsque tous les astres du syst�mes solaires sont align�s.

Envoy� par vivid

A toujours �tre assister on perd en comp�tence ! �� c'est un paradigme

[Troll]
Tu as raison, les IDE avec leurs suggestions automatiques et leur autres fioritures, les smart pointer, les class, les struct, les biblioth�ques, les compilateurs et les �diteurs de lien... Que d'�l�ments qui nous obscurcissent de la vrai connaissance de la programmation ! Les vrais dev, eux ils font tout en assembleur et leur programmes marchent sans probl�me quelque soit l'ordinateur ou le temps
[/Troll]

Il faut savoir o� mettre son cheval de bataille. Le temps passer � s'assurer que toutes les possibilit�s soient correctement traiter est de la productivit� de perdu. Si l'on peut gagner en productivit� et en stabilit� tout en conservant les performances, pourquoi devrions refuser d'�tre assister ? Pour la beaut� du geste ?
Attention, je ne dis pas qu'il ne faut pas savoir comment �a marche derri�re, rien n'est magique et l'obscurantisme m�nent � la d�pendance. Je dis juste que rejeter toute assistance est idiot. Si le borrow checker de Rust me dit qu'il y a un risque d'un double emprunt, c'est pas lui qui � mal compris mon code, c'est moi qui n'a pas vu le cas o� �a pourrait si produire. L'humain aussi assidu puisse t-il �tre ne sera jamais infaillible. Avoir l'assistance d'un programme l'aide � �viter des erreurs

Envoy� par vivid

A toujours �tre assister on perd en comp�tence ! �� c'est un paradigme

Rassure toi, les r�gles d'emprunt, et les mani�res de faire avec de Rust n�cessitent des comp�tences. M�me si le compilateur est assez didactique dans son assistance.

Envoy� par NotABread

Je ne suis pas contre, on a plusieurs id�e explor�e tel que "rustiser" C++ (je n'ai plus le nom du projet), ici ajouter un GC et des bound check ou encore (je ne suis pas vraiment s�r de �a) ajouter une notion d'ownership avec Zig. Peut-�tre que qu'une id�e novatrice s'imposera, ou peut �tre que l'on aura un �ni�me langage. La plus grosse contrainte est la compatibilit� avec l'existant et je ne pense pas qu'il y a de solution miracle.

Mais est-ce vraiment n�cessaire de multiplier � outrance les langages ? L'int�r�t d'un langage est aujourd'hui autant dans les qualit�s intrins�ques que dans l'�cosyst�me autour (� commencer pour le c�t� batteries included). Le c�t� r�v�lateur est marqu� par les gestionnaires de packages qui permettent une fluidit� dans l'acc�s � cet �cosyst�me (Pip pour Python, Maven pour Java, Nuget pour C#, Cargo pour Rust, vcpkg pour C/C++/MSVC, Opam pour OCaml, Alire pour Ada, etc...).

Actuellement, on a des langages �volu�s, mais n�anmoins avec des impl�mentations proches du mat�riels (Rust, Ada, Zig, D...). Ada est peut-�tre un des rares langages avec des types entiers born�s (comme range 1..10). L'avantage est que si une variable a ce type, inutile de tester les limites d'un tableaux de type array (range 1..10) of Integer. Un for I in Tableau'Range loop Tableau(I) := Tableau(I)*2; end loop; peut �tre compil� sans aucune v�rification de bornes (sauf le *2... si on d�passe la capacit� des Integer !! NB: Il y a des types sans v�rifications de bornes), mais aussi sans aucun risque de s�curit�. Par ailleurs, il existe des langages moins proches du mat�riels utilis�s aussi dans des applications similaires (le projet MirageOS vise � proposer un Unikernel en OCaml).

Quand � ajouter � C/C++ un GC et des bound check, c'est peut-�tre ce qui est fait avec C# dans une certaine mesure. (M�me si l'arithm�tique des pointeurs y est autoris� uniquement pour des blocs unsafe).

Envoy� par floyer

Mais est-ce vraiment n�cessaire de multiplier � outrance les langages ? L'int�r�t d'un langage est aujourd'hui autant dans les qualit�s intrins�ques que dans l'�cosyst�me autour (� commencer pour le c�t� batteries included). Le c�t� r�v�lateur est marqu� par les gestionnaires de packages qui permettent une fluidit� dans l'acc�s � cet �cosyst�me (Pip pour Python, Maven pour Java, Nuget pour C#, Cargo pour Rust, vcpkg pour C/C++/MSVC, Opam pour OCaml, Alire pour Ada, etc...).

J'ai envie de dire oui et non. Non car multiplier le nombre de langage disperse des ressources qui pourrait �tre mutualiser pour faire un bon langage plut�t que 20 moyen ou exp�rimentale. Oui car ces nouveaux langages ou extensions de langage cherche � r�pondre � un probl�me qui n'a pas de solution satisfaisante (ou pas totalement), et c'est source d'innovation. Certaines initiatives cherchent m�me � conserver l'acc�s � l'�cosyst�me d�j� �tabli (il me semble que les travaux visant � faire un C++ s�r ont toujours garder une compatibilit� avec le C++ standard).

Oui� quand je vois que Java a mis 8 ans (1996-2004) pour int�grer les g�n�riques. Avec C# c�est arriv� plus tard encore (2005 mais leur V1 date de 2003)� fonctionnalit�s de ML (typage Hindley-Milner en 1978), reprise dans Ada (1983)� ainsi, je veux bien croire et esp�rer que chaque language essaye de se d�marquer en ajoutant un truc en plus, mais � r�inventer la roue, on peine parfois � se mettre � l��tat de l�art pour lequel la barre est de plus en plus haute. Sauf � avoir une bonne expertise (ce qui me semble le cas de ceux qui ont fait Rust).

�a d�pend aussi de la port�e du langage. Haskell avec son c�t� purement fonctionnel et paresseux se d�marque franchement et ouvre une voie de recherche.

Apr�s, il y a des langages (et impl�mentations) construites pour utiliser leur �cosyst�me (Ada avec C qui a des pragma d�di�s et standards, les langages des VM .Net et JVM�). D�autres n�cessitent des bindings en C (JNI avec JVM�).

Pour C++, une biblioth�que STL alternative est peut-�tre le plus simple (de m�moire, Stroutstrup semblait dans un de ses livres mettre en avant les vecteurs que les tableaux).

Par ailleurs, supprimer l�arithm�tique des pointeurs au C++, mettre un GC et cela commence � ressembler � C#.

J'ai �crit plusieurs applications en C et en C++ qui ont pass� tous les test de v�rifications avec succ�s. Aucune fuite et toute la salade avanc�es par les amateurs de Rust. Mais comme ces applications sont �crites en C et C++ et non en Rust elles sont donc dangereuses quoi qu'elles fassent. L'aspect s�curitaire du Rust n'est qu'un d�tail qui ne peut pas remplacer le C ou le C++. D'ailleurs pourquoi pas Ada ou Pascal ? L� aussi ce sont des langages pourris comme le C et le C++ ?

Le Pascal a tout de m�me beaucoup de limitations qui sont compens�s dans l�impl�mentation de Delphi qui supporte entre autres l�objet et les g�n�riques. On est alors assez loin du langage de Niklaus Wirth. C�est presque un Ada avec une autre syntaxe un peu proche, m�me s�il reste beaucoup de diff�rences.

Ada est tr�s novateur avec les t�ches/rendez-vous et g�n�riques d�s 1983, puis l�objet en 1995. D�ailleurs les tableaux Delphi ressemblent aux tableaux Ada en ce sens qu�il incluent leurs bornes (on peut �crire High(Array) pour obtenir la borne max, comme un Array�Last en Ada. C�est une diff�rence majeure avec C/C++ (les tableaux pass�s en param�tre sont de simples pointeurs qui obligent � passer en plus des tailles comme avec strncmp, strncpy� �videmment en C++, on pourrait pr�f�rer les vector)

Le c�t� emb�tant en Ada est la gestion des caract�res� pour avoir un tableau de cha�nes de caract�res de tailles diff�rentes, il faut les convertir en Unbounded_String ce qui alourdi les choses. C�est plus pratique en Delphi.

L� o� Rust se distingue de Delphi et Ada est l�introduction de la programmation fonctionnelle. Typiquement : words.iter().map(|&s| s.to_uppercase()).collect() cela peut �tre assez puissant. C�est le genre de chose introduite avec les stream Java 8. Bon Delphi supporte les fonctions anonymes (lambda fonctions) mais c�est plus lourd et il ne me semble pas qu�il y ait les fonctions usuelles (map, filter�) m�me si on peut les r�impl�menter. Rust d�salloue automatiquement les objets du tas, l� o� c�est manuel en Delphi et Ada. Rust et probablement Delphi supportent les closures, pas Ada.

Concernant cette obsession des fuites et acc�s m�moire il faut tenir compte du fait que les langages ne font qu'emprunter de la m�moire au syst�me d'exploitation. Et de plus ces syst�mes d'exploitation sont d�pendants de l'architecture mat�rielle de la m�moire. A ces conditions on outil malveillant peut acc�der � la m�moire de la machine ce qui n'a rien � voir avec Rust ou C. En C il faut �tre vigilant dans l'�criture des programmes ce n'est pas impossible ni condamn� au manque de s�curit�. Ce qu'apporte Rust aux autres langages est un d�tail qui ne peut pas effacer les autres fonctionnalit�s des autres langages. De plus ce qui est assez �tonnant c'est le haro sur le C et la b�n�diction du Python qui pourtant est impl�ment� en C. Python c'est bien mais le C alors l� le scandale. Rien de meilleur que des biblioth�ques �crites selon l'API en C de Python pour booster les applications Python. Mais c'est vrai que le C est d�routant pour ceux qui n'arrivent � compter jusqu'� 10 en partant de 0 � 9.

Pourquoi parler d�obsession alors que le probl�me des acc�s m�moire est une cause importante de CVE ? (Cf https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33)

Et si, cela a voir avec le langage. En Rust acc�der au 10�me �l�ments d�un tableau de 5 cause une exception alors qu�en C, tu auras des effets de bord (en lecture, l�attaquant peut obtenir des informations confidentielles, en �criture, provoquer un comportement inattendu). Le dernier bug de Crowdstrike est un exemple.
Je ne vois pas o� tu veux en venir avec l�OS et la m�moire physique. La question n�est pas de savoir si on acc�de � de la m�moire physique in fine (forc�ment�) mais si on acc�de aux zones pr�vues. Si tu as un tampon de 64 caract�res pour un mot de passe, une impl�mentation na�ve �crasera de mani�re inattendue les variables apr�s d�s que tu envoies un mot de passe plus long.

Et oui, comme la plupart des programmes complexe Python n�est pas exempt de bug, mais ce logiciel est plus �prouv� que beaucoup de projet (plus de contributeurs). Si bien que tu peux tout de m�me gagner � utiliser Python l� o� il est ad�quat. Nb : en Python, range(10) compte aussi de 0 � 9� ce sont plut�t des langage comme Ada ou Pascal o� tu comptes jusqu�� la borne sup incluse� (le mieux �tant les langages fonctionnels o� des fonctions comme map te dispensent de compter. Python permet d��crire [x*2 for x in l], ce qui dispense d�expliciter une boucle sur les indices de la liste l. En Ada, on �crirait la boucle comme for i in Table�Range loop � ce qui laisse peu de risque d�erreur. Pareil en Rust : for &x in tableau.iter() { �}).

Et sinon, Rust est aussi con�u pour limiter les bug li�s � la programmation concurrente (race condition�)

ca fait 35 ans (j'ai commenc� en 1990, avec Borland et Microsoft) que je fais du C++ (que j'adore), et du C (qui est plus rugeux)
des bugs m�moires en C++, j'en ai vu des tonnes, et je me suis battu avec les templates, les exceptions, le multi-threading, etc...
je sais que ce c'est que de passer des week-ends � d�bugger des fuites m�moires, des segfaults, des deadlocks, etc...

j'ai ensuite fait du C#, Java, et m�me du Python
Il y a quelques mois, je me suis mis � Rust, par curiosit�, et parce que j'avais un outil a coder sous Linux et Windows
Et je dois dire que c'est une sacr�e claque !

Le langage est superbe, la gestion de la m�moire (single owner, borrowing, pas de GC, pas de "delete" � ne pas oublier, etc,) est tellement simple, mais tellement r�volutionnaire!
toutes les rustines ajout�es au fil du temps, dans les diff�rentes versions de C++, font un peu piti� quand on s'int�resse � Rust.
Venant du C++, Rust n'est pas compliqu� � comprendre et apprendre; le plus d�licat (comme souvent), c'est de maitriser les outils (cargo) et de connaitre un minimum de lib (crates)

J'apr�cie aussi que l'environnement vienne avec
* un coding standard (aux oubliettes, les querelles st�riles entre les { sur la meme ligne ou sur la ligne suivante))
* une gestion des tests
* un g�n�rateur de documentation automatique
* un support multiplateforme natif (Linux, Windows, Mac)

bref si vous venez du C++ et que vous voulez apprendre, embarquez-vous dans Rust, vous ne le regretterez pas