Discussion :

[Mathis Lucas]

Brian Kernighan, co-cr�ateur d'Unix, s'exprime apr�s avoir test� le langage Rust : � je ne pense pas qu'il va remplacer C tout de suite �
il juge l��cosyst�me de Rust � incompr�hensiblement vaste et lent �

Brian Kernighan, co-cr�ateur d'Unix, a partag� ses r�flexions sur les langages modernes tels que Rust, les distributions Linux et les descendants d'Unix. Il a soulign� que les solides fonctionnalit�s de s�curit� m�moire de Rust font des vagues dans la communaut�, offrant aux d�veloppeurs un moyen d'�crire du code plus s�r. Toutefois, apr�s l'avoir test�, Brian Kernighan juge l��cosyst�me de Rust � incompr�hensiblement vaste et lent �. Il n'a �crit qu'un seul programme en Rust, mais rapporte une exp�rience p�nible. Son avis contraste avec celui d'autres figures de l'industrie, comme Linus Torvalds, cr�ateur du noyau Linus.

Brian Kernighan, 83 ans, est un informaticien canadien de renom connu pour avoir co�crit le premier livre sur le langage de programmation C (avec Dennis Ritchie). Il est �galement le co-cr�ateur des langages Awk, avec Alfred Aho et Peter Weinberger, et AMPL. Il a travaill� aux Bell Labs et a contribu� au d�veloppement d'Unix aux c�t�s des cr�ateurs d'Unix, Ken Thompson et Dennis Ritchie. Il est aussi connu pour d'autres travaux pionniers dans l'informatique.

En 1969, il obtient un doctorat d'�lectrotechnique � l'universit� de Princeton, o� en 2004, il occupe un poste de professeur. � J'enseigne toujours � Princeton. Je n'ai pas encore pris ma retraite ! �, a-t-il d�clar� r�cemment, devant un public r�uni au InfoAge Science and History Museums de Wall, dans le New Jersey.

Brian Kernighan avait �t� invit� � prendre la parole lors du festival � Vintage Computer East �. Lors de l'�v�nement, il a partag� ses r�flexions sur ce qu'il pense du monde d'aujourd'hui, avec son abandon du langage C au profit de langages de programmation plus s�rs pour la m�moire. Il a mis l'accent sur le langage Rust, qu'il a utilis� pour �crire un programme. Mais alors que Rust jouit d'une popularit� croissant, Brian Kernighan n'a pas du tout �t� s�duit.

Brian Kernighan critique vivement les performances du langage Rust

� Pensez-vous que Rust ait un quelconque int�r�t � remplacer C ? Ou s'agit-il simplement d'un �norme battage m�diatique qui finira par s'essouffler ? �, a demand� un membre du public. Dans un monde qui �volue depuis des ann�es vers des langages plus s�rs pour la m�moire, la r�ponse d'un fervent d�fenseur du langage de programmation C depuis plus d'un demi-si�cle promettait d'�tre tout simplement embl�matique. Il s'est montr� tr�s tr�s critique.

Brian Kernighan a trouv� son exp�rience avec Rust � p�nible �. Selon lui, les m�canismes impos�s par Rust pour garantir la s�curit� m�moire sont trop lourds, surtout dans un programme o� la gestion de la m�moire n��tait pas un probl�me majeur. Il d�crit son unique essai comme � une douleur �, et juge l��cosyst�me du langage � avec ses crates, sa complexit� et la lenteur de la compilation � comme � incompr�hensiblement vaste et lent �.

� Ohhh, Rust �, a d�clar� Brian Kernighan, sous les rires du public. � Je n'ai �crit qu'un seul programme en Rust, vous devez donc prendre tout cela avec beaucoup de recul. Et j'ai trouv� cela p�nible. Je n'arrivais tout simplement pas � comprendre les m�canismes n�cessaires pour assurer la s�curit� de la m�moire, dans un programme o� la m�moire n'�tait m�me pas un probl�me ! �. Sa plus grande critique semble concerner ses performances de Rust.

� Et le compilateur �tait lent, le code qui en ressortait �tait lent... �, a-t-il d�clar�. � Quand j'ai essay� de comprendre ce qui se passait, le langage avait chang� depuis la derni�re fois que quelqu'un avait publi� une description ! Il m'a donc fallu plusieurs jours pour �crire un programme qui, dans d'autres langages, aurait pris peut-�tre cinq minutes... �

Le 15 mai 2025, le compte Twitter officiel du projet FFmpeg a publi� un message acerbe � l'encontre de Rust qui dit : � [Rust] est tellement bon que l'on peut �tre pay� 20 000 $ pour le rendre aussi rapide que C �. Cette remarque visait l'initiative de Prossimo, qui a propos� une prime de 20 000 $ � quiconque parviendrait � rendre son d�codeur AV1, rav1d, aussi rapide que dav1d, une impl�mentation en C largement reconnue pour sa rapidit�.

Cette d�claration a raviv� le d�bat sur les compromis entre s�curit� m�moire, performance et co�t dans le d�veloppement de syst�mes critiques. Il s'agit d'un d�bat de longue date dans la communaut� des d�veloppeurs. Certains ch�rissent les performances brutes, tandis que d'autres pr�f�rent la s�curit�.

Les limites du jugement de Brian Kernighan concernant le langage Rust

Dans l'ensemble, Brian Kernighan avait eu une mauvaise exp�rience. Il reconna�t qu�il n�a �crit qu�un seul programme en Rust et conseille de prendre ses critiques avec prudence. Il pr�cise que son exp�rience reste personnelle et ne doit pas �tre vue comme un rejet d�finitif du langage. Cela dit, il ne consid�re pas Rust comme un rempla�ant du C : � je suis probablement trop cynique. Mais je ne pense pas qu'il va remplacer C tout de suite, en tout cas �.

La position de Brian Kernighan sur Rust contraste avec celle de Linus Torvalds, cr�ateur du noyau Linux. Linus Torvalds est favorable � l'introduction de Rust dans le noyau Linus, ce qui constitue l�un des changements techniques les plus significatifs de ces derni�res ann�es. Le langage de programmation Rust, r�put� pour sa s�curit� m�moire et sa modernit� par rapport au langage C, a suscit� un d�bat tr�s intense parmi des d�veloppeurs du noyau.

Depuis l'annonce de la prise en charge exp�rimentale de Rust dans le noyau Linux, plusieurs mainteneurs ont exprim� des inqui�tudes quant � l'impact de ce changement. Parmi eux, Christoph Hellwig a pris une position ferme contre l'utilisation de Rust, mettant en avant des arguments relatifs � la complexit� et � la fragmentation du d�veloppement du noyau. Les critiques craignent que le m�lange de Rust et du C ne rende Linux impossible � maintenir.

Face aux pr�occupations soulev�es, Linus Torvalds a clarifi� sa position sur Rust. Il a affirm� qu'il n'est pas question d'imposer Rust aux mainteneurs qui ne souhaitent pas travailler avec ce langage. Linus Torvalds a expliqu� que les mainteneurs ne seront pas contraints d'interagir avec du code Rust s'ils n'en voient pas l�utilit�. Cependant, cela ne signifie pas qu'ils ont le droit de bloquer son int�gration dans des domaines o� il est jug� b�n�fique.

Linus Torvalds a pr�cis� que la demande d�int�gration d�un module en Rust, qui �tait � l�origine du d�bat, n�avait aucune incidence directe sur le code existant maintenu par Christoph Hellwig. D�s lors, il n��tait pas justifi� que ce dernier cherche � bloquer l��volution du noyau dans ce sens.

Linus Torvalds a �galement insist� sur un principe fondamental du d�veloppement de Linux : le pragmatisme et la flexibilit�. Selon lui, l'objectif n'est pas d'obliger quiconque � travailler avec Rust, mais de permettre � ceux qui veulent l�utiliser de le faire sans contraintes excessives. L'ann�e derni�re, Linus Torvalds a exprim� sa d�ception face au faible taux d'adoption de Rust, les principaux mainteneurs du noyau �tant plus habitu�s au langage C.

Pourquoi Rust dans le noyau Linux ?

L'adoption de Rust dans le noyau Linux repose sur plusieurs motivations majeures :

• s�curit� m�moire am�lior�e : l�un des principaux atouts de Rust est sa gestion de la m�moire s�curis�e par conception. Contrairement au C, qui repose sur une gestion explicite de la m�moire (et donc sujet � des erreurs comme les d�passements de tampon et les acc�s � des pointeurs invalides), Rust emp�che ces erreurs � la compilation. Cela permet de r�duire la surface d�attaque du noyau, particuli�rement pour les pilotes et modules de bas niveau ;
• fiabilit� et modernit� : Rust introduit des concepts modernes, tels que le syst�me de propri�t� et l�emprunt de m�moire, qui facilitent l��criture de code robuste. Pour un projet aussi critique que le noyau Linux, cela peut se traduire par une r�duction significative des bogues et des failles de s�curit� ;
• un d�veloppement plus modulaire : Rust permet de d�velopper des modules et pilotes isol�s qui peuvent coexister avec du code en C sans n�cessiter une r��criture compl�te du noyau. Cela signifie que les d�veloppeurs peuvent progressivement tester et adopter Rust sans perturber le fonctionnement global de Linux ;
• l�adoption croissante dans l�industrie : de grandes entreprises technologiques, comme Google, Microsoft et Meta, soutiennent l'utilisation de Rust pour des composants critiques de bas niveau. Google, par exemple, a d�j� commenc� � utiliser Rust dans le noyau Android pour renforcer la s�curit�.

Il faut noter que l'adoption de Rust soul�ve des d�fis :

• apprentissage du langage : certains mainteneurs ne sont pas familiers avec Rust, et il faudra du temps pour qu�une partie significative de la communaut� Linux se l�approprie ;
• support des outils et cha�nes de compilation : bien que Rust dispose d�un excellent �cosyst�me, son int�gration au sein des infrastructures existantes du noyau n�cessite un travail suppl�mentaire ;
• �quilibre entre conservatisme et innovation : Linux a toujours �t� un projet o� le pragmatisme prime sur la mode technologique. Torvalds veut s�assurer que Rust apporte une v�ritable valeur ajout�e avant de l��tendre plus largement.

Brian Kernighan revient sur son passage au sein des laboratoires Bell

Au cours de son intervention, Brian Kernighan a �voqu� avec �motion l'ambiance g�n�rale qui r�gnait chez Bell Labs, la qualifiant de coop�rative, coll�giale et agr�able... � C'�tait tr�s agr�able de passer du temps avec ces gens �. Mais il a ajout� qu'apr�s l'arriv�e de Microsoft Windows, � le monde de la technologie avait compl�tement chang� � et que beaucoup d'efforts, d'attention et de talents avaient commenc� � se concentrer sur le monde des PC...

Il se souvient que � les bonnes id�es et les personnes talentueuses se sont en quelque sorte �loign�es, dans une certaine mesure, voire beaucoup, d'Unix �. Et � l'accent �tait beaucoup plus mis sur l'interaction �, car Microsoft fabriquait des produits grand public (qui n'�taient pas destin�s � � une population technique �). Il a toutefois rappel� � l'auditoire que le monde avait ensuite assist� au d�veloppement de Linux, qui perp�tue l'h�ritage d'Unix.

Que pense-t-il donc de la d�mocratisation d'Unix aujourd'hui ? Les utilisateurs de Mac/iPhone utilisent les descendants d'Unix sans m�me le savoir. Le projet s'�loigne ainsi de la philosophie originale libre et open source. � Je pense que vous avez mis le doigt dessus �, a r�pondu Brian Kernighan, � quand vous avez dit que la plupart des gens ne le savent pas... �.

Il a fait remarquer que les iPhone fonctionnent avec une � version d'Unix assez �volu�e �, tandis que les t�l�phones Android fonctionnent avec une version diff�rente de Linux sous-jacente... � De mon point de vue, en tant que personne qui a �t� vaguement impliqu�e dans les d�buts et qui poss�de un t�l�phone, je trouve cela intrigant. Et je trouve aussi assez irritant qu'il y ait en dessous un syst�me avec lequel je pourrais faire des choses, mais auquel je n'ai pas acc�s ! �, a-t-il d�clar�.

Son public a de nouveau ri et applaudi... Un participant a m�me soulign� que � Brian Kernighan a effectivement �t� impliqu� dans le logiciel pendant toute la dur�e de vie du logiciel en tant que produit commercial �. Mais cela signifie aussi qu'il a v�cu pour voir sa commercialisation et sa productisation.

Il a �galement �t� invit� � r�pondre � la question suivante : � avez-vous des commentaires pertinents sur l'�tat actuel des logiciels tels qu'ils existent aujourd'hui... ? � Brian Kernighan a souri malicieusement � tandis que son public riait � nouveau � lorsque l'interlocuteur ajouta : � en dix mots maximum, si possible ! �.

� La plupart sont nuls... ! �, r�pondit-il sous les applaudissements du public. � Malheureusement, c'est tout � fait vrai �. Il a ajout� � l'intention de son interlocuteur : � je pourrais d�velopper, mais peut-�tre hors ligne... �.

Brian Kernighan contre le vibe coding

Au cours de sa pr�sentation, Brian Kernighan a d�clar� que l'un des h�ritages d'Unix r�side dans � les programmes qui �crivent des programmes �. � Un compilateur cr�e un langage d'assemblage... ? C'est un programme qui �crit un programme... Et une fois que vous avez compris le principe, les programmes qui �crivent des programmes font du bon travail. Ils le font souvent mieux que les humains �, a expliqu� l'informaticien.

Mais ensuite, en entendant ses propres mots, il a rapidement ajout� une mise en garde. � Je passerai sur ce qui se passe avec les grands mod�les de langage... � Alors que le public riait, il a poursuivi : � parce que mes quelques tentatives dans ce domaine ont en quelque sorte invalid� ce que je viens de dire ! �.

Avec l'essor d'outils d'IA tels que ChatGPT, il est d�sormais possible de d�crire un programme en langage naturel et de demander au mod�le d'IA de le traduire en code fonctionnel, souvent sans comprendre comment le code fonctionne. Andrej Karpathy, ancien chercheur d'OpenAI, a donn� un nom � cette pratique : le � vibe coding �. Elle gagne du terrain dans les milieux technologiques. Google a m�me d�clar� g�n�rer 25 % de son code par IA.

David Farley pour sa part affirme que le vibe coding est la pire id�e dans l'ing�nierie logicielle en 2025. Dette technique et illusion de productivit� sont des facteurs que le d�veloppeur doit int�grer de fa�on plus aig�e lorsqu�il opte pour l�utilisation de l�IA aux fins de codage. En gros, l�intervention de personnes avec un bagage cons�quent en d�veloppement informatique demeure n�cessaire comme le souligne Cendyne sur Developpez.com :

� Le "Vibe Coding" peut vous permettre d'obtenir un concept fonctionnel � 80 %. Mais pour produire quelque chose de fiable et de s�r, qui vaille la peine de d�penser de l'argent, vous aurez besoin d'humains exp�riment�s pour faire le travail difficile qui n'est pas possible avec les mod�les d'aujourd'hui �.

Alors que la conf�rence touchait � sa fin, quelqu'un a demand� � Brian Kernighan de donner un conseil aux futures g�n�rations de programmeurs. C'est une question � laquelle il a d�j� r�pondu, et sa premi�re r�action a �t� de reconna�tre que � la r�ponse � cette question, la vraie r�ponse, est je ne sais pas �.

Source : Brian Kernighan, cocr�ateur d'Unix

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous du retour d'exp�rience de Brian Kernighan sur le langage Rust ?
Brian Kernighan juge l��cosyst�me de Rust � incompr�hensiblement vaste et lent �. �tes-vous de cet avis ?
Pensez-vous que la complexit� apparente de Rust est un obstacle r�el � son adoption, ou bien seulement une difficult� passag�re pour les nouveaux venus ?
Selon vous, un langage de programmation doit-il viser d�abord la simplicit� d�usage ou la robustesse et la s�curit� ?
L�avis d�un pionnier comme Brian Kernighan a-t-il encore du poids pour juger les langages modernes, ou bien son exp�rience est-elle trop marqu�e par d�autres �poques ?
Selon vous, Rust pourra-t-il un jour remplacer le langage C dans les syst�mes critiques, ou restera-t-il un langage de niche ?
Avez-vous d�j� essay� d�apprendre Rust ? Si oui, quelles difficult�s avez-vous rencontr�es ?
Pr�f�rez-vous travailler avec des langages plus permissifs (comme C, Python) ou plus stricts (comme Rust, Haskell) ?
Que pensez-vous de l'�tat du projet Unix aujourd'hui ?

Voir aussi

Linus Torvalds clarifie sa position concernant l'int�gration du code Rust dans le noyau Linux, affirmant qu'il n'est pas question d'imposer Rust aux mainteneurs qui ne souhaitent pas travailler avec ce langage

Le vibe coding est la pire id�e en 2025, d'apr�s David Farley qui jette un regard sur cette tendance � accepter du code g�n�r� par l'IA, souvent sans le comprendre

FFmpeg : � Rust est tellement bon qu'on peut �tre pay� 20 000 $ pour le rendre aussi rapide que le C �, le framework multim�dia �crit en C r�agi avec sarcasme � une initiative de Prossimo

[fdecode]

Est-il utile de relayer les arguments un peu creux d'une personne illustre qui donne un avis rapide sur un langage auquel il ne s'est visiblement pas int�ress� (une programmation qui aurais d� prendre 5 minutes...) et auquel il n'a pas l'intention de s'int�resser. Il m�rite certainement mieux que �a:

� Je n'ai �crit qu'un seul programme en Rust, vous devez donc prendre tout cela avec beaucoup de recul. Et j'ai trouv� cela p�nible. Je n'arrivais tout simplement pas � comprendre les m�canismes n�cessaires pour assurer la s�curit� de la m�moire, dans un programme o� la m�moire n'�tait m�me pas un probl�me ! �

� Quand j'ai essay� de comprendre ce qui se passait, le langage avait chang� depuis la derni�re fois que quelqu'un avait publi� une description ! Il m'a donc fallu plusieurs jours pour �crire un programme qui, dans d'autres langages, aurait pris peut-�tre cinq minutes... �

Le langage ou un crate? Parce que le langage est plut�t stable d'une version � l'autre... Lors d'un changement d'�dition, il peut y avoir des changements notables, mais m�me l�, la transition reste relativement simple.

[RenarddeFeu]

Le juge de paix, ce sont les utilisateurs qui adopteront ou non le langage. Les qualit�s intrins�ques d'un langage de programmation n'ont jamais �t� gage popularit�. Et a contrario, beaucoup de langages largement utilis�s sont juste horribles.

[OuftiBoy]

Je suis plut�t d'accord avec RenarddeFeu, ce sont les utilisateurs qui choisiront au final. Rust est un langage avec des qualit�s, c'est certains. Mais il n'est d�j� plus tout jeune (il a plus de 10 ans si je ne me trompe). 10 ans, en informatique, c'est long, et cela n'a pas pourtant permit � 'Rust' de s'imposer.

Il gagne en popularit�, mais il a une courbe d'apprentissage qui me semble (ce n'est que mon opinion...) plus ardue, une communaut� ayant un esprit "�litiste" (c'�tait en tout cas mon sentiment lorsque j'ai tent� d'approfondir ma connaissance de Rust), une syntaxe assez "rebutante" (� laquelle on peut certes s'habituer par la pratique, rien d'insurmontable), et utilise des "termes" ou un vocabulaire (comme "crate" par exemple) "d�routant".

Rust est un (tr�s) bon langage, mais tous ces "petits d�tails" (courbe d'apprentissage ardue, communaut� �litiste, syntaxe rebutante, vocabulaire d�routant) sont des freins � son adoption plus "massive". On dirait m�me qu'il fait tout pour ne pas �tre aim�.

Mais ce n'est que mon avis, chacun � le sien, et les utilisateurs (les d�veloppeurs) trancheront.

B�V et Peace & Love.

[fdecode]

Brian Kernighan juge l��cosyst�me de Rust � incompr�hensiblement vaste et lent �. �tes-vous de cet avis ?

En fait il est tr�s simple de compter les composants de la librairie standard Rust.

Les crates qui composent le langage Rust sont: alloc, core, proc_macro, std, test.

Mais pour toute utilisation ordinaire, le langage Rust, c'est essentiellement la librairie standard std:
https://doc.rust-lang.org/stable/std/all.html
soit environ 2000 composants (toutes structures, primitives, traits, macros, fonctions, alias, constantes confondues) publiquement affich�s dans la librairie standard.

Dans les faits, std utilise des composants bas niveaux de core et alloc, mais cela est transparent pour l'utilisateur lambda. Personnellement, je n'utilise jamais core ni alloc.

Si on fait du no_std, on doit passer par le core et alloc:
https://doc.rust-lang.org/stable/core/all.html
https://doc.rust-lang.org/stable/alloc/all.html
alloc comprends � peu pr�s 250 composants et core, quant � lui, est bien plus gros (environ 25000 composants d�finis), car le core met � disposition des impl�mentations bas niveau tr�s sp�cifiques pour diff�rentes architectures mat�rielles. Cela a un effet d�multiplicateur.

Les autres crates du langage Rust, proc_macro, test, ne repr�sentent pas grand chose num�riquement.

Est-ce incompr�hensiblement vaste? Pour �tre honn�te, il faudrait comparer std aux librairies standards C et C++ (core et alloc ne correspondent pas � un usage standard de Rust).
Il me semblait avoir lu que les composants de la librairies standard C se comptaient en centaines et que ceux de C++ �taient autour des 10000. Mais ce serait � confirmer. Pour que les comparaisons se valent, il faudrait compter les composants d�clar�s � l'int�rieur des header...

---

En revanche, pour ce qui est du site de d�p�t crates.io, il y a pr�s de 200000 crates. Mais cela est en dehors de la librairie std ou no_std. N'importe qui peut d�poser un crates sur crates.io...

Pensez-vous que la complexit� apparente de Rust est un obstacle r�el � son adoption, ou bien seulement une difficult� passag�re pour les nouveaux venus ?

J'ai accroch� tout de suite. Mais chaque codeur a ses affinit�s linguistiques.

Selon vous, un langage de programmation doit-il viser d�abord la simplicit� d�usage ou la robustesse et la s�curit� ?

La difficult� dans beaucoup de langages est implicite, alors qu'elle est plut�t explicite en Rust. En ce sens, la question est mal pos�e.
En pratique, j'utilise des IA comme aide pour la programmation C++ (avoir le bon usage des diff�rents standards) et Python (notamment pour maitriser numpy, pytorch et tensorflow). Je n'ai pas besoin de cette aide en Rust. Et l� on parle de chose qui ne concernent pas seulement la s�curit�.

L�avis d�un pionnier comme Brian Kernighan a-t-il encore du poids pour juger les langages modernes, ou bien son exp�rience est-elle trop marqu�e par d�autres �poques ?

Brian Kernighan est plut�t prudent et honn�te dans sa r�ponse. Son jugement et ses conseils ont certainement un int�r�t mais pas sur un sujet qu'il ne connait pas vraiment. Et c'est ce qu'il dit... C'est pour cette raison que je trouve inad�quat des titres comme Brian Kernighan critique vivement les performances du langage Rust.

Selon vous, Rust pourra-t-il un jour remplacer le langage C dans les syst�mes critiques,

Je ne me suis jamais pos� la question en termes de remplacement...

La programmation no_std peut s'appliquer � de la programmation embarqu�e ou � de la programmation syst�me,
https://www.redox-os.org/
https://www.rust-lang.org/what/embedded

en revanche, il faudra certainement aller vers des certifications pour des syst�mes critiques. Il y a en tout cas des actions � ce sujet:
https://rustfoundation.org/safety-cr...st-consortium/

ou restera-t-il un langage de niche ?

De quelle niche parle-t-on?

[Pat2kz]

malgr� les comp�tences ind�niable de ce monsieur qui a grandement contribu� � l'open source, je pense que l�, il est un peu d�pass� !??
il n'a �crit qu'un seul programme et peut d�j� "d�nigrer" Rust ?
rester sur C, C++, Java, etc, c'est une chose, mais heureusement que le langage informatique �volue et on doit aussi �voluer avec, comme la s�curit� de Rust a �t� prouv�e et c'est aussi de ce c�t� qu'on doit se diriger.

[OuftiBoy]

Pat2kz,

malgr� les comp�tences ind�niable de ce monsieur qui a grandement contribu� � l'open source, je pense que l�, il est un peu d�pass� !?? il n'a �crit qu'un seul programme et peut d�j� "d�nigrer" Rust ?

Dans l'article, il dit (je cite) : "Je n'ai �crit qu'un seul programme en Rust, vous devez donc prendre tout cela avec beaucoup de recul". Il est donc bien conscient et exprime son avis sur le sujet avec �norm�ment de pr�caution, et apparemment, cela se d�roulait dans une ambiance "l�g�re", propice a se l�cher un peu.

Je ne suis absolument pas exp�riment� en "Rust", mais bien en "C". Mais j'ai �tudi� la partie "s�curisation de la m�moire" de Rust, et lorsqu'il dit (je cite) : "Et j'ai trouv� cela p�nible. Je n'arrivais tout simplement pas � comprendre les m�canismes n�cessaires pour assurer la s�curit� de la m�moire, dans un programme o� la m�moire n'�tait m�me pas un probl�me !".

Le probl�me qu'il d�nonce, c'est qu'il a eu du mal a comprendre les m�canismes de s�curisation de ma m�moire. Si un d�veloppeur de son niveau n'arrive que difficilement � comprendre ces m�canismes, on peut comprendre que nombres de d�veloppeurs lambda �prouvent eux aussi d'�normes difficult�s avec la compr�hension de ces m�canismes, non ?

Il ajoute (je cite) : "dans un programme o� la m�moire n'�tait m�me pas un probl�me !". Je ne connais pas le programme qu'il a voulu �crire, mais sa parole �tant "rare", j'ai tendance � le croire.

Ayant �tudi� de pr�s ces m�canismes, et m�me si le r�sultat fait ind�niablement de "Rust" un langage plus "secure" qu'un programme en "C", les m�canismes qu'il faut utiliser sont assez "lourds" (ce n'est que mon avis), le concept "d'ownership" montre vite ces "limites", d'o� le "Borrowing" et son indispensable "Borrow Checker". Il faut ajouter � cela le concepts de "Lifetime". Cela fait quand m�me pas mal de concepts a int�grer.

Je pense que cela vient du fait que "Rust" n'a pas voulu trop s'�loigner du C++ (en terme de syntaxe), car son objectif est d'attirer � lui ces d�veloppeurs C++.

rester sur C, C++, Java, etc, c'est une chose, mais heureusement que le langage informatique �volue et on doit aussi �voluer avec, comme la s�curit� de Rust a �t� prouv�e et c'est aussi de ce c�t� qu'on doit se diriger.

� Et le compilateur �tait lent, le code qui en ressortait �tait lent... �, a-t-il d�clar�. � Quand j'ai essay� de comprendre ce qui se passait, le langage avait chang� depuis la derni�re fois que quelqu'un avait publi� une description ! Il m'a donc fallu plusieurs jours pour �crire un programme qui, dans d'autres langages, aurait pris peut-�tre cinq minutes... �.

Je ne sais pas me prononcer, et je suis certains que certains diront que ce sont plus les "libraires" qui �voluent que le langage lui-m�me. Mais "Rust" n'est plus tout jeune non plus, il a une dizaine d'ann�es, et ce "temps" aurait du suffire pour qu'il s'impose face au C++, ce qui ne semble pas �tre le cas.

En fait, il est plus judicieux de comparer "Rust" � "C++" et pas au "C". Ce sont deux types d'outils (Rust et C++) et (le C) qui sont destin�s a r�gler des probl�mes diff�rents, dans des contexte diff�rents.

Perso, AMHA, je ne suis ni pour ni contre, et "comparer" des langages n'a pas pour moi beaucoup de sens. Comme toujours, il faut utiliser le bon outils adapt� au travail a r�aliser.

B�V et Peace & Love.

[fdecode]

Ayant �tudi� de pr�s ces m�canismes, [...] le concept "d'ownership" montre vite ces "limites", d'o� le "Borrowing" et son indispensable "Borrow Checker". Il faut ajouter � cela le concepts de "Lifetime".

Puisque vous avez intens�ment �tudi� ces questions d'ownership, vous savez donc que l�ownership n�est pas une lourdeur invent�e par Rust, mais une r�alit� universelle : dans tout langage, il faut d�cider qui poss�de quoi, combien de temps �a vit, et quand on peut le partager. La diff�rence, c�est que Rust choisit de l�exprimer clairement et de le v�rifier � la compilation, l� o� d�autres laissent le soin au programmeur (C++) ou au GC (Java).

Dans C++, les deux types de r�f�rence T& et T&& permettent respectivement de distinguer entre une r�f�rence � une donn�e du processus appelant et un transfert d'ownership vers l'appel�. Les pointeurs intelligents du C++ sont aussi un moyen de g�rer l'ownership au niveau d'un pointeur compt�.

Le borrowing et les lifetimes sont des outils pour clarifier des cas particuliers (emprunt temporaire, partage, multithreading). C�est vrai qu�il y a une marche d�apprentissage, mais une fois pass�e, on gagne �norm�ment en robustesse et en s�r�nit�.

il a une dizaine d'ann�es, et ce "temps" aurait du suffire pour qu'il s'impose face au C++, ce qui ne semble pas �tre le cas.

C'est une vision fantasm�e des langages de programmation. Compte tenu de la place occup�e par le C++ et le C dans les produits existants, je pense que personne n'a jamais s�rieusement fait l'hypoth�se que Rust pourrait s'imposer face au C++ en 10 ans. D'ailleurs quand on voit que Google (contributeur platinum de la fondation Rust) a offert un financement pour l'interop�rabilit� Rust/C++, cela montre bien que m�me les soutiens de premier plan du langage le voient coexister dans un �cosyst�me avec d'autres langages. Et je partage cette vision.

Je pense que cela vient du fait que "Rust" n'a pas voulu trop s'�loigner du C++ (en terme de syntaxe), car son objectif est d'attirer � lui ces d�veloppeurs C++.

En fait, il est plus judicieux de comparer "Rust" � "C++" et pas au "C".

Rust n�a pas de classes, ce qui l��loigne fondamentalement de la syntaxe de C++. Sa hi�rarchie des types concrets (struct, enum, union, tableaux, primitives, �) reste proche d�une philosophie C, m�me si elle est enrichie de subtilit�s comme les encodages (repr).

Les traits d�finissent une hi�rarchie de comportements (ou de capacit�s), orthogonale � la hi�rarchie des types concrets : ils n�alt�rent pas ces structures simples. On peut former des trait objects, mais il y a toujours un type concret en arri�re-plan.

Rust n�emprunte donc pas l�approche hi�rarchique de C++ (h�ritage de classes qui m�le structure et comportement), mais propose une alternative orthogonale : des traits pour exprimer les comportements, et des g�n�riques pour composer ces comportements. � mes yeux, c�est une approche alternative qui prolonge l�esprit du C : un langage bas niveau, mais cette fois s�curis� et enrichi de concepts objets, sans impact direct sur l�organisation nominale des types concrets.

Cela n�emp�che pas le syst�me de traits, associ� aux g�n�riques et aux macros proc�durales (travaillant sur l�AST), d��tre extr�mement puissant.

Ce sont deux types d'outils (Rust et C++) et (le C) qui sont destin�s a r�gler des probl�mes diff�rents, dans des contexte diff�rents.

Je ne me risquerais pas � d�finir de telles fronti�res. Vous avez du Rust dans Redox-OS -- l�essentiel du code (noyau, pilotes, biblioth�ques, espace utilisateur), � l�exception de quelques routines assembleur tr�s bas niveau et d�un peu de code C dans relibc, soit en cours de transition vers Rust, soit maintenu pour assurer certaines compatibilit�s POSIX -- et il y a �galement de plus en plus de Rust dans Linux.... Je ne fais pas de Rust embarqu�, mais cela aussi s'installe petit � petit.

C'est un petit d�tail, mais ils attirent toujours mon attention: ARM est r�cemment devenu soutien platinum de la Rust Foundation. On a donc d�sormais 6 soutiens platinum � la Rust Foundation : AWS, Google, Meta, Microsoft, Huawei, ARM.
La pr�sence d'un acteur essentiellement mat�riel comme ARM donne une certaine perspective sur les �volutions de Rust.

[OuftiBoy]

fdecode

Puisque vous avez intens�ment �tudi� ces questions d'ownership, vous savez donc que l�ownership n�est pas une lourdeur invent�e par Rust, mais une r�alit� universelle : dans tout langage, il faut d�cider qui poss�de quoi, combien de temps �a vit, et quand on peut le partager. La diff�rence, c�est que Rust choisit de l�exprimer clairement et de le v�rifier � la compilation, l� o� d�autres laissent le soin au programmeur (C++) ou au GC (Java).

Je ne dis pas le contraire, il faut �videmment (dans tout langage) d�cider qui poss�de quoi, combien de temps �a vit, et quand on peut le partager. C'est comme vous dites "une r�alit� universelles". Et je suis encore d'accord avec vous que les moyens employ�s par Rust, v�rifiables � la compilation, apportent une plus-value. Par contre, je trouve (c'est un avis personnel, d'autres peuvent penser le contraire, cela d�pend comment on "ressent" les choses), je ne trouve pas que les m�canismes de Rust (qui sont tr�s valables, je ne dis pas le contraire) peuvent �tre exprim�s si "clairement" que cela.

Dans C++, les deux types de r�f�rence T& et T&& permettent respectivement de distinguer entre une r�f�rence � une donn�e du processus appelant et un transfert d'ownership vers l'appel�. Les pointeurs intelligents du C++ sont aussi un moyen de g�rer l'ownership au niveau d'un pointeur compt�.

Honn�tement, je me suis "d�tourn�" du C++ il y a d�j� bien longtemps. Je pourrais palabrer pendant des heures sur ce sujet, mais ce n'est le sujet... Je n'intervenais pas pour d�nigrer Rust, loin de l�, mais en r�action � l'article o� Brian Kernighan exprimait qu'il avait trouv� difficile d'appr�hender ces concepts, et que si un d�veloppeur de son calibre a eu des soucis avec cela, d'autres d�veloppeurs peuvent �galement avoir une grande difficult� � les assimiler et � les utiliser.

Le borrowing et les lifetimes sont des outils pour clarifier des cas particuliers (emprunt temporaire, partage, multithreading). C�est vrai qu�il y a une marche d�apprentissage, mais une fois pass�e, on gagne �norm�ment en robustesse et en s�r�nit�.

Je ne pense pas avoir dis le contraire, vous dites vous-m�me qu'il y a cette "marche" d'apprentissage, qui peut sembler facile pour certains, mais compliqu�e par d'autres. Cela n'enl�ve rien au fait qu'avec l'utilisation des ces outils, Rust aide a produire un code plus "secure" et offre par la suite, une robustesse et une s�r�nit�.

C'est une vision fantasm�e des langages de programmation. Compte tenu de la place occup�e par le C++ et le C dans les produits existants, je pense que personne n'a jamais s�rieusement fait l'hypoth�se que Rust pourrait s'imposer face au C++ en 10 ans. D'ailleurs quand on voit que Google (contributeur platinum de la fondation Rust) a offert un financement pour l'interop�rabilit� Rust/C++, cela montre bien que m�me les soutiens de premier plan du langage le voient coexister dans un �cosyst�me avec d'autres langages. Et je partage cette vision.

Il y a tout de m�me "un mouvement" qui tend a cesser d'utiliser "C++" et d'utiliser "Rust" � la place. Il est �vident que cela ne peut se faire du jour au lendemain, de part la base de code immense d�velopp�es en C/C++, je suis tout � fait d'accord avec vous sur ce point. 10ans, ce n'est peut-�tre pas assez, je vous l'accorde, mais "le COBOL", dans le domaine bancaire, reste largement utilis�, car rien n'as pu venir le remplacer. Certains ont essayer avec Java, mais sans succ�s.

Par contre, la coexistence de plusieurs langages dans un m�me produit, je ne suis pas fan. Cela ajoute une couche de complexit� dans la "cha�ne de production" du logiciel. Et il faut alors "trouver" des d�veloppeurs avec une bonne exp�rience dans 2 langages pour participer au d�veloppement du projet, ce qui, actuellement encore, n'est pas si facile a trouver.

Oui, Rust est support� par des grands acteurs, mais il n'en reste pas moins vrai que dans certains domaines (l'embarqu�), le premier langage disponible est toujours le C. Il y a, c'est vrai, des compilateurs Rust m�me pour certains microcontr�leurs, mais ils viennent apr�s le C et ne sont pas si rependus que cela. Si, pour une raison quelconque il faut changer de microcontr�leur dans un firmware, que ce "firmware" a �t� �crit en "Rust", et qu'il n'y a pas de compilateur Rust pour ce dernier, cela pose un grand soucis...

Rust n�a pas de classes, ce qui l��loigne fondamentalement de la syntaxe de C++. Sa hi�rarchie des types concrets (struct, enum, union, tableaux, primitives, �) reste proche d�une philosophie C, m�me si elle est enrichie de subtilit�s comme les encodages (repr).

Les traits d�finissent une hi�rarchie de comportements (ou de capacit�s), orthogonale � la hi�rarchie des types concrets : ils n�alt�rent pas ces structures simples. On peut former des trait objects, mais il y a toujours un type concret en arri�re-plan.

Rust n�emprunte donc pas l�approche hi�rarchique de C++ (h�ritage de classes qui m�le structure et comportement), mais propose une alternative orthogonale : des traits pour exprimer les comportements, et des g�n�riques pour composer ces comportements. � mes yeux, c�est une approche alternative qui prolonge l�esprit du C : un langage bas niveau, mais cette fois s�curis� et enrichi de concepts objets, sans impact direct sur l�organisation nominale des types concrets.

Je vous fais confiance sur cet aspect, je n'ai pas �tudier Rust dans son ensemble, je me suis attard� sur les principes utilis�s pour la "s�curisation" de la m�moire, et j'y ai vu une "ressemblance" syntaxique avec le C/C++. C'est peut-�tre une fausse "impression", mais c'est ce que j'ai ressenti.

Cela n�emp�che pas le syst�me de traits, associ� aux g�n�riques et aux macros proc�durales (travaillant sur l�AST), d��tre extr�mement puissant.

Je suis 100% d'accord avec vous, la POO tel qu'impl�ment�e dans le C++, Java n'est pas l'approche que je pr�f�re. Une approche plus bas�e sur le comportement plut�t que sur les "donn�es" d'un objet est pour moi, bien plus pertinent. L'encapsulation et l'h�ritage sont souvent � l'origine d'architectures de code difficiles � suivre et a faire �voluer. Il faut privil�gier la composition � l'h�ritage, et travailler en utilisant des interfaces et non des "types concrets".

Je ne me risquerais pas � d�finir de telles fronti�res. Vous avez du Rust dans Redox-OS -- l�essentiel du code (noyau, pilotes, biblioth�ques, espace utilisateur), � l�exception de quelques routines assembleur tr�s bas niveau et d�un peu de code C dans relibc, soit en cours de transition vers Rust, soit maintenu pour assurer certaines compatibilit�s POSIX -- et il y a �galement de plus en plus de Rust dans Linux.... Je ne fais pas de Rust embarqu�, mais cela aussi s'installe petit � petit.

Vous avez raison, les fronti�res sont plus floues en r�alit�, mais l'utilisation du C dans l'embarqu� offre une garantie que Rust ne peut pas apporter actuellement. Ce sera peut-�tre dans quelques ann�es ou peut-�tre pas.

C'est un petit d�tail, mais ils attirent toujours mon attention: ARM est r�cemment devenu soutien platinum de la Rust Foundation. On a donc d�sormais 6 soutiens platinum � la Rust Foundation : AWS, Google, Meta, Microsoft, Huawei, ARM. La pr�sence d'un acteur essentiellement mat�riel comme ARM donne une certaine perspective sur les �volutions de Rust.

Oui, mais il n'y a pas que des ARM qui sont utilis�s dans l'embarqu�... Parfois, pour gagner quelques centimes, on doit choisir un microcontr�leur pour y faire rentrer au chose-pied un firmware... Les "petits" d�tails attirent aussi mon attention

Je n'ai franchement pas l'envie ni le temps de "peser" le pour et le "contre" des attraits d'un langage par rapport � un autre. Tel n'�tait pas mon but dans ma r�action � l'article.

Mais je vous remercie de partager, de discuter, et de d�battre courtoisement.

B�V et Peace & Love.

[floyer]

Je cite : "L'encapsulation et l'h�ritage sont souvent � l'origine d'architectures de code difficiles � suivre et a faire �voluer. Il faut privil�gier la composition � l'h�ritage, et travailler en utilisant des interfaces et non des "types concrets".

L'encapsulation permet au contraire de raisonner � plus haut niveau. Prenons une table de hashage (hash table). Tout ce que tu souhaites pour utiliser cette table est qu'il est possible d'y ajouter/supprimer/retrouver des information d'apr�s leur cl�. L'encapsulation permet cela en t'emp�chant d'acc�der au tableau qu'il y a derri�re et programmer quelque chose qui cassera d�s que le mainteneur de la table de hashage gangera des modalit�s interne. Je cite les table de hashage, mais les exemples ne manquent pas (driver SGBD, etc).

Par ailleurs, encapsulation et interfaces ne s'opposent pas bien au contraire. Le principe d'une interface est justement de d�corr�ler donn�es et traitement, et permettre de substituer une impl�mentation � une autre, voire permettre l'usage de plusieurs impl�mentation simultan�ment. Les interfaces sont indissociables de l'encapsulation.

[OuftiBoy]

floyer

Je cite : "L'encapsulation et l'h�ritage sont souvent � l'origine d'architectures de code difficiles � suivre et a faire �voluer. Il faut privil�gier la composition � l'h�ritage, et travailler en utilisant des interfaces et non des "types concrets".

Oui, je maintient cela. Privil�gier la composition � l'h�ritage, et travailler pour des interfaces, sont des bonnes pratiques.

L'encapsulation permet au contraire de raisonner � plus haut niveau. Prenons une table de hashage (hash table). Tout ce que tu souhaites pour utiliser cette table est qu'il est possible d'y ajouter/supprimer/retrouver des information d'apr�s leur cl�.

Oui, je suis bien d'accord. Ajouter/Supprimer/Retrouver sont des "actions" ou des "comportements" sans "lien" avec un type quelconque.

L'encapsulation permet cela en t'emp�chant d'acc�der au tableau qu'il y a derri�re et programmer quelque chose qui cassera d�s que le mainteneur de la table de hashage gangera des modalit�s interne. Je cite les table de hashage, mais les exemples ne manquent pas (driver SGBD, etc).

Oui, l'encapsulation te permets d'�viter ce genre de "pratiques", je ne dis pas le contraire, mais l'encapsulation et un moyen "technique" pour �viter une "mauvaise" pratique. Je n'ai par exemple jamais rencontrer un d�veloppeur "C" qui modifiait un des �l�ments d'une structure FILE "directement" en rempla�ant le handler du fichier par l'�ge de sa grand-m�re... La structure FILE est faite pour �tre utilis�e par certaines fonctions bien sp�cifiques (que l'on pourrait nommer "interface", repr�sentant une liste de comportements que l'on peut faire avec).

Par ailleurs, encapsulation et interfaces ne s'opposent pas bien au contraire. Le principe d'une interface est justement de d�corr�ler donn�es et traitement

Justement, c'est l� que l'on se m�lange souvent les pieds... C'est l� tout l'avantage d'une interface. Une interface permet de "d�corr�ler" donn�es et traitement, alors que l'encapsulation "regroupe" donn�es et traitement. L'encapsulation impose une forme d'h�ritage, et on se retrouve vite avec une hi�rarchie de class, o� pour ajouter un "type" pouvant effectuer un "comportement", on en arrive � devoir modifier des classes en amont du nouveau type.

Je pr�f�re de loin une autre approche, plus proche des origine de la POO, o� des interfaces "D�finissent un comportement", et o� des "Type" (n'ayant rien en communs au niveau "data") impl�mente cette interface.

Un petit exemple pour mieux me faire comprendre. Prenons l'exemple d'un oiseau et d'un avion. Ils n'ont aucunes donn�es en commun, mais ils ont un "comportement" commun, le fait de savoir voler. On peut donc cr�er deux types "compl�tements" ind�pendants l'un de l'autre (avec leurs donn�es propres), et par combinaison d'un Type et d'une Interface, permettre de traiter d'une mani�re homog�ne le comportement "voler", sans avoir besoin d'utiliser l'h�ritage.

et permettre de substituer une impl�mentation � une autre, voire permettre l'usage de plusieurs impl�mentation simultan�ment. Les interfaces sont indissociables de l'encapsulation.

Dans la POO "classique, comme en C++ ou en Java", oui, l'encapsulation (regroupant data et comportement), les interfaces permettent de "d�coupler" (data et comportement). Mais il y a plusieurs "Genre de POO". O� il n'est pas n�cessaire d'utiliser l'encapsulation et donc l'h�ritage.

C'est dr�le comme discussion, car je suis par ailleurs en train de d�velopper un langage et un compilateur pour ce dernier, et j'ai "bosser" pas mal sur le sujet. J'en suis arriv� � la conclusion que d'encapsuler les data et leur comportement rendait l'�volution d'un programme plus compliqu� que n�cessaire.

Dans ce langage, on peut d�finir un "Type A" et un "Type B" n'ayant rien en commun. On peut �galement d�finir des "Interfaces". Les types respectant une m�me interface (ou une partie d'interface) peuvent �tre "combin�s" et "trait�s" de fa�on h�t�rog�ne, sans avoir besoin d'utiliser un m�canisme d'h�ritage. C'est bien plus souple. Tu veux cr�er un nouveau type ? Tu peux le faire en partant de 0, sans h�ritage. Si tu veux l'utiliser avec d'autres, il suffit de dire que le type impl�mente l'interface en question (ici, l'interface "voler), et c'est tout.

Cela ressemble au "Duck Typing" de Python, mais le compilateur produit du code "statique", et la validation qu'un type impl�mente bien une interface peut �tre fait � la compilation. C'est �norm�ment plus simple, et souple qu'une hi�rarchie de class ou m�me d'interfaces.

Si tu veux participer � ce d�bat, c'est "ici" https://www.developpez.net/forums/d2...uveau-langage/ que cela se passe.

PS: Utiliser l'encapsulation pour "prot�ger" les donn�es d'un acc�s direct est un autre sujet, qui peut �galement �tre r�solu sans passer par l'encapsulation (qui n�cessite une class).

B�T. et Peace & Love.

[fdecode]

C'est �norm�ment plus simple, et souple qu'une hi�rarchie de class ou m�me d'interfaces.

La hi�rarchie d'interfaces ne va pas complexifier les types concrets.
Elle permet en revanche de d�finir une taxonomie de comportement, et cela peut clarifier la structure logique du programme.

[floyer]

Je pense que nous n�avons pas la m�me notion d�encapsulation. Et c�est ce qui m�a fait r�agir.

Tu affirmes � L'encapsulation impose une forme d'h�ritage, �. Et bien non. Il suffit d�une classe avec des champs priv�s pour faire de l�encapsulation. (Pour faire de l�h�ritage, il faut deux classes). En Ada 83 (donc avant l�ajout de principes orient�s objet dans Ada95), le simple fait de d�clarer dans la partie publique � type Ma_Structure is private � te garantit l�encapsulation� et l�, pas d�h�ritage (cela n'est pas support� en Ada83, donc on ne parle ni de classe, ni d'objet) !!)

Le fait que tu n�ais pas acc�s aux champs depuis l�ext�rieur est de l�encapsulation. Les structures FILE dont l�int�rieur n�est pas document� est donc une forme d�encapsulation mais pas support� par le compilateur qui acceptera de compiler f->_flags avec certaines versions de la libc, alors que ce n'est absolument pas portable.

� J'en suis arriv� � la conclusion que d'encapsuler les data et leur comportement rendait l'�volution d'un programme plus compliqu� que n�cessaire. �� c�est un outil� adapt� � ton usage, je ne sais pas, mais le concept est que lorsqu�un programmeur te livre une biblioth�que, la signature de sa biblioth�que te dit ce que tu peux faire, et il y a un contrat moral : tant que tu n�utilises que �a, �a, �a, je m�efforce de modifier ma biblioth�que pour garantir le bon fonctionnement. Apr�s, si l�interface �tait mal d�finie, il faut la changer, cela peut casser des choses, etc. Pour un seul programmeur, c�est moins utile. (Tu sais bien que si tu acc�des � des donn�es internes, tu risques de le payer (plus de rigidit� dans tes structures de donn�es car la logique qui s�appuie sur ces donn�es est potentiellement diss�min� dans tout le code.)

Dans l�exemple de ton langage et cas d�usage, tu as d�fini un � player � qui peut sauter. Je suppose qu�il ne faut absolument pas que la position du joueur change sans que l�impl�mentation du joueur puisse changer l�affichage. Pour cela, il te faut de l�encapsulation, et la poign�e de fonctions qui ont acc�s � la position se charge de rendre l�affichage coh�rent avec toutes �volutions de la position.

� Utiliser l'encapsulation pour "prot�ger" les donn�es d'un acc�s direct est un autre sujet �. Il n�y a qu�une notion d�encapsulation et il s�agit bien d�emp�cher des acc�s directs aux donn�es internes, voire fonctions et/ou m�thodes internes� Comme le d�montre Ada83, les classes et h�ritages ne sont m�me pas n�cessaires m�me si souvent utilis�es pour cela dans d�autres langage. Utiliser un mot dans un autre sens ne peut qu�amener des incompr�hensions. � qui peut �galement �tre r�solu sans passer par l'encapsulation �. Ce serait de l�encapsulation sans encapsulation. Dit comme cela, je ne comprends pas.

Ainsi, je ne sais pas de quoi tu veux parler. La POO est caract�ris�e par l'encapsulation (mais cela ce n'est pas ce dont tu veux parler), l'h�ritage (que tu souhaite �viter), et le polymorphisme. Ta r�f�rence au Duck-Typing, me fait dire que tu souhaites parler de polymorphisme, ce qui est tr�s diff�rent. En Java, on l'obtient par h�ritage, ou par impl�mentation d'une interface, ce qui n�cessite d'expliciter ce qu'impl�mente tes variables. En OCaml, il y a un typage structurel, ainsi, on n'a pas besoin de se poser la question lors de l'impl�mentation des m�thodes. D'ailleurs, tu peux �crire let f(a) = a#do_it et ta fonction prend n'importe quel objet compatible avec la m�thode do_it... le tout v�rifi� � la compilation. (Tu notes l'inf�rence de type... OCaml d�duit que f a besoin d'un objet compatible avec la m�thode do_it.)

[OuftiBoy]

floyer

Tout d'abord, merci de ce dialogue courtois

Je pense que nous n�avons pas la m�me notion d�encapsulation. Et c�est ce qui m�a fait r�agir.

Oui, on ne "voient" pas cette encapsulation sous le m�me angle, c'est parfois difficile d'exprimer clairement "comment on voit" les choses sans une bonne discussion devant un caf�

Tu affirmes � L'encapsulation impose une forme d'h�ritage, �. Et bien non. Il suffit d�une classe avec des champs priv�s pour faire de l�encapsulation.

Je suis tout � faire d'accord, une classe et des champs "priv�s", c'est une encapsulation (quelque soit la "mani�re" dont est "impl�ment�e" cette encapsulation. Jusque l�, je suis 100% d'accord avec toi.

(Pour faire de l�h�ritage, il faut deux classes).

Tout � fait, mais si la cr�ation de cette "seconde class" d�rive de la premi�re, elle h�rite de la premi�re, data compris, et c'est l� (l'importation des donn�es de la classe de base) qui (selon mon point de vue, je peux me tromper), complique inutilement les choses. C'est en tout cas un probl�me que je vois souvent, et qui finit par des hi�rarchies complexes, difficile � "suivre". J'ai une m�taphore que j'utilise souvent: Si on s'y prend mal on fait du code "spaghettis" avec le C, et du code "lasagne" avec une POO "� la java/C++" (encapsulation + h�ritage), et moi, je pr�f�re les raviolis

En Ada 83 (donc avant l�ajout de principes orient�s objet dans Ada95), le simple fait de d�clarer dans la partie publique � type Ma_Structure is private � te garantit l�encapsulation� et l�, pas d�h�ritage (cela n'est pas support� en Ada83, donc on ne parle ni de classe, ni d'objet) !!)

Je suis d'accord avec toi. Je parlais de l'encapsulation qui "complique" les choses si on utilise l'h�ritage par la suite, car on h�rite aussi des donn�es. C'est d'ailleurs pour �a que l'on a ajout� � ce type de POO la notion d'interface, pour, en quelque sorte, contourner l'encapsulation. Les premi�res version du C++ n'avait pas cette notion d'interface, elle a �t� ajout�e "par apr�s". Je ne connais pas assez Java pour me prononcer. Concernant Ada, j'ai regarder ce dernier, car Rust emprunte (et ce n'est pas un reproche, loin de l�) beaucoup de ses concepts.

Le fait que tu n�ais pas acc�s aux champs depuis l�ext�rieur est de l�encapsulation. Les structures FILE dont l�int�rieur n�est pas document� est donc une forme d�encapsulation mais pas support� par le compilateur qui acceptera de compiler f->_flags avec certaines versions de la libc, alors que ce n'est absolument pas portable.

Je suis d'accord avec toi, mais un d�veloppeur qui ag�t de la sorte, comment dire... N'est pas un "bon d�veloppeur". En Python, les donn�es d'une class sont accessibles, mais part "convention", on n'est pas sens� les utiliser s'ils commencent par un '_'. Et si on doit y acc�der, on remplace l'acc�s direct part un getter/setter (et c'est pareil pour un champ publique d'une fonction, part d�faut, on peut y acc�der directement, mais si l'on doit effectuer un traitement avant ou apr�s l'acc�s, on ajoute une "propri�t�" avec getter/setter.

� J'en suis arriv� � la conclusion que d'encapsuler les data et leur comportement rendait l'�volution d'un programme plus compliqu� que n�cessaire. �� c�est un outil� adapt� � ton usage, je ne sais pas, mais le concept est que lorsqu�un programmeur te livre une biblioth�que, la signature de sa biblioth�que te dit ce que tu peux faire, et il y a un contrat moral : tant que tu n�utilises que �a, �a, �a, je m�efforce de modifier ma biblioth�que pour garantir le bon fonctionnement. Apr�s, si l�interface �tait mal d�finie, il faut la changer, cela peut casser des choses, etc

Je suis d'accord, mais une interface peut �tre "valide" � un moment donn�, mais lorsqu'il faut la faire �voluer, elle peut ne plus �tre valide... Il est parfois difficile de savoir "� l'avance" comment elle va devoir utiliser.

Si je reprend l'exemple de l'oiseau et de l'avion, on passe souvent par une "class abstraite" pour d�finir une interface. On a donc d�j� 3 classes (la class de base, et les 2 class oiseau et avion, soit d�j� 3 class. Moi (et c'est un avis personnel), c'est d�j� inutilement compliqu�, et je n'ai pas aborder les "interfaces".

D'o� ma "conviction" que s�parer un type et son comportement donne un code bien plus simple et lisible. Tu d�finis un type "A", un type "B", et si tu veux les utiliser d'une mani�re h�t�rog�ne, chaque type d�clare qu'il "respecte" une "interface" (l'interface "voler"). Tu n'as pas � te soucier si un futur type "C" veut �galement utilis� l'interface "voler".

Les types A, B, C est n'ont pas de lien entre eux (A est un oiseau (qui vole gr�ce ces ailes), B est un avion (qui vole gr�ce � des moteurs), et C sera "ce qu'il doit �tre, avec ces donn�es propres" (disons une pierre). Et bien sans toucher aux Type A ni B, il suffit au type C (une pierre) de d�clarer qu'il utilise l'interface 'voler', et d'impl�menter cette interface. La Pierre "qui vole", elle "vole" car jet�e en l'air par un gosse (par exemple). On a donc 3 types, compl�tement diff�rent l'un de l'autre, sans "lien", sans "class de base", sans besoin d'"h�ritage", mais qui peuvent �tres utilis�s d'une mani�re homog�ne, car on peut aller l'api 'voler' sur les 3 types.

Pour un seul programmeur, c�est moins utile. (Tu sais bien que si tu acc�des � des donn�es internes, tu risques de le payer (plus de rigidit� dans tes structures de donn�es car la logique qui s�appuie sur ces donn�es est potentiellement diss�min� dans tout le code.)

Il faut �viter toute "rigidit�", et le "d�couplage" du "type" et de son/ses "comportements", y participe.

Dans l�exemple de ton langage et cas d�usage, tu as d�fini un � player � qui peut sauter. Je suppose qu�il ne faut absolument pas que la position du joueur change sans que l�impl�mentation du joueur puisse changer l�affichage. Pour cela, il te faut de l�encapsulation, et la poign�e de fonctions qui ont acc�s � la position se charge de rendre l�affichage coh�rent avec toutes �volutions de la position.

Oui, mais chaque "type" est compl�tement ind�pendant l'un de l'autre. Une "interface" est juste le "nom d'un comportement" (techniquement, c'est une m�thode sans argument). Lorsque l'interface "sauter" est appel�e, cette derni�re "fait ce qu'elle veut pour r�aliser le comportement (ou api) sauter suivant sur quelle "objet" elle est appel�e.

C'est d'une facilit� et d'une impl�mentation tr�s simple.

Je suis bien conscient que ce n'est pas un type de POO "classique", C'est plus de la POC (Programmation Orient�e Comportement). Les "api" sont comme des messages "envoy�s" � des types. Cela se rapproche plus des origines de la POO tel que d�finie par son cr�ateur Alan Key.

Que les types poss�dent des donn�es priv�e ou public n'a pas d'importance ici.

Merci du d�bat, tr�s int�ressant. J'esp�re que petit � petit on va se comprendre.

B�T et Peace & Love.

[manu007]

Le langage C (apr�s A) f�t d�velopp� en moins d'un mois par K & R, la premi�re version d'Unix en moins d'un an, en y travaillant apr�s l'horaire de travail... Rust � quelques dix ans de vie et continue a poss�der des probl�mes, le voir dans le noyau de Linux me donne de la peine, m�me s'il est autoris� que dans les couches hautes du noyau. Je crois que beaucoup de d�veloppeurs ont des probl�mes avec les pointeurs et la lib�ration de m�moire ou bien ce sont des fonctions qu'ils n'ont pas encore tr�s bien compris...

[smarties]

Depuis les quelques projets legacy sur lesquels j'ai pu travailler (JAVA il y a longtemps et maintenant Python), il y a des choses que je n'aimerais plus traiter :
- l�h�ritage multiple
- plus de 2 niveaux d'h�ritage

Aujourd'hui je fais du Rust sur des projets perso et m�me si je n'ai pas d'h�ritage je le vis tr�s bien. La composition et les traits/interfaces sont une bonne chose, le plus dur a �t� de changer ses habitudes je trouve.

[floyer]

@OuftiBoy, j�ai l�impression que le langage existant qui est le plus proche de ce que souhaite est OCaml o� tu peux d�clarer des classes ind�pendamment et tout de m�me profiter du polymorphisme sans h�ritage (m�me si l�h�ritage est support�). OCaml se distingue de Python par le contr�le statiques des types � la compilation.

Ainsi, la fonction

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
let process obj =
  obj#saute 56;
  obj#saute "abc"

Ne compile pas car cela voudrait dire que la m�thode saute de l�objet consid�r� prend un argument qui est � la fois un entier et � la fois une cha�ne de caract�res.

Mais le code:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
let process obj =
  obj#saute 56;
  obj#tire HK416

D�clare une fonction qui a besoin d�un param�tre objet qui supporte les m�thodes saute et tire. Utiliser cette m�thode avec un objet qui ne supporte par les 2 m�thodes �chouera � la compilation.

On notera que les biblioth�ques OCaml sont tr�s rarement orient�es objet. Il y a en effet d�autres approches pour faire du polymorphisme.

[OuftiBoy]

@floyer:

@OuftiBoy, j�ai l�impression que le langage existant qui est le plus proche de ce que souhaite est OCaml o� tu peux d�clarer des classe ind�pendamment et tout de m�me profiter du polymorphisme sans h�ritage (m�me si l�h�ritage est support�). OCaml se distingue de Python par le contr�le statiques des types � la compilation.

Dans le fil qui traite de mon langage, on me fait aussi cette r�flexion. Malheureusement, mis � part de nom, je ne connais pas ce langage. Mais c'est bien possible que mon langage y ressemble, mais c'est fortuit. Mais je n'ai pas le temps, ni l'envie, d'�tudier chaque langages, mon parcours c'est BASIC sur C64, Pascal durant mes �tudes, C et ASM pour des microcontr�leurs au taf, Delphi et/ou C++ Builder pour des App "Windows", mais que j'ai remplac� avec bonheur par Python/wxPython. PS: Dans mon langage, le contr�le des types est �galement statique.

@Smarties

Depuis les quelques projets legacy sur lesquels j'ai pu travailler (JAVA il y a longtemps et maintenant Python), il y a des choses que je n'aimerais plus traiter :
- l�h�ritage multiple
- plus de 2 niveaux d'h�ritage

Aujourd'hui je fais du Rust sur des projets perso et m�me si je n'ai pas d'h�ritage je le vis tr�s bien. La composition et les traits/interfaces sont une bonne chose, le plus dur a �t� de changer ses habitudes je trouve.

Je comprend tout � fait, l'h�ritage et encore plus l'h�ritage multiple encore plus, produisent un code "lasagne", avec plus de couche que n�cessaire, et souvent avec trop d'abstractions pour "s'ins�rer dans la hi�rarchie" telle qu'on la d�couvre. Sans en avoir une grande connaissance, les traits/interface de Rust me semble aller "dans le bon sens".

@manu007

Le langage C (apr�s A) f�t d�velopp� en moins d'un mois par K & R, la premi�re version d'Unix en moins d'un an, en y travaillant apr�s l'horaire de travail... Rust � quelques dix ans de vie et continue a poss�der des probl�mes, le voir dans le noyau de Linux me donne de la peine, m�me s'il est autoris� que dans les couches hautes du noyau. Je crois que beaucoup de d�veloppeurs ont des probl�mes avec les pointeurs et la lib�ration de m�moire ou bien ce sont des fonctions qu'ils n'ont pas encore tr�s bien compris...

C'est vrai, C a �t� d�velopp� assez rapidement, m�me si j'adore ce langage, il n'est forc�ment adapt� � tous les besoins, et a certains UB (Undefined Behavior). C'est vrai aussi que Rust a 10 ans de vies, mais je ne connais pas assez ce dernier pour me prononcer, j'ai juste �tudi� son syst�me de protection de la m�moire, qui m�me s'il est efficace, me semble inutilement "compliqu�". Les d�veloppeurs qui ont des probl�mes avec les pointeurs sont souvent des d�veloppeurs ayant �t� form�s sur des langage avec GC, et n'ont qu'une vague connaissance du bas-niveau des choses. Ce qui n'est pas forc�ment de leurs fautes, mais de la formation qu'ils ont (ou pas) re�ues.

@Tous les 3
Pour ne pas "polluer" la discussion en discutant ici de mon langage, je vous invite � participer au fil de discussion le concernant. Cela ce passe ici: https://www.developpez.net/forums/d2...uveau-langage/

Pour faire cours, on y discute de l'impl�mentation de mon langage (Home) et de son compilateur (Home Compiler). J'avais envie d'�crire un compilateur, et je ne voulais pas (re)faire un compilateur pour un langage existant. Ceci a eu pour cons�quence que je suis parti d'une feuille blanche tant pour la d�finition du langage, que pour le d�veloppement du compilateur (fait compl�tement "� la main"). Cela m'a permis d'�tre "libre" et d'exp�rimenter diff�rents m�canismes tant pour le langage que pour le compilateur, quitte a r�inventer la roue, et forc�ment a commettre des erreurs.

Je n'ai "aucune pr�tention" concernant le langage, il ne sera peut-�tre jamais utilis� que par moi, il n'est pas destin� � "remplacer" ou "faire mieux" qu'un autre langage. Mais je vous avoue que le d�veloppement en // d'un langage et de son compilateur est tr�s instructif et int�ressant. Donc si cela vous tente de participer, vous �tes les bienvenus

B�V et Peace & Love.

[fdecode]

Depuis les quelques projets legacy sur lesquels j'ai pu travailler (JAVA il y a longtemps et maintenant Python), il y a des choses que je n'aimerais plus traiter :
- l�h�ritage multiple
- plus de 2 niveaux d'h�ritage

Aujourd'hui je fais du Rust sur des projets perso et m�me si je n'ai pas d'h�ritage je le vis tr�s bien. La composition et les traits/interfaces sont une bonne chose, le plus dur a �t� de changer ses habitudes je trouve.

Il y a de � l'h�ritage multiple � au sens des traits, et ils ne sont pas limit�s en nombre de niveaux. Mais dans la pratique, on utilise beaucoup la composition en Rust.
Comprendre qu'on n'avait pas besoin de classes et d'h�ritages, �a a aussi �t� une d�couverte pour moi, avec Rust.

[fdecode]

Le langage C (apr�s A) f�t d�velopp� en moins d'un mois par K & R, la premi�re version d'Unix en moins d'un an, en y travaillant apr�s l'horaire de travail... Rust � quelques dix ans de vie et continue a poss�der des probl�mes, le voir dans le noyau de Linux me donne de la peine, m�me s'il est autoris� que dans les couches hautes du noyau.

Qu'est-ce qu'on est en train de comparer?

• UNIX V1 (1969�71) -- complet : ~1 Mo *
• Debian 12 (2025, base) : ~1 Go
• Debian 12 (desktop complet) : ~10 Go
• D�p�t Debian complet : ~1,5 To

On doit certes applaudir � ce travail de pionnier. Mais on n'est plus dans les m�mes ordres de complexit�!

* pour avoir une id�e de la frugalit� des premiers UNIX, on peut lire certains papiers de Thompson ou de Ritchie, p. ex:

Dennis M. Ritchie and Ken Thompson. 1974. The UNIX time-sharing system. Commun. ACM 17, 7 (July 1974), 365�375.

D. M. Ritchie, "The UNIX system: The evolution of the UNIX time-sharing system," in AT&T Bell Laboratories Technical Journal, vol. 63, no. 8, pp. 1577-1593, Oct. 1984

Rust � quelques dix ans de vie et continue a poss�der des probl�mes

X a N ans de vie et continue � poss�der des probl�mes.
--> cette phrase marche avec tout en fait!
Tant qu'on ne pr�cise pas de quels probl�mes il s'agit...