Discussion :

[Bardaz]

C'est pas comme si Rust était testé dans le kernel depuis plusieurs années pour voir si ça valait le coup et leur convenait après tout... Et le plus beau : tous ces débats sont publics. Faut arrêter de chercher des complots à un moment...

Encore une fois on se trompe de débat il ne porte pas du tout sur la qualité du code Rust, son exécution ou tout aspect technique. Comme tu le dis pas de complots tout est public. La question se pose sur la gouvernance et les logiques de pouvoir coté Rust VS l'existant. Là il est grand temps que le débat se pose car c'est ici que tout se joue dans le tuilage. Le remplacement des développeurs impliquent de céder une partie du "pouvoir" majoritairement à des big techs logées aux USA là où avec C et C++ les instances sont internationales, les devs seniors pléthore et surtout organisés !

Je ne sors pas ça du chapeau, faites une recherche, même rapide sur la partie financière de Rust et sur les protocoles de décisions des instances des différents langages. La plupart des personnes se concentrent sur la partie technique à juste titre c'est la première à interroger mais il ne faut aucunement s'arrêter là. Il faut avouer que c'est pas un aspect très apétant pour des devs mais faut bien s'y coller pour comprendre pourquoi les bigs techs et le gouvernement US soutient à fond.

[calvaire]

Chacun voit midi à sa porte, perso la secte C\C++ bloquée dans les années 2000 je la trouve encore bien présente. Enfin elle est bientôt à la retraite.

c'est juste que je vois passer beaucoup de news sur le net de certains qui veulent absolument tous recoder un truc (même quand ça marche très bien depuis des années) en rust.
Meme antropic fait sa pub en codant en rust un compilateur c. L’intérêt technique de ce truc et nul, ils ont choisit volontairement pour faire de la pub de coder en rust parmis les 10aines d'autres langages populaire qui existe.

Il y'a 10ans je disais la même chose avec la "secte" javascript, tous le monde voulaient tous recoder en javascript. On a eu des hyperviseurs/émulateurs en javascript, des système d'exploitation web comme firefox os...etc.
Tous ça sait d'ailleurs terminé à du web assembly.


Perso j'ai toujours suivie le conseil de Warren Buffett, tant en finance que dans ma carrière pro et dans ma vie perso:

C'est lorsque mon chauffeur de taxi me dit d'acheter une action que je sais qu'il faut la vendre.

ce qui explique que j'ai jamais appris le js ou le rust

Les stats semble me donner tort mets de ce que je con,state du marché du travail en Europe et en asie il y'a décalage très réel entre les statistiques globales et la réalité du terrain.
Quand les comparatifs (comme l'enquête Stack Overflow) placent Rust au sommet, les chiffres sont massivement tirés vers le haut par trois facteurs précis :
Les rôles à l'étranger (notamment US en remote) où les salaires à 180k – 230k sont fréquents.
Le secteur de la Web3 / Blockchain, très friand de Rust, qui a longtemps surpayé ses ingénieurs (parfois en jetons/tokens).
La rareté des profils seniors : beaucoup de développeurs apprennent Rust en dilettante, mais les vrais experts capables de gérer de la programmation système complexe sont rares.

Mais ailleurs, sur un poste de "dev" classique en CDI, la grille salariale locale reprend souvent le dessus, et Rust ne fait pas de miracle absolu face à la réalité du marché.
Perso je conseil plutôt de partir sur du des technos de niche à forte valeur : Scala, Clojure ou Zig

[Uther]

Je ne sors pas ça du chapeau, faites une recherche, même rapide sur la partie financière de Rust et sur les protocoles de décisions des instances des différents langages. La plupart des personnes se concentrent sur la partie technique à juste titre c'est la première à interroger mais il ne faut aucunement s'arrêter là. Il faut avouer que c'est pas un aspect très apétant pour des devs mais faut bien s'y coller pour comprendre pourquoi les bigs techs et le gouvernement US soutient à fond.

Il faudrait que tu sois plus précis car ce que tu reproches au Rust, comparé au C et C++, n'est pas très clair .
Les protocoles de décision en ce qui concerne l'évolution de Rust sont connus et relativement ouverts. Il ne faut pas croire que c'est très différent coté C ou C++, les comités de normalisation du langage ont beau répondre à une norme ISO, ils ont tout autant leur problèmes de jeu de pouvoir.

c'est juste que je vois passer beaucoup de news sur le net de certains qui veulent absolument tous recoder un truc (même quand ça marche très bien depuis des années) en rust.
Meme antropic fait sa pub en codant en rust un compilateur c. L’intérêt technique de ce truc et nul, ils ont choisit volontairement pour faire de la pub de coder en rust parmi les 10aines d'autres langages populaire qui existe.

Les tentatives de porter, sans de très bonnes raisons, un outil C qui marche bien en Rust ne sont pas légion. Si tu as l'impression qu'on en parle beaucoup, c'est la plupart du temps parce que les supporters du C et du C++ remontent en boucle les mêmes cas particuliers. Généralement les gens qui connaissent Rust sont les premiers à recommander de ne pas le faire, à moins que le besoin d'un réécriture se fasse vraiment sentir.

En ce qui concerne Anthropic, je suppose que tu parles de Bun, mais c'est une suite d'outils pour le langage TypeScript, écrite en Zig. Pas de rapport avec C. Je dirais même qu'une partie de la problématique est inversée, vue que Zig est un langage bien plus niche que le Rust.
Cependant, c'est vrai que cette migration n'était pas pas indispensable, surtout que ça a été fait de manière précipitée à coup d' IA générative quasiment pas supervisée, ce qui est critiqué en premier lieu par la communauté Rust.

[fdecode]

Il y'a 10ans je disais la même chose avec la "secte" javascript, tous le monde voulaient tous recoder en javascript.

Je ne code pas en javascript/typescript, mais cela reste incontournable dans le developpement web, me semble-t-il.

Tous ça sait d'ailleurs terminé à du web assembly.

Cela cible des choses différentes. C'est très bien pour faire des modules bas niveau ou pour compiler de l'existant, Rust, C/C++ ou Zig notamment.

Perso je conseil plutôt de partir sur du des technos de niche à forte valeur : Scala, Clojure ou Zig

On est vraiment dans des technos de niche, là.
Et pour ce qui est de Scala, on est davantage dans l'effet de mode que JavaSctipt qui a une porté universelle dans le monde web. Heureusement qu'il lui reste une implémentation importante dans le domaine des grandes données et du distribué JVM.
J'aime bien ce langage ceci étant, et il a contribué à mon basculement dans le monde Rust (et oui...).

[calvaire]

On est vraiment dans des technos de niche, là.
Et pour ce qui est de Scala, on est davantage dans l'effet de mode que JavaSctipt qui a une porté universelle dans le monde web. Heureusement qu'il lui reste une implémentation importante dans le domaine des grandes données et du distribué JVM.
J'aime bien ce langage ceci étant, et il a contribué à mon basculement dans le monde Rust (et oui...).

Je parle d'un point de vue carrière/business, pas de la technique dont je m'en fou.
De ce que je constate c'est qu'il y a une vraie déconnexion je trouve entre la hype technique autour de Rust et la réalité du marché de l'emploi local. En dehors des licornes ou des contrats d'envergure internationale en remote, les salaires en Europe restent calqués sur du C/C++ traditionnel. Vu la courbe d'apprentissage du langage (la gestion de la mémoire, le borrow checker.....), le retour sur investissement est difficile à justifier.

Si le but est d'optimiser sa carrière et sa rémunération en choisissant une niche, le paradigme fonctionnel reste bien plus standard et rentable. Miser sur la stack Scala (avec ZIO) ou Clojure offre un bien meilleur levier de négociation financière, car les profils qualifiés y sont extrêmement rares et recherchés.
C'est pour moi le but 1er pour apprendre/se former sur des nouvelles technos car sinon je n'en vois pas l’intérêt... mais comme d'hab je vais avoir des réponses avec des vieux poncifs de type pour la culture/curiosité, tout ne tourne pas autour de l'argent dans la vie et blablabla.

Maintenant je ne suis pas medium, je parle des grilles de salaire des entreprises que je connais bien en zone europe/asia pour 2025/2026, dans 5ans ca peut changer. Mais n'allez pas faire du rust en croyant que vous allez avoir un meilleur salaire a l'heure ou j'écris ces lignes.

[fdecode]

Je parle d'un point de vue carrière/business, pas de la technique dont je m'en fou.

J'ai compris cela. Mais l'impact futur de langages de niche comme Scala reste difficile à évaluer, me semble-t-il. Je ne fonderais pas une carrière là-dessus au delà du moyen terme.
Scala ne s'est pas vraiment sorti du monde JVM (les alternatives js et LLVM proposées n'ont pas beaucoup d'impact), ce que je trouve un peu embêtant. L'écosystème JVM va rester longtemps, mais sa place s'érode.

il y a une vraie déconnexion je trouve entre la hype technique autour de Rust et la réalité du marché de l'emploi local.

Alors cet hypothétique "forcing" de Rust n'est qu'une broutille dont il est inutile de s'inquiéter.

tout ne tourne pas autour de l'argent dans la vie

Cela ne fait pas trop sens de devenir développeur pour l'argent, surtout face aux capacités de codage émergentes des IA. Il y a des formations qui payent mieux.

Mais n'allez pas faire du rust en croyant que vous allez avoir un meilleur salaire a l'heure ou j'écris ces lignes.

Cette question ne se pose pas pour ma part. Mais je suis assez d'accord sur ce point, et à l'heure actuelle.

[Mathis Lucas]

Zig interdit les contributions de code généré par l'IA, car elles sont « systématiquement de mauvaise qualité »
le projet affirme qu'il veut préserver le temps précieux des réviseurs humains

Le président de la fondation Zig a instauré une interdiction stricte concernant l'usage de l'IA pour les contributions au code source du langage. Andrew Kelley qualifie ces soumissions automatisées de déchets numériques dépourvus de valeur, car elles surchargent inutilement les réviseurs humains déjà très sollicités. Contrairement aux Big Tech, ce projet open source privilégie le mentorat et le développement des compétences personnelles plutôt que la productivité pure. Cette politique radicale vise à protéger la qualité logicielle tout en évitant le temps perdu à corriger des erreurs générées par des machines. Zig n'est pas le premier à emprunter ce chemin.

Zig est un langage de programmation système conçu pour apporter des améliorations polyvalentes au langage de programmation C. Il s'agit d'un logiciel libre et open source, publié sous licence MIT. Les différences avec le langage C concernent le flux de contrôle, les appels de fonction, l'importation de bibliothèques, la déclaration de variables et la prise en charge de l'Unicode. De plus, le langage Zig n'utilise ni macros ni instructions de préprocesseur.

Parmi les fonctionnalités empruntées aux langages modernes, on trouve l'ajout de types de données de programmation générique à la compilation, et un petit ensemble de nouvelles directives de compilation permettant d'accéder aux informations sur ces types à l'aide de la réflexion.

Perte de temps critique pour les mainteneurs très sollicités

Zig est géré par une association à but non lucratif de type 501(c)(3) et un réseau de contributeurs. Tout développeur peut soumettre du code à son référentiel, à condition de respecter un code de conduite. Zig vient d'ajouter une nouvelle règle interdisant la soumission de code généré par l'IA. La politique prévient : aucun contenu généré par une IA, aucune paraphrase issue d'une IA, aucun élément édité, issu d'une réflexion ou débogué par une IA.

Andrew Kelley, le président de la fondation Zig, justifie cette décision en qualifiant les contributions faites par l'IA de déchets systématiques n'ayant aucune valeur. Selon lui, ces soumissions ont en réalité une valeur négative, car elles gaspillent le temps de la petite équipe chargée d'examiner le code. Le processus de révision constitue le principal goulot d'étranglement du projet, l'équipe étant déjà débordée par le nombre élevé de requêtes en attente.

Ces ajouts générés par l'IA ralentissent considérablement le groupe et proviennent généralement de contributeurs de passage qui ne s'investiront pas durablement dans le projet. « Les gens nous envoient des contributions qui n'ont absolument aucune valeur. Elles ont même une valeur négative, car elles font perdre du temps à l'équipe en révision », a déclaré Andrew Kelley dans un récent épisode du podcast de la société de logiciels JetBrains.

Au moment de l'enregistrement, Andrew Kelley a indiqué que Zig comptait 200 pulls requests en attente. « Nous avons fait perdre du temps à tout le monde », a-t-il déclaré. Bien que Zig soit relativement modeste comme langage de programmation, son impact a été considérable. Ce langage a notamment servi à créer Bun, qui a ensuite été racheté par Anthropic. L'interdiction de l'IA a par la suite provoqué de vives tensions entre Bun et Zig.

Priorité à l'apprentissage plutôt qu'à la productivité intense

Le code généré par l'IA fait fureur dans la Silicon Valley, porté par des outils comme Claude Code d'Anthropic ou Codex d'OpenAI. Certain l'utilisent pour éditer leur code, d'autres pour le rédiger entièrement. Les Big Tech se sont fixé des objectifs ambitieux quant à la part de code produite par l'IA. Mais contrairement aux géants de la tech qui cherchent à maximiser leur efficacité grâce à l'IA, la mission fondamentale de Zig repose sur le mentorat.

Zig n'a pas pour mission d'atteindre une efficacité maximale. « Nous essayons tous de nous améliorer en programmation. Les personnes qui envoient des pulls requests générées par l'IA ne contribuent pas à cet objectif », a déclaré le président Andrew Kelley. Ces développeurs IA sont des « contributeurs occasionnels », c'est-à-dire ceux qui peuvent soumettre une ou deux demandes de fusion, mais qui ne rejoindront jamais l'équipe principale.

Bref, l'IA est banni. Andrew Kelley a expliqué que s'il avait déclaré que seules les pulls requests de « bonne qualité » générées par l'IA seraient acceptées, les réviseurs auraient dû les évaluer une par une. « Si je dis qu'aucune ne sera acceptée, alors c'est une politique très facile à appliquer », a-t-il déclaré.

Plusieurs projets ont interdit les rapports générés par l'IA

L'adoption des outils d'IA par les plateformes telles que HackerOne pose un problème majeur à la communauté des logiciels libres : la multiplication de rapports de vulnérabilités générés par des outils d'IA, souvent erronés ou trompeurs, qui submergent les mainteneurs. Les fabricants de modèles d'IA s'attendent à ce que l'IA aide les développeurs à détecter les bogues beaucoup plus rapidement afin de jouir de plus de temps pour innover.

Mais il s'avère que ces rapports sont en majorité le résultat des hallucinations de l'IA, et donc inutiles. Seth Larson, développeur de sécurité en résidence à la Python Software Foundation, a soulevé la question dans un billet de blogue en décembre 2024. Il a exhorté les personnes qui signalent des bogues à ne pas utiliser de systèmes d'IA pour la chasse aux bogues. Selon lui, les systèmes d'IA actuels ne sont pas fiables dans ce contexte.

« J'ai remarqué une augmentation des rapports de sécurité de qualité extrêmement médiocre, spammés et hallucinés par les LLM dans les projets open source. À première vue, ces rapports de bogue semblent potentiellement légitimes et nécessitent donc du temps pour être réfutés », écrivait-il, rappelant les résultats similaires obtenus par le projet cURL en janvier 2024. Début 2025, c'est le créateur du projet cURL qui a exprimé son ras-le-bol.

Dans certains cas, les auteurs des signalements erronés sont des personnes novices qui testent des IA sur du code. Ou pire, elles utilisent les rapports générés par l'IA pour tenter d'obtenir des récompenses financières via des programmes de primes aux bogues sans fournir de véritables contributions.

Par exemple, quatre rapports de vulnérabilité malavisés ont été publiés par une personne apparemment à la recherche d'une réputation ou d'une prime de détection de bogues. « L'une des façons de s'en rendre compte, c'est que le rapport est toujours très agréable. Formulé de manière agréable, en anglais parfait, poli, avec de jolis points... un humain ordinaire ne le ferait jamais de cette manière dans son premier rapport », a déclaré Daniel Stenberg.

Vouch : un système de gestion de la confiance communautaire

Ces dernières années, le nombre de personnes utilisant les outils d'IA pour générer du code au lieu de l'écrire eux-mêmes a augmenté. Cependant, une grande partie du code généré par l'IA est de mauvaise qualité. En conséquence, le coût croissant de l'élimination du code de mauvaise qualité généré par l'IA est devenu un problème épineux pour les projets open source disposant déjà de peu de ressources et reposant sur la coopération communautaire.

Pour remédier à ce problème, le développeur de logiciels Mitchell Hashimoto a lancé un système appelé « Vouch » qui élimine les personnes soumettant du code de mauvaise qualité et maintient la qualité des projets open source. Il se dit lasser de jouer au chat et à la souris avec les rapports de mauvaise qualité.

Vouch introduit un modèle de confiance explicite. Un contributeur ne peut soumettre une pull request que s’il a été préalablement approuvé par un contributeur déjà reconnu comme fiable. « La légitimité n’est plus implicite, mais formalisée, ce qui inverse la logique par défaut de l’ouverture totale ». Vouch repose sur des actions GitHub. Une action vérifie automatiquement si l’auteur d’une pull request figure dans la liste des contributeurs approuvés.

D’autres actions GitHub permettent d’ajouter ou de retirer des contributeurs, en s’appuyant sur des décisions humaines documentées dans le dépôt. Les informations de confiance sont stockées dans un fichier texte unique, versionné avec le projet. Ce choix favorise la transparence, l’auditabilité et l’automatisation.

Vouch permet de réutiliser ces listes entre projets, ouvrant la voie à des réseaux de confiance partagés entre dépôts ayant des exigences similaires. La mise en œuvre est générique et peut être utilisée par n'importe quel projet sur n'importe quelle forge de code, mais le développeur fournit une intégration GitHub prête à l'emploi via les actions GitHub et l'interface CLI. Le projet Vouch vise à faire face à l'afflux de pulls requests de mauvaise qualité.

Source : Andrew Kelley, président de la fondation Zig

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de l'interdiction de l'IA par le projet open source Zig ?

Voir aussi

Vouch : un système visant à maintenir la qualité de l'open source face à l'afflux de pulls requests de mauvaise qualité générées par l'IA, il permet de gérer la confiance dans les contributeurs à un projet

Le projet open source cURL interdit les rapports de bogue inutiles générés par l'IA : « nous n'avons toujours pas vu un seul rapport de sécurité valide rédigé avec l'aide de l'IA »

Les mainteneurs de logiciels libres sont noyés dans des rapports de bogues inutiles rédigés par l'IA. « Ces systèmes ne sont pas encore capable de comprendre le code », estime un développeur

[Uther]

Je parle d'un point de vue carrière/business, pas de la technique dont je m'en fou.

Sauf que le sujet c'était précisément l'intérêt technique de Rust dans le cadre du noyau Linux. Tu as tout a fait le droit de te foutre du coté technique, mais là c'est le sujet de base.

Si le but est d'optimiser sa carrière et sa rémunération en choisissant une niche, le paradigme fonctionnel reste bien plus standard et rentable. Miser sur la stack Scala (avec ZIO) ou Clojure offre un bien meilleur levier de négociation financière, car les profils qualifiés y sont extrêmement rares et recherchés.

De nos jours Scala et Clojure sont tellement niche que ça me parait risqué comme plan carrière, c'est possiblement bien payé, encore faut il trouver un poste intéressant avec. Et dans le cadre du sujet, à savoir le noyau Linux, ces langages sont juste inenvisageables car pas assez bas niveau.
Un intérêt de Rust est justement qu'il permet d’intégrer le paradigme fonctionnel bien mieux que C et C++ dans des domaines où la plupart des langage fonctionnels sont inenvisageables

[fdecode]

Un intérêt de Rust est justement qu'il permet d’intégrer le paradigme fonctionnel bien mieux que C et C++ dans des domaines où la plupart des langage fonctionnels sont inenvisageables

Je ne me suis pas senti trop dépaysé en passant à Rust après quelques temps à travailler avec Scala (version 2).
Pour ce qui est du fonctionnel, j'avais justement apprécié les capacités de pattern matching de Rust, se basant essentiellement sur la structure de donnée, et donc favorisant une optimisation du code par le compilateur (sans surcharge d'abstraction à l'exception de certains tests conditionnels ou certaines gestions de l'énumération dans le matching).
A contrario, le pattern matching de Scala passe beaucoup par des unapply, et n'est pas aussi direct. Même les 'case class' de Scala restent des classes JVM, et cela est un peu plus lourd que les structures Rust qui sont directement matchables tout en étant très simples et proches du C.
Alors Scala est plus concis du point de vue de la programmation fonctionnelle, certes, mais je m'y retrouve bien en Rust.
Les deux langages proposent des mécanismes haut niveau, incluant:
- le fonctionnel,
- Des mécanismes de trait différents, mais sur lequel Rust fait reposer sa programmation par héritage (programmation orientée traits, à comportements orthogonaux aux données).
- Des langages fortement typés mais avec un mécanisme important d'inférence de type (Rust étant plus limité que Scala sur ce point mais avec plus de lisibilité; il faut très bien connaitre ses règles de sucre grammatical en Scala...),
- Un fort impact de la généricité par des variables de type et cette généricité est bien maîtrisée (rien à voir avec un template). Le conditionnement des types en Rust est incroyable, et je pense que ça va plus loin que Scala. Par contre, Scala permet des variables de type du second ordre... Même si les GAT (Generic Associated Types) de Rust offrent quelques possibilités.
- Des systèmes de macros agissant sur l'AST,
- Une programmation multithread/asynchrone facile (e.g. Scala: Future basé GC et les mécanismes de multithread de la JVM ; Akka/Pekko ; Flink, Spark, ... ; je ne connais pas ZIO /**/ Rust: noGC ; multithread ou async (concurrence) ; channels ; rayon ; tokio ; ractor ...).
Les deux langages sont élégants de mon point de vue, et la concision de Scala est imbattable. Et on n'oubliera pas le côté DSL-friendly de Scala grâce à ses sucreries grammaticales (à l'excès parfois).
Mais ce qui avait emporté mon choix, c'est que Rust m'a offert des fonctionnalités qui me paraissent proches de Scala tout en étant bas niveau et avec un travail direct en mémoire, grâce à la sémantique de prêt... Honnêtement, ça m'avait impressionné à l'époque.

[fdecode]

Les tentatives de porter, sans de très bonnes raisons, un outil C qui marche bien en Rust ne sont pas légion. Si tu as l'impression qu'on en parle beaucoup, c'est la plupart du temps parce que les supporters du C et du C++ remontent en boucle les mêmes cas particuliers. Généralement les gens qui connaissent Rust sont les premiers à recommander de ne pas le faire, à moins que le besoin d'un réécriture se fasse vraiment sentir.

Ces montages en boucles viennent aussi de certains préjugés. C'est à croire que certains pensent que les personnes qui programment en Rust ont découvert la programmation avec Rust et veulent refaire le monde en oubliant le passé... Et bien non, beaucoup d'entre nous ont un historique de programmation, et les bons réflexes qu'on avait en faisant du C ou du C++ à une certaine époque, puis en utilisant d'autres langages, n'ont pas disparu depuis qu'on fait du Rust.