IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    Juin 2023
    Messages
    1 522
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2023
    Messages : 1 522
    Par défaut Brian Kernighan, informaticien de renom et co-créateur d'Unix, s'exprime après avoir testé le langage Rust
    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

  2. #2
    Membre confirmé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    111
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2021
    Messages : 111
    Par défaut
    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.

  3. #3
    Membre confirmé
    Homme Profil pro
    Architecte réseau
    Inscrit en
    Février 2024
    Messages
    293
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Architecte réseau

    Informations forums :
    Inscription : Février 2024
    Messages : 293
    Par défaut
    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.

  4. #4
    Membre confirmé
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Mai 2015
    Messages
    404
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Mai 2015
    Messages : 404
    Par défaut Ce n'est que mon opinion...


    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.

  5. #5
    Membre confirmé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    111
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2021
    Messages : 111
    Par défaut
    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?

  6. #6
    Nouveau candidat au Club
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Juin 2025
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Suisse

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Juin 2025
    Messages : 10
    Par défaut rust
    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.

  7. #7
    Membre confirmé
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Mai 2015
    Messages
    404
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Mai 2015
    Messages : 404
    Par défaut Un peu de nuance...
    Pat2kz,

    Citation Envoyé par Pat2kz Voir le message
    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++.

    Citation Envoyé par Pat2kz Voir le message
    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.

  8. #8
    Membre confirmé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    111
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2021
    Messages : 111
    Par défaut
    Citation Envoyé par OuftiBoy Voir le message
    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é.

    Citation Envoyé par OuftiBoy Voir le message
    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.

    Citation Envoyé par OuftiBoy Voir le message
    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++.
    Citation Envoyé par OuftiBoy Voir le message
    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.
    Citation Envoyé par OuftiBoy Voir le message
    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.

  9. #9
    Membre confirmé
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Mai 2015
    Messages
    404
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Mai 2015
    Messages : 404
    Par défaut Oui et non...
    fdecode

    Citation Envoyé par fdecode Voir le message
    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.

    Citation Envoyé par fdecode Voir le message
    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.

    Citation Envoyé par fdecode Voir le message
    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é.

    Citation Envoyé par fdecode Voir le message
    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...

    Citation Envoyé par fdecode Voir le message
    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.

    Citation Envoyé par fdecode Voir le message
    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".

    Citation Envoyé par fdecode Voir le message
    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.

    Citation Envoyé par fdecode Voir le message
    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.

  10. #10
    Membre éclairé
    Homme Profil pro
    autre
    Inscrit en
    Septembre 2015
    Messages
    506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Septembre 2015
    Messages : 506
    Par défaut
    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.

  11. #11
    Membre confirmé
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Mai 2015
    Messages
    404
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Mai 2015
    Messages : 404
    Par défaut Oui et non...
    floyer

    Citation Envoyé par floyer Voir le message
    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.

    Citation Envoyé par floyer Voir le message
    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.

    Citation Envoyé par floyer Voir le message
    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).

    Citation Envoyé par floyer Voir le message
    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.

    Citation Envoyé par floyer Voir le message
    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.

  12. #12
    Membre confirmé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    111
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2021
    Messages : 111
    Par défaut
    Citation Envoyé par OuftiBoy Voir le message
    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.

  13. #13
    Membre éclairé
    Homme Profil pro
    autre
    Inscrit en
    Septembre 2015
    Messages
    506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : autre

    Informations forums :
    Inscription : Septembre 2015
    Messages : 506
    Par défaut
    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.)

  14. #14
    Membre confirmé
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Mai 2015
    Messages
    404
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Mai 2015
    Messages : 404
    Par défaut Bonjour floyer
    floyer

    Tout d'abord, merci de ce dialogue courtois

    Citation Envoyé par floyer Voir le message
    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é

    Citation Envoyé par floyer Voir le message
    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.

    Citation Envoyé par floyer Voir le message
    (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

    Citation Envoyé par floyer Voir le message
    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.

    Citation Envoyé par floyer Voir le message
    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.

    Citation Envoyé par floyer Voir le message
    « 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.

    Citation Envoyé par floyer Voir le message
    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.

    Citation Envoyé par floyer Voir le message
    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.

  15. #15
    Membre éprouvé
    Homme Profil pro
    Développeur
    Inscrit en
    Août 2003
    Messages
    1 504
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Août 2003
    Messages : 1 504
    Par défaut
    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.

  16. #16
    Membre actif
    Profil pro
    Consultant
    Inscrit en
    Janvier 2011
    Messages
    83
    Détails du profil
    Informations personnelles :
    Localisation : Espagne

    Informations professionnelles :
    Activité : Consultant

    Informations forums :
    Inscription : Janvier 2011
    Messages : 83
    Par défaut
    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...

  17. #17
    Membre confirmé
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    Mai 2021
    Messages
    111
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Mai 2021
    Messages : 111
    Par défaut
    Citation Envoyé par manu007 Voir le message
    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

    Citation Envoyé par manu007 Voir le message
    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...

Discussions similaires

  1. Réponses: 0
    Dernier message: 31/12/2020, 16h12
  2. Informaticiens de ce forum, quel est votre métier ?
    Par Bidouille dans le forum Emploi
    Réponses: 46
    Dernier message: 21/07/2005, 12h12
  3. Réponses: 32
    Dernier message: 20/01/2004, 19h33
  4. renomer une DB
    Par wilaya dans le forum MS SQL Server
    Réponses: 4
    Dernier message: 12/12/2003, 15h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo