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 ?
:fleche: Quel est votre avis sur le sujet ?
:fleche: Que pensez-vous du retour d'expérience de Brian Kernighan sur le langage Rust ?
:fleche: Brian Kernighan juge l’écosystème de Rust « incompréhensiblement vaste et lent ». Êtes-vous de cet avis ?
:fleche: 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 ?
:fleche: Selon vous, un langage de programmation doit-il viser d’abord la simplicité d’usage ou la robustesse et la sécurité ?
:fleche: 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 ?
:fleche: 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 ?
:fleche: Avez-vous déjà essayé d’apprendre Rust ? Si oui, quelles difficultés avez-vous rencontrées ?
:fleche: Préférez-vous travailler avec des langages plus permissifs (comme C, Python) ou plus stricts (comme Rust, Haskell) ?
:fleche: Que pensez-vous de l'état du projet Unix aujourd'hui ?
Voir aussi
:fleche: 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
:fleche: 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
:fleche: 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
Ce n'est que mon opinion...
:coucou:
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.
Bonjour à vous tous: manu007, smarties, floyer
:coucou:
@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.
