"Brian Kernighan, 83 ans, n'a écrit qu'un seul programme en Rust" et il donne son avis…
Il n'est pas vraiment concerné, lui n'a plus vraiment d'avenir dans le logiciel. Il profite de sa retraite. J'ai envie de dire, on se fout de son avis. Mais au delà, c'est normal à son âge d'aimer les vieux trucs et d'avoir une aversion au changement.
IL n'a écris 1 seul programme Rust. On sait qu'au départ c'est un langage un peu difficile car il ne se rapproche d'aucun autres. Pour autant Google avait reconnu dans un rapport que le temps d'apprentissage de Rust n'est pas plus long qu'un autre (Car une fois les concepts maitrisés, il est plutôt plus simple).
De mon avis perso, Rust remplacera C… mais pas avant 50 ans car il faut du temps avant de migré la base de code. COBOL nous l'a montré… et d'ici là beaucoup de chose peuvent arrivés. En attendant, les nouveaux programme devraient absolument abandonner C… s'ils étaient rationnels.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
PS : En fait quand il accuse Rust d'être "lent" et incroyablement compliqué alors que son programme était "sécurisé"… C'est parce qu'il trouve sécurisé un programme qui à ses yeux ne peut pas faire de bug… mais en architecture parallèle qu'en serait-il? N'as t'il réellement aucun risque de bug? Si les programme Rust sont plus lent (et de très peu) c'est principalement, car il rajoute de la sécurité/.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
C est rapide et simple car il est très proche du HW. La simplicité peut être une finalité en soi. C'est bien Rust, mais Rust utilise la lib C, donc déjà… La question "Rust va remplacer C" est hyper clivante car la permissivité du C est aussi une feature.
J'adore Java par exemple, à cause de la plateforme Java, pas à cause du langage. J'en ai rien à carrer de C# et autres. Savoir dans la tête de quelqu'un qui prétend s'y connaître ça va se faire remplacer, au secours.
Le C était proche du matériel du PDP-11 sur lequel il a été conçu. Il n'est pas du tout proche du matériel actuel, malgré les efforts des fabricants de processeurs pour adapter leur architecture à l'exécution du C et de langages apparentés (stockage de grosse données sur la pile d'exécution; opérations sur les pointeurs avec plusieurs niveaux d'indirection; …). Ce sont des choses qui n'étaient pas du tout évidentes à l'époque de l'invention du C. En d'autres termes, c'est le hardware actuel qui est proche du C, et non lwinverse.
Les choses seraient certainement plus simples avec un langage plus haut niveau laissant le soin au compilateur et au fabricant de processeur de choisir comment l'implémenter.
Si Rust a autant de succès que C, un jour ou lwautre on verra apparaître dans les processeurs et dans les systèmes d'exploitation de nouvelles primitives (instructions, appels systèmes, …) pour l'implémenter plus efficacement.
Si Rust a autant de succès que C, un jour ou lwautre on verra apparaître dans les processeurs et dans les systèmes d'exploitation de nouvelles primitives (instructions, appels systèmes, …) pour l'implémenter plus efficacement.
C'est comme pour les langues : il faut des locuteurs et des locutrices. C'est pour ça que la question posée sur l'avenir de Rust n'est pas pertinente et qu'elle ne pouvait pas s’attirer une réponse pertinente.
PS : je n'ai aucun avis sur ces langages (ni aucune vision). Mais les guéguerres entre les langages de programmation ont tendance à me faire rire et à m'agacer en même temps.
La particularité d'Unix et C qu'il décrit très bien est qu'ils sont proches du développeur, dans le sens d'être simple et accessible ce qui a permis sa diffusion.
Rust ne va pas du tout dans cette direction, c'est pour ça qu'il n'a pas accroché.
Désolé mais Rust est bien plus simple et proche du développeur.
En Rust tu as juste 2 concept à apprendre et comprendre (Borowing et ownership) et après tout ce que tu écris fonctionne. Tu l'exprime et ça juste marche. Quand ça "plante", l'explication est claire.
En C, c'est bien plus complexe. Non seulement il faut connaitre et comprendre les pointeurs (Y compris les pointeurs de fonctions), mais aussi et surtout tous les pièges qu'ils ont. Et avec ça "Hello world" fonctionne, mais pour un peu plus ça plante méchamment sans aucune informations. Il faut apprendre à débugger et pour ça il y a plusieurs école mais ce n'est jamais simple.
Ce que je te concède c'est que C pense comme un ordinateur , alors que Rust à une approche beaucoup plus proche de la philosophie d'un programme.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
RISC, qui domine le monde actuel du CPU, c'est une simplification des processeurs.
Pour les GPU, il y a une implémentation d'OpenCL en Rust, lente mais prometteuse, à voir.
Je ne comprends pas en quoi les performances ont à voir avec la taille de la stack ou 'opérations sur les pointeurs avec plusieurs niveaux d'indirection'… tu veux dire ça
int****proute
?
Les optimisations CPU, les micro-optimisations, c'est sur des petits blocs de 32 ou 64 instructions … Tu n'as pas de méthode générique pour savoir ce que va faire le programme automatiquement au-delà, via le compilateur, sur les accès mémoire. Je veux bien croire à ton langage de haut niveau, mais bonsoir l'accessibilité… En C, t'as les intrinsic, basta-cosi.
Attention, Rust n'est, selon moi, pas plus lent en théorie que le C. Sauf qu'en C tu bénéficie à 100% des intrinsic du compilateur (moins utile avec Rust car les contraintes d'accès mémoire sont tout le temps spécifié), et le link ou stabilité de l'ABI (je ne parle pas de binding) qui permet de distribuer des binaires performants et réutilisable. Voila.
Tu es sûr ? L'ascension irresistible des processeurs type ARM (RISC) a dépassé celle des compatibles PC (CISC) ?
Si tu ne prends en compte que les PC, non, bien que la part d'ARM soit passé de 0 à 15 % en l'espace de quelques années (Apple et les PC, Raspberry PI)
Par contre, si tu comptes les consoles, les téléphones, les serveurs, l'IoT, il doit y avoir au bas mot 80 % d'ARM. Facile.
J'imagine que la théorie importe peu lors de la mesure de l'exécution réelle (en cycles, instructions ou en temps).
Oui. On peut aussi dire que Fortran est plus rapide que C, parce qu'il ne peut y avoir d'aliasing de pointer.
En C on peut retrouver la compacité et les performances en utilisant restrict:
Rust n'est, selon moi, pas plus lent en théorie que le C
Si Rust est théoriquement plus lent que C… car il est sécurisé. Rust est capable de produire un programme exceptionnellement efficace, même plus que C pour un programmeur standard. Mais inévitablement quand on cherches l'optimisation a bloc, en C, on peut outre-passer des règles de sécurité. En Rust on ne peut pas.
Pour moi ce n'est pas souhaitable, mais certains cas l'on montré (je ne parles pas de démonstrations mais de cas concret ou Rust se montre plus lent). Et encore une fois, c'est quand on passe du temps à chercher à tout optimiser… Rust est pour moi autrement bien plus productif.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
malgré les efforts des fabricants de processeurs pour adapter leur architecture à l'exécution du C et de langages apparentés
Question de béotien : comment arrives-tu à ça ? C'est intéressant comme point de vue, je suis curieux !
Si Rust a autant de succès que C, un jour ou l'autre on verra apparaître dans les processeurs et dans les systèmes d'exploitation de nouvelles primitives (instructions, appels systèmes, …) pour l'implémenter plus efficacement.
De mémoire, il y avait eu un essai avec des processeurs Java, et c'était pas la folie. Ça ne veut pas dire que la prochaine fois ce sera aussi un échec, mais l'idée a été testée.
D'ailleurs, dans les processeurs Apple (M1 etc.), il me semble qu'il y a des circuits dédiés à JavaScript, pour accélérer certains comportements.
Question de béotien : comment arrives-tu à ça ? C'est intéressant comme point de vue, je suis curieux !
En regardant ce qui se fait ailleurs, par exemple, les LISP Machines qui ont (ou avaient) un jeu d'instruction plutôt dédié à manipuler très rapidement des listes chaînées; les données dans la mémoire sont "taggées" par exemple pour indiquer si une adresse contient une valeur entière, une référence vers un autre objet, ou rien du tout, ce qui est très utile au garbage collector pour nettoyer la mémoire.
Ou plein d'autres architectures historiques comme le z80, sur lequel écrire un compilateur C est possible, mais assez pénible, parce que les registres et instructions sont spécialisés pour faire d'autres choses. Par exemple, il n'y a pas vraiment de quoi implémenter un "frame pointer". Sur un processeur 68000, SPARc ou x86, ça se fait en une instruction (link/unlink, save/restore, et un mov bp, sp avec un offset sur le dernier). Ils ont tous les 3 également des modes d'adressages indexés, on peut donc facilement avoir sur la pile un pointeur vers une structure, et en une ou deux instructions, on va:
Récupérer ce pointeur dans la mémoire (adressage par bp + offset)
Ajouter un offset à ce pointeur (soit un offset constant pour accéder à un champ d'une structure, soit un nombre d'éléments multiplié par la taille d'un élément pour accéder à un tableau
lire ou écrire quelque chose à cette addresse
C'est un exemple de ce que je disais par "nombreux niveaux d'indirection de pointeurs". Bien sur on écrit pas int**** truc; dans un programme, mais on écrit facilement ce genre de code:
Deuxième niveau: le pointeur truc avec l'offset champ1
Troisième niveau: l'index dans le tableau champ1
Quatrième niveau, l'index de chose dans l'élément de champ1
Le code passe plus de temps à manipuler des adresses que des données (comme donnée dans cet exemple il y a la constante 3). Si on regarde un processeur comme le 68000, on voit que la moitié des registres sont dédiés aux calculs d'adresses en conséquence. C'est encore plus flagrant sur son petit frère 8 bit le 6809: pour gérer les adresses on a 4 registres 16 bit, alors que pour les données on en a un seul (découpable en 2 moitiés de 8 bits). Et les calculs sur les adresses sont plus rapides car ils disposent d'une unité arithmétique 16 bit dédiée (alors que les calculs sur les données sont fait en 8 bit et donc en 2 fois).
Il y a d'autres processeurs où la pile est limitée à 256 éléments au total. Sur le z80, on peut simuler un registre BP avec l'un des deux registres d'index, mais on ne peut pas adresser plus de 256 octets de mémoire et les index sont forcément constants. Pour tout le reste il faut faire des acrobaties qui consomment une quinzaine d'instructions.
On a des informations historiques des concepteurs de ces langages, aussi. Pour le x86, ce n'est pas exactement le C qui était visé, mais plutôt le Pascal. Mais le modèle d'exécution est assez similaire: fonctions avec passage de paramètres sur la pile, structures, tableaux. Pas de programmation objet, par exemple (ce qui se concentrerait plutôt sur des sauts indirects via des vtables). ça n'a pas vraiment été étudié pour les coroutines non plus.
Pour le SPARC, les choix de jeu d'instruction ont été faits en simulant l'exécution de code existant. Comme c'était en plein dans l'époque de UNIX pour Sun, ça a forcément été fait avec du C.
De mémoire, il y avait eu un essai avec des processeurs Java, et c'était pas la folie. Ça ne veut pas dire que la prochaine fois ce sera aussi un échec, mais l'idée a été testée.
D'ailleurs, dans les processeurs Apple (M1 etc.), il me semble qu'il y a des circuits dédiés à JavaScript, pour accélérer certains comportements.
Pour le Java, je suppose que tu parles des processeurs ARM Jazelle. Qui ont été un échec pour deux raisons: d'une part parce que ce mode d'exécution est incomplètement documenté par ARM, et d'autre part parce qu'il ne correspond pas du tout au fonctionnement interne des machines virtuelles Java de l'époque (qui font beaucoup de transformations sur le bytecode pour l'opptimiser avant de l'exécuter).
Pour le Javascript, effectivement il existe plusieurs opérations dédiées pour des comportements spécifiques sur certaines opérations mathématiques (ce n'esst pas spécifique à Apple, on trouve ça dans plusieurs processeurs ARM et c'est dans le jeu d'instruction officiel).
Dans les choses qui n'ont pas marché on peut aussi citer l'Intel iAPX 432 dont le but était de faire un processeur orienté objet.
Et un autre qui rejoint un peu ce que j'essaie de dire, c'est l'architecture Itanium de Intel. Le but était justement de supprimer des couches de complexité dans les processeurs (réordonnancement des instructions, renommage de registres, exécution spéculative) pour remettre tout ça sous la responsabilité du compilateur. En théorie, ce n'est pas une mauvaise idée pour avoir un langage vraiment "proche du matériel". En pratique, la densité du code est plus basse (et donc il s'exécute moins vite, parce que la mémoire est beaucoup plus lente que le processeur), et surtout, le code compilé est lié à une implémentation spécifique du CPU. Si une nouvelle génération de CPU devient disponible, avec, par exemple, des unités de traitement ou des registres supplémentaires, il faut tout recompiler pour en tirer parti. C'est l'erreur qu'ont fait les générations précédentes de RISC avec le "branch delay slot" par exemple (exécuter une instruction supplémentaire après un jump, avant d'aller à la nouvelle addresse: ça simplifiait beaucoup le design initial avec un pipeline à 4 étages seulement, mais c'est resté ensuite dans le jeu d'instruction alors que ça n'avait plus aucun intérêt).
On semble donc se diriger, aussi bien dans le logiciel que dans le matériel, vers une solution intermédiaire: un code assembleur qui fournit une représentation compacte de ce qu'il faut exécuter, mais tout en étant facile à décoder et optimiser par des phases de pré-traitement avant d'être exécutée. C'est le principe des machines virtuelles (javascript, java, wasm), mais c'est aussi ce qu'il se passe à l'intérieur des processeurs modernes (pré-décodage du jeu d'instruction x86 ou ARM vers des instructions internes microcodées; jeu d'instruction Thumb sur ARM pour gagner en densité et en bande passante mémoire). Une exception notable est le RISC-V, qui part dans la direction opposée avec un jeu d'instruction très minimaliste et donc peu dense, avec dans l'idée que cela pourrait permettre à ce pré-traitement d'être plus complexe et intrusif (c'est un peu plus facile de manipuler ce flot d'instruction si chaque instruction fait très peu de choses), mais par contre avec une densité faible qui risque de poser problème si les mémoires ne font pas de gros progrès en vitesse d'accès.
Au final, il y a en fait un genre de co-évolution: on exécute beaucoup de code basé sur le modèle d'exécution du C, donc on achète (et on fabrique) les processeurs qui sont efficace pour ça, et les autres architectures sont oubliées depuis longtemps. Les compilateurs s'adaptent également à ces processeurs courants. Et si quelqu'un vient proposer un langage avec des idées radicalement différentes, il vient se heurter à des processeurs pas forcément adaptés et donc à une pénalité de performances.
Je ne comprends VRAIMENT pas en quoi le C n'est pas fait pour les CPU récent, y compris ceux que tu imagines…
ARM s'est inspiré du 6502, rien de nouveau. Si tu regardes les PowerPC, les RISC les plus puissant, l'architecture n'a quasiment pas changé, simplement il peut faire a*b+c en 1 cycle (c'était il y a fort longtemps). Si tu regardes les UltraSparc, il pouvait passer 6 paramètres sans utiliser la Stack (register window …
Les seuls qui tentent aujourd'hui d'avoir une MMU virtuelle au sein du CPU, c'est Microsoft, avec le créateur de la série UltraSPARC T1 entre autres, que j'ai rencontré (Oui monsieur). Sans doute pour faire un CPU accélérant du code C# pour les serveurs.
On ne fait pas un CPU pour un langage. On fait un compilateur d'un langage pour un CPU. Si tu compares Fortran et C, pour le calcul scientifique, la différence de performance viendra
de l'aliasing de pointeur. Point. Il n'y a rien de métaphysique.
Merci, on entends souvent le discours "le C est proche du matériel ancien", mais si on regarde bien le langage on a des fonctions, des structures de données et si on ne bidouille pas trop avec les pointeurs de pointeurs de pointeurs, ça reste un langage très générique.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Là tout à coup me vient le cas du journal sur le calcul float qui exploite des registres de calculs intermédiaires. Manifestement beaucoup de gens n'ont pas compris que le bug était dans le code ; entre autres parce que le code C ne donne pas accès direct aux instructions modernes et le compilo fait sa sauce. Le C est effectivement basé sur un modèle de machine obsolète. Ça a amené à un comportement surprenant à première vue mais en réalité très logique quand on déplie les couches d'abstraction.
Après la force et le succès du C c'est aussi parce que ses pré-requis sont minimalistes concernant le hardware.
Waouh, quelle réponse ! Merci d'avoir pris le temps pour cette tartine, c'est instructif (sans jeu de mot :D).
Y'a un truc marrant dans l'utilisation des divers processeurs, c'est qu'on a les GPU, qui sont utilisés en GPGPU (donc comme des CPUs, d'un certain point de vue), on a des mécanismes pour brancher le stockage NVME directement sur le réseau… Limite, je me dis qu'à moyen terme le CPU "central" pourrait ne plus devenir qu'un auxiliaire, qui ordonnance mais sans faire trop de traitements (c'est sans doute déjà le cas pour certains domaines). Un peu comme le BIOS ou la BMC servent à mettre en place l'environnement.
Est-ce un scénario crédible que les CPUs deviennent anecdotiques à moyen terme (sur des machines type desktop/laptop, l'embarqué c'est une autre salade sans doute) ?
Je ne vois pas de raisons pour laquelle le CPU deviendrait secondaire à ce point là.
Le GPU a des inconvénients qui le rendent assez peu adaptés à réellement prendre le pas sur le CPU en dehors de quelques cas spécifiques.
Et les CPU sont tellement pas cher que on en met vraiment partout. Un chargeur de téléphone aujourd'hui a un processeur à 200MHz, bien plus puissant que la plupart des ordinateurs dans les années 90. Même chose pour un disque dur ou un SSD, la plupart des périphéricues USB utilisent un coeur Intel 8051 boosté, …
Donc d'une certaine façon l'architecture est déjà pas mal distribuée. Mais il y a des processeurs classiques partout, et le besoin de réaliser des circuits spécialisés (qui sont plus chers, c'est un peu le sur mesure de l'électronique) est de moins en moins justifié car les performances avec un CPU générique sont bien suffisantes.
Posté par Faya .
Évalué à 2 (+0/-0).
Dernière modification le 09 septembre 2025 à 23:17.
Un chargeur de téléphone aujourd'hui a un processeur à 200MHz, bien plus puissant que la plupart des ordinateurs dans les années 90.
Tu as une source pour ça ? Parce que je ne trouve rien qui aille dans ce sens. Ça serait plutôt de l'ordre de 50MHz (mais on reste dans les années 90).
https://spritesmods.com/?art=hddhack&page=1 (un disque dur avec un processeur ARM à 150MHz et 64MB de RAM, l'auteur ne s'arrête pas à l'identification du matériel et finit par démarrer Linux directement sur ce disque dur sans avoir besoin de le connecter à un ordinateur)
Je fais peut-être l'erreur de différencier microcontrôleur (MCU) et microprocesseur (CPU). J'imagine que la frontière entre les deux est fine, et peut changer au fil du temps.
Par exemple je ne range pas un ARM Cortex-M0 dans la même famille que ce qu'on trouve sur un SBC comme une Raspberry Pi ou un petit routeur compatible avec OpenWRT. L'exemple du Z80 me parle : c'était le grand chef de mon CPC 464, et de nos jours (enfin, y'a pas si longtemps), on le trouve à jouer le second rôle sur des cartes RAID bas de gamme.
Ton exemple ne présente qu'une redirection : tu lis l'adresse dans la mémoire pointée par truc et la stockes dans un registre r. Puis l'adresse mémoire du reste est de la forme r × s + o. Il y a un peu d'arithmétique car o va dépendre de index. Il y a des restrictions concernant s mais on peut faire en sorte de les respecter. Et accessoirement être plus optimal sur les accès critiques aux données : globalement faire en sorte que dans les boucles les accès mémoires soient bien séquentiels et continus. Ce qui coûte dans les redirections c'est le côté "random" des accès. Typiquement c'est la blague bien connue du tableau à 2 indices type** qui est en pratique stocké à plat et optimisé avec la convention de parcours du dernier indice au premier. En pratique, vu le mal de crâne que sont les pointeurs de pointeurs de… j'ai du mal à croire que c'est critique.
Par respect pour le personnage j'aurais formulé les choses différemment (j'ai appris la programmation avec le K&R).
Surtout qu'il s'agit d'une réponse à une question qu'on lui pose à la fin d'une conférence d'une heure sur l'histoire d'Unix.
C'est pas comme si il partait en croisade contre Rust. Il donne son avis, de son point de vue, c'est tout.
Oui en fin là, c'est mis en avant comme si c'était un argument anti-Rust… On ne peut pas dire tout et son contraire.
Sur ce qu'il dit sur le C, il a sans doute raison, mais sur le Rust. Peut-être que c'est un type sympa, politiquement il a raison ou tord peu importe. On parles de Rust, on parles d'arguments (assez factuels par ailleurs).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Rust n'est-il pas fait pour être un langage de backend de compilo ?
Un langage à syntaxe humaine style Python ou assimilé, une transpilation/compilation en Rust, et tout le monde est content. Non ?
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
Posté par steph1978 .
Évalué à 6 (+4/-0).
Dernière modification le 07 septembre 2025 à 18:01.
Non.
En backend de compilo, tu peux avoir
une représentation intermédiaire propre au compilo (LLVM-IR, GCC-IR, MLIR, QBE)
un byte code (java, C#, Python, Ruby) destiné à un interpréteur (VM)
du C (Nim, Awka), sûrement parce que c'est simple, que ça facilite l’interopérabilité et que tu peux t'appuyer sur des compilateurs puissants existants
du JS (Elm), pour déployer dans le navigateur
rien ; certain compilateur génèrent directement du code machine (tcc)
Bien sûr rien ne l'empêche techniquement, mais IMHO, générer du Rust serait un peu compliqué. Sauf pour un langage de script très proche des paradigmes de Rust.
La partie où il s'exprime sur Rust est assez anecdotique dans la vidéo, pourtant cela fait des gros titres sur plusieurs sites (en mal d'audience sans doute…).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Mais comme tout le monde le C: nul n'est prophète en son pays (d'ailleurs Luke, Marc et John sont d'accord) alors bon, les "Paul et Mick" éventuels, ça compte pas vraiment quand bien même ils auraient vaguement quelque chose à voir avec le bidule.
"Si tous les cons volaient, il ferait nuit" F. Dard
On ne peut pas trop s'attendre de la personne qui connaît un langage comme sa poche, l'utilise depuis des décennies et à qui on pose une question sur un langage plutôt récent et qu'il utilise peu de donner un avis pertinent sur la question.
Après… comme le souligne devnewton, ce n'est pas l'essentiel de l'article.
# Aucune légitimité
Posté par abriotde (site web personnel, Mastodon) . Évalué à -7 (+9/-17). Dernière modification le 06 septembre 2025 à 12:34.
"Brian Kernighan, 83 ans, n'a écrit qu'un seul programme en Rust" et il donne son avis…
Il n'est pas vraiment concerné, lui n'a plus vraiment d'avenir dans le logiciel. Il profite de sa retraite. J'ai envie de dire, on se fout de son avis. Mais au delà, c'est normal à son âge d'aimer les vieux trucs et d'avoir une aversion au changement.
IL n'a écris 1 seul programme Rust. On sait qu'au départ c'est un langage un peu difficile car il ne se rapproche d'aucun autres. Pour autant Google avait reconnu dans un rapport que le temps d'apprentissage de Rust n'est pas plus long qu'un autre (Car une fois les concepts maitrisés, il est plutôt plus simple).
De mon avis perso, Rust remplacera C… mais pas avant 50 ans car il faut du temps avant de migré la base de code. COBOL nous l'a montré… et d'ici là beaucoup de chose peuvent arrivés. En attendant, les nouveaux programme devraient absolument abandonner C… s'ils étaient rationnels.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Aucune légitimité
Posté par abriotde (site web personnel, Mastodon) . Évalué à -4 (+3/-8).
PS : En fait quand il accuse Rust d'être "lent" et incroyablement compliqué alors que son programme était "sécurisé"… C'est parce qu'il trouve sécurisé un programme qui à ses yeux ne peut pas faire de bug… mais en architecture parallèle qu'en serait-il? N'as t'il réellement aucun risque de bug? Si les programme Rust sont plus lent (et de très peu) c'est principalement, car il rajoute de la sécurité/.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Aucune légitimité
Posté par YBoy360 (site web personnel) . Évalué à 4 (+3/-1).
C est rapide et simple car il est très proche du HW. La simplicité peut être une finalité en soi. C'est bien Rust, mais Rust utilise la lib C, donc déjà… La question "Rust va remplacer C" est hyper clivante car la permissivité du C est aussi une feature.
J'adore Java par exemple, à cause de la plateforme Java, pas à cause du langage. J'en ai rien à carrer de C# et autres. Savoir dans la tête de quelqu'un qui prétend s'y connaître ça va se faire remplacer, au secours.
I use Arch BTW
[^] # Re: Aucune légitimité
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+5/-2).
Le C était proche du matériel du PDP-11 sur lequel il a été conçu. Il n'est pas du tout proche du matériel actuel, malgré les efforts des fabricants de processeurs pour adapter leur architecture à l'exécution du C et de langages apparentés (stockage de grosse données sur la pile d'exécution; opérations sur les pointeurs avec plusieurs niveaux d'indirection; …). Ce sont des choses qui n'étaient pas du tout évidentes à l'époque de l'invention du C. En d'autres termes, c'est le hardware actuel qui est proche du C, et non lwinverse.
Les choses seraient certainement plus simples avec un langage plus haut niveau laissant le soin au compilateur et au fabricant de processeur de choisir comment l'implémenter.
Si Rust a autant de succès que C, un jour ou lwautre on verra apparaître dans les processeurs et dans les systèmes d'exploitation de nouvelles primitives (instructions, appels systèmes, …) pour l'implémenter plus efficacement.
[^] # Re: Aucune légitimité
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5 (+3/-1). Dernière modification le 07 septembre 2025 à 21:23.
C'est comme pour les langues : il faut des locuteurs et des locutrices. C'est pour ça que la question posée sur l'avenir de Rust n'est pas pertinente et qu'elle ne pouvait pas s’attirer une réponse pertinente.
PS : je n'ai aucun avis sur ces langages (ni aucune vision). Mais les guéguerres entre les langages de programmation ont tendance à me faire rire et à m'agacer en même temps.
Je n’ai aucun avis sur systemd
[^] # Re: Aucune légitimité
Posté par wilk . Évalué à 5 (+3/-0).
La particularité d'Unix et C qu'il décrit très bien est qu'ils sont proches du développeur, dans le sens d'être simple et accessible ce qui a permis sa diffusion.
Rust ne va pas du tout dans cette direction, c'est pour ça qu'il n'a pas accroché.
[^] # Re: Aucune légitimité
Posté par abriotde (site web personnel, Mastodon) . Évalué à -2 (+0/-3).
Désolé mais Rust est bien plus simple et proche du développeur.
En Rust tu as juste 2 concept à apprendre et comprendre (Borowing et ownership) et après tout ce que tu écris fonctionne. Tu l'exprime et ça juste marche. Quand ça "plante", l'explication est claire.
En C, c'est bien plus complexe. Non seulement il faut connaitre et comprendre les pointeurs (Y compris les pointeurs de fonctions), mais aussi et surtout tous les pièges qu'ils ont. Et avec ça "Hello world" fonctionne, mais pour un peu plus ça plante méchamment sans aucune informations. Il faut apprendre à débugger et pour ça il y a plusieurs école mais ce n'est jamais simple.
Ce que je te concède c'est que C pense comme un ordinateur , alors que Rust à une approche beaucoup plus proche de la philosophie d'un programme.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Aucune légitimité
Posté par devnewton 🍺 (site web personnel) . Évalué à 8 (+6/-1).
Rust a bien une approche philosophique, mais façon Michel Onfray : on voit son égo depuis Alpha du Centaure.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Aucune légitimité
Posté par YBoy360 (site web personnel) . Évalué à 5 (+3/-0).
RISC, qui domine le monde actuel du CPU, c'est une simplification des processeurs.
Pour les GPU, il y a une implémentation d'OpenCL en Rust, lente mais prometteuse, à voir.
Je ne comprends pas en quoi les performances ont à voir avec la taille de la stack ou 'opérations sur les pointeurs avec plusieurs niveaux d'indirection'… tu veux dire ça
?
Les optimisations CPU, les micro-optimisations, c'est sur des petits blocs de 32 ou 64 instructions … Tu n'as pas de méthode générique pour savoir ce que va faire le programme automatiquement au-delà, via le compilateur, sur les accès mémoire. Je veux bien croire à ton langage de haut niveau, mais bonsoir l'accessibilité… En C, t'as les intrinsic, basta-cosi.
Attention, Rust n'est, selon moi, pas plus lent en théorie que le C. Sauf qu'en C tu bénéficie à 100% des intrinsic du compilateur (moins utile avec Rust car les contraintes d'accès mémoire sont tout le temps spécifié), et le link ou stabilité de l'ABI (je ne parle pas de binding) qui permet de distribuer des binaires performants et réutilisable. Voila.
I use Arch BTW
[^] # Re: Aucune légitimité
Posté par cg . Évalué à 3 (+1/-0).
Tu es sûr ? L'ascension irresistible des processeurs type ARM (RISC) a dépassé celle des compatibles PC (CISC) ?
J'imagine que la théorie importe peu lors de la mesure de l'exécution réelle (en cycles, instructions ou en temps).
(perso je n'ai pas d'avis à donner sur Rust vs C)
[^] # Re: Aucune légitimité
Posté par YBoy360 (site web personnel) . Évalué à 4 (+2/-0).
Si tu ne prends en compte que les PC, non, bien que la part d'ARM soit passé de 0 à 15 % en l'espace de quelques années (Apple et les PC, Raspberry PI)
Par contre, si tu comptes les consoles, les téléphones, les serveurs, l'IoT, il doit y avoir au bas mot 80 % d'ARM. Facile.
Oui. On peut aussi dire que Fortran est plus rapide que C, parce qu'il ne peut y avoir d'aliasing de pointer.
En C on peut retrouver la compacité et les performances en utilisant restrict:
Dans certains cas ça peut être très significatif. Mais ce qui compte c'est comme tu dis, le temps mesuré à l'exécution.
I use Arch BTW
[^] # Re: Aucune légitimité
Posté par abriotde (site web personnel, Mastodon) . Évalué à -1 (+0/-2).
Si Rust est théoriquement plus lent que C… car il est sécurisé. Rust est capable de produire un programme exceptionnellement efficace, même plus que C pour un programmeur standard. Mais inévitablement quand on cherches l'optimisation a bloc, en C, on peut outre-passer des règles de sécurité. En Rust on ne peut pas.
Pour moi ce n'est pas souhaitable, mais certains cas l'on montré (je ne parles pas de démonstrations mais de cas concret ou Rust se montre plus lent). Et encore une fois, c'est quand on passe du temps à chercher à tout optimiser… Rust est pour moi autrement bien plus productif.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Aucune légitimité
Posté par cg . Évalué à 3 (+1/-0).
Question de béotien : comment arrives-tu à ça ? C'est intéressant comme point de vue, je suis curieux !
De mémoire, il y avait eu un essai avec des processeurs Java, et c'était pas la folie. Ça ne veut pas dire que la prochaine fois ce sera aussi un échec, mais l'idée a été testée.
D'ailleurs, dans les processeurs Apple (M1 etc.), il me semble qu'il y a des circuits dédiés à JavaScript, pour accélérer certains comportements.
[^] # Re: Aucune légitimité
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+11/-0).
En regardant ce qui se fait ailleurs, par exemple, les LISP Machines qui ont (ou avaient) un jeu d'instruction plutôt dédié à manipuler très rapidement des listes chaînées; les données dans la mémoire sont "taggées" par exemple pour indiquer si une adresse contient une valeur entière, une référence vers un autre objet, ou rien du tout, ce qui est très utile au garbage collector pour nettoyer la mémoire.
Ou plein d'autres architectures historiques comme le z80, sur lequel écrire un compilateur C est possible, mais assez pénible, parce que les registres et instructions sont spécialisés pour faire d'autres choses. Par exemple, il n'y a pas vraiment de quoi implémenter un "frame pointer". Sur un processeur 68000, SPARc ou x86, ça se fait en une instruction (link/unlink, save/restore, et un mov bp, sp avec un offset sur le dernier). Ils ont tous les 3 également des modes d'adressages indexés, on peut donc facilement avoir sur la pile un pointeur vers une structure, et en une ou deux instructions, on va:
C'est un exemple de ce que je disais par "nombreux niveaux d'indirection de pointeurs". Bien sur on écrit pas
int**** truc;dans un programme, mais on écrit facilement ce genre de code:Si on compte on a ici:
Le code passe plus de temps à manipuler des adresses que des données (comme donnée dans cet exemple il y a la constante 3). Si on regarde un processeur comme le 68000, on voit que la moitié des registres sont dédiés aux calculs d'adresses en conséquence. C'est encore plus flagrant sur son petit frère 8 bit le 6809: pour gérer les adresses on a 4 registres 16 bit, alors que pour les données on en a un seul (découpable en 2 moitiés de 8 bits). Et les calculs sur les adresses sont plus rapides car ils disposent d'une unité arithmétique 16 bit dédiée (alors que les calculs sur les données sont fait en 8 bit et donc en 2 fois).
Il y a d'autres processeurs où la pile est limitée à 256 éléments au total. Sur le z80, on peut simuler un registre BP avec l'un des deux registres d'index, mais on ne peut pas adresser plus de 256 octets de mémoire et les index sont forcément constants. Pour tout le reste il faut faire des acrobaties qui consomment une quinzaine d'instructions.
On a des informations historiques des concepteurs de ces langages, aussi. Pour le x86, ce n'est pas exactement le C qui était visé, mais plutôt le Pascal. Mais le modèle d'exécution est assez similaire: fonctions avec passage de paramètres sur la pile, structures, tableaux. Pas de programmation objet, par exemple (ce qui se concentrerait plutôt sur des sauts indirects via des vtables). ça n'a pas vraiment été étudié pour les coroutines non plus.
Pour le SPARC, les choix de jeu d'instruction ont été faits en simulant l'exécution de code existant. Comme c'était en plein dans l'époque de UNIX pour Sun, ça a forcément été fait avec du C.
Pour le Java, je suppose que tu parles des processeurs ARM Jazelle. Qui ont été un échec pour deux raisons: d'une part parce que ce mode d'exécution est incomplètement documenté par ARM, et d'autre part parce qu'il ne correspond pas du tout au fonctionnement interne des machines virtuelles Java de l'époque (qui font beaucoup de transformations sur le bytecode pour l'opptimiser avant de l'exécuter).
Pour le Javascript, effectivement il existe plusieurs opérations dédiées pour des comportements spécifiques sur certaines opérations mathématiques (ce n'esst pas spécifique à Apple, on trouve ça dans plusieurs processeurs ARM et c'est dans le jeu d'instruction officiel).
Dans les choses qui n'ont pas marché on peut aussi citer l'Intel iAPX 432 dont le but était de faire un processeur orienté objet.
Et un autre qui rejoint un peu ce que j'essaie de dire, c'est l'architecture Itanium de Intel. Le but était justement de supprimer des couches de complexité dans les processeurs (réordonnancement des instructions, renommage de registres, exécution spéculative) pour remettre tout ça sous la responsabilité du compilateur. En théorie, ce n'est pas une mauvaise idée pour avoir un langage vraiment "proche du matériel". En pratique, la densité du code est plus basse (et donc il s'exécute moins vite, parce que la mémoire est beaucoup plus lente que le processeur), et surtout, le code compilé est lié à une implémentation spécifique du CPU. Si une nouvelle génération de CPU devient disponible, avec, par exemple, des unités de traitement ou des registres supplémentaires, il faut tout recompiler pour en tirer parti. C'est l'erreur qu'ont fait les générations précédentes de RISC avec le "branch delay slot" par exemple (exécuter une instruction supplémentaire après un jump, avant d'aller à la nouvelle addresse: ça simplifiait beaucoup le design initial avec un pipeline à 4 étages seulement, mais c'est resté ensuite dans le jeu d'instruction alors que ça n'avait plus aucun intérêt).
On semble donc se diriger, aussi bien dans le logiciel que dans le matériel, vers une solution intermédiaire: un code assembleur qui fournit une représentation compacte de ce qu'il faut exécuter, mais tout en étant facile à décoder et optimiser par des phases de pré-traitement avant d'être exécutée. C'est le principe des machines virtuelles (javascript, java, wasm), mais c'est aussi ce qu'il se passe à l'intérieur des processeurs modernes (pré-décodage du jeu d'instruction x86 ou ARM vers des instructions internes microcodées; jeu d'instruction Thumb sur ARM pour gagner en densité et en bande passante mémoire). Une exception notable est le RISC-V, qui part dans la direction opposée avec un jeu d'instruction très minimaliste et donc peu dense, avec dans l'idée que cela pourrait permettre à ce pré-traitement d'être plus complexe et intrusif (c'est un peu plus facile de manipuler ce flot d'instruction si chaque instruction fait très peu de choses), mais par contre avec une densité faible qui risque de poser problème si les mémoires ne font pas de gros progrès en vitesse d'accès.
Au final, il y a en fait un genre de co-évolution: on exécute beaucoup de code basé sur le modèle d'exécution du C, donc on achète (et on fabrique) les processeurs qui sont efficace pour ça, et les autres architectures sont oubliées depuis longtemps. Les compilateurs s'adaptent également à ces processeurs courants. Et si quelqu'un vient proposer un langage avec des idées radicalement différentes, il vient se heurter à des processeurs pas forcément adaptés et donc à une pénalité de performances.
[^] # Re: Aucune légitimité
Posté par YBoy360 (site web personnel) . Évalué à 4 (+2/-0).
Je ne comprends VRAIMENT pas en quoi le C n'est pas fait pour les CPU récent, y compris ceux que tu imagines…
ARM s'est inspiré du 6502, rien de nouveau. Si tu regardes les PowerPC, les RISC les plus puissant, l'architecture n'a quasiment pas changé, simplement il peut faire a*b+c en 1 cycle (c'était il y a fort longtemps). Si tu regardes les UltraSparc, il pouvait passer 6 paramètres sans utiliser la Stack (register window …
Les seuls qui tentent aujourd'hui d'avoir une MMU virtuelle au sein du CPU, c'est Microsoft, avec le créateur de la série UltraSPARC T1 entre autres, que j'ai rencontré (Oui monsieur). Sans doute pour faire un CPU accélérant du code C# pour les serveurs.
On ne fait pas un CPU pour un langage. On fait un compilateur d'un langage pour un CPU. Si tu compares Fortran et C, pour le calcul scientifique, la différence de performance viendra
de l'aliasing de pointeur. Point. Il n'y a rien de métaphysique.
I use Arch BTW
[^] # Re: Aucune légitimité
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
Merci, on entends souvent le discours "le C est proche du matériel ancien", mais si on regarde bien le langage on a des fonctions, des structures de données et si on ne bidouille pas trop avec les pointeurs de pointeurs de pointeurs, ça reste un langage très générique.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Aucune légitimité
Posté par Computer (site web personnel) . Évalué à 3 (+3/-0).
Là tout à coup me vient le cas du journal sur le calcul float qui exploite des registres de calculs intermédiaires. Manifestement beaucoup de gens n'ont pas compris que le bug était dans le code ; entre autres parce que le code C ne donne pas accès direct aux instructions modernes et le compilo fait sa sauce. Le C est effectivement basé sur un modèle de machine obsolète. Ça a amené à un comportement surprenant à première vue mais en réalité très logique quand on déplie les couches d'abstraction.
Après la force et le succès du C c'est aussi parce que ses pré-requis sont minimalistes concernant le hardware.
[^] # Re: Aucune légitimité
Posté par cg . Évalué à 3 (+1/-0).
Waouh, quelle réponse ! Merci d'avoir pris le temps pour cette tartine, c'est instructif (sans jeu de mot :D).
Y'a un truc marrant dans l'utilisation des divers processeurs, c'est qu'on a les GPU, qui sont utilisés en GPGPU (donc comme des CPUs, d'un certain point de vue), on a des mécanismes pour brancher le stockage NVME directement sur le réseau… Limite, je me dis qu'à moyen terme le CPU "central" pourrait ne plus devenir qu'un auxiliaire, qui ordonnance mais sans faire trop de traitements (c'est sans doute déjà le cas pour certains domaines). Un peu comme le BIOS ou la BMC servent à mettre en place l'environnement.
Est-ce un scénario crédible que les CPUs deviennent anecdotiques à moyen terme (sur des machines type desktop/laptop, l'embarqué c'est une autre salade sans doute) ?
[^] # Re: Aucune légitimité
Posté par Renault (site web personnel) . Évalué à 4 (+1/-0).
Je ne vois pas de raisons pour laquelle le CPU deviendrait secondaire à ce point là.
Le GPU a des inconvénients qui le rendent assez peu adaptés à réellement prendre le pas sur le CPU en dehors de quelques cas spécifiques.
[^] # Re: Aucune légitimité
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Et les CPU sont tellement pas cher que on en met vraiment partout. Un chargeur de téléphone aujourd'hui a un processeur à 200MHz, bien plus puissant que la plupart des ordinateurs dans les années 90. Même chose pour un disque dur ou un SSD, la plupart des périphéricues USB utilisent un coeur Intel 8051 boosté, …
Donc d'une certaine façon l'architecture est déjà pas mal distribuée. Mais il y a des processeurs classiques partout, et le besoin de réaliser des circuits spécialisés (qui sont plus chers, c'est un peu le sur mesure de l'électronique) est de moins en moins justifié car les performances avec un CPU générique sont bien suffisantes.
[^] # Re: Aucune légitimité
Posté par Faya . Évalué à 2 (+0/-0). Dernière modification le 09 septembre 2025 à 23:17.
Tu as une source pour ça ? Parce que je ne trouve rien qui aille dans ce sens. Ça serait plutôt de l'ordre de 50MHz (mais on reste dans les années 90).
[^] # Re: Aucune légitimité
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Effectivement ça semble être autour de 50MHz, j'ai un peu exagéré
Sources:
https://forrestheller.com/Apollo-11-Computer-vs-USB-C-chargers.html (un chargeur Anker avec un processeur à 48MHz)
https://www.righto.com/2015/11/macbook-charger-teardown-surprising.html?m=1 (un chargeur Apple, à seulement 16MHz mais tout de menme 4 fois plus rapide que le processeur central du Macintosh original)
https://spritesmods.com/?art=hddhack&page=1 (un disque dur avec un processeur ARM à 150MHz et 64MB de RAM, l'auteur ne s'arrête pas à l'identification du matériel et finit par démarrer Linux directement sur ce disque dur sans avoir besoin de le connecter à un ordinateur)
[^] # Re: Aucune légitimité
Posté par cg . Évalué à 2 (+0/-0).
Je fais peut-être l'erreur de différencier microcontrôleur (MCU) et microprocesseur (CPU). J'imagine que la frontière entre les deux est fine, et peut changer au fil du temps.
Par exemple je ne range pas un ARM Cortex-M0 dans la même famille que ce qu'on trouve sur un SBC comme une Raspberry Pi ou un petit routeur compatible avec OpenWRT. L'exemple du Z80 me parle : c'était le grand chef de mon CPC 464, et de nos jours (enfin, y'a pas si longtemps), on le trouve à jouer le second rôle sur des cartes RAID bas de gamme.
Pour compléter ta réponse, j'ai trouvé ceci intéressant et assez clair : Why are we still using CPUs instead of GPUs?.
[^] # Re: Aucune légitimité
Posté par Computer (site web personnel) . Évalué à 1 (+1/-0).
Ton exemple ne présente qu'une redirection : tu lis l'adresse dans la mémoire pointée par truc et la stockes dans un registre r. Puis l'adresse mémoire du reste est de la forme r × s + o. Il y a un peu d'arithmétique car o va dépendre de index. Il y a des restrictions concernant s mais on peut faire en sorte de les respecter. Et accessoirement être plus optimal sur les accès critiques aux données : globalement faire en sorte que dans les boucles les accès mémoires soient bien séquentiels et continus. Ce qui coûte dans les redirections c'est le côté "random" des accès. Typiquement c'est la blague bien connue du tableau à 2 indices
type**qui est en pratique stocké à plat et optimisé avec la convention de parcours du dernier indice au premier. En pratique, vu le mal de crâne que sont les pointeurs de pointeurs de… j'ai du mal à croire que c'est critique.[^] # Re: Aucune légitimité
Posté par Florian.J . Évalué à 10 (+18/-0).
Par respect pour le personnage j'aurais formulé les choses différemment (j'ai appris la programmation avec le K&R).
Surtout qu'il s'agit d'une réponse à une question qu'on lui pose à la fin d'une conférence d'une heure sur l'histoire d'Unix.
C'est pas comme si il partait en croisade contre Rust. Il donne son avis, de son point de vue, c'est tout.
[^] # Re: Aucune légitimité
Posté par Voltairine . Évalué à 10 (+13/-0).
Et il le donne avec une pointe d'humour et beaucoup d'humilité, contrairement au commentaire originel…
[^] # Re: Aucune légitimité
Posté par abriotde (site web personnel, Mastodon) . Évalué à -1 (+1/-3).
Oui en fin là, c'est mis en avant comme si c'était un argument anti-Rust… On ne peut pas dire tout et son contraire.
Sur ce qu'il dit sur le C, il a sans doute raison, mais sur le Rust. Peut-être que c'est un type sympa, politiquement il a raison ou tord peu importe. On parles de Rust, on parles d'arguments (assez factuels par ailleurs).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Aucune légitimité
Posté par jseb . Évalué à 2 (+1/-1).
Rust n'est-il pas fait pour être un langage de backend de compilo ?
Un langage à syntaxe humaine style Python ou assimilé, une transpilation/compilation en Rust, et tout le monde est content. Non ?
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Aucune légitimité
Posté par steph1978 . Évalué à 6 (+4/-0). Dernière modification le 07 septembre 2025 à 18:01.
Non.
En backend de compilo, tu peux avoir
Bien sûr rien ne l'empêche techniquement, mais IMHO, générer du Rust serait un peu compliqué. Sauf pour un langage de script très proche des paradigmes de Rust.
# Titre peripatéticlic
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+23/-0).
La partie où il s'exprime sur Rust est assez anecdotique dans la vidéo, pourtant cela fait des gros titres sur plusieurs sites (en mal d'audience sans doute…).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Titre peripatéticlic
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0 (+1/-2).
En mal d'acharnement anti-Rust.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Il a écrit la Bible du C
Posté par Luc-Skywalker . Évalué à 1 (+2/-3).
Mais comme tout le monde le C: nul n'est prophète en son pays (d'ailleurs Luke, Marc et John sont d'accord) alors bon, les "Paul et Mick" éventuels, ça compte pas vraiment quand bien même ils auraient vaguement quelque chose à voir avec le bidule.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Il a écrit la Bible du C
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 8 (+6/-1).
On ne peut pas trop s'attendre de la personne qui connaît un langage comme sa poche, l'utilise depuis des décennies et à qui on pose une question sur un langage plutôt récent et qu'il utilise peu de donner un avis pertinent sur la question.
Après… comme le souligne devnewton, ce n'est pas l'essentiel de l'article.
Je n’ai aucun avis sur systemd
[^] # Re: Il a écrit la Bible du C
Posté par Luc-Skywalker . Évalué à 2 (+0/-0).
absolument !
"Si tous les cons volaient, il ferait nuit" F. Dard
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.