Discussion :

[Stéphane le calme]

Rust a-t-il atteint son plafond de popularité ? Le langage recule de trois places dans l'index TIOBE d'avril 2026,
son PDG évoque une « courbe d'apprentissage difficile pour les développeurs non experts »

Depuis quelques semaines, une question circule dans les cercles de développeurs : Rust aurait-il atteint sa vitesse de croisière, voire son plafond ? Le PDG de l'index TIOBE l'affirme, s'appuyant sur un recul de trois positions entre janvier et avril 2026. Mais derrière cette lecture statistique se cache un tableau bien plus complexe et une leçon sur la façon dont on mesure l'influence réelle d'un langage.

Selon Paul Jansen, PDG de TIOBE, Rust a atteint son plus haut historique en janvier 2026, à la 13^e place de l'index. Trois mois plus tard, il est retombé à la 16^e position. Pour le dirigeant de la société d'évaluation de la qualité logicielle, cela suggère un plafonnement de l'adoption. L'argument principal avancé : la courbe d'apprentissage jugée rédhibitoire pour les développeurs non spécialistes limiterait l'expansion vers un public grand public.

Et Paul Jansen de déclarer :

« Rust est le plus jeune langage du top 20 de l'indice TIOBE. Il y a fait son entrée en juin 2020 et était alors pressenti pour intégrer le top 10, s'imposant comme un concurrent sérieux pour C et C++. C'était il y a près de six ans. Depuis, Rust a progressé régulièrement dans le classement, atteignant même sa meilleure position historique (13e) en début d'année. Cependant, trois mois plus tard seulement, il a chuté à la 16e place. Cela suggère que son taux d'adoption pourrait plafonner.

« Une explication possible est que, malgré sa capacité à produire du code très performant et sûr, Rust reste difficile à apprendre pour les programmeurs non experts. Si les spécialistes des domaines critiques en termes de performances sont prêts à investir dans la maîtrise du langage, une adoption plus large par le grand public semble plus complexe.

« Par conséquent, la popularité croissante de Rust semble se stabiliser et l'objectif d'intégrer le top 10 paraît désormais plus lointain. »

Mais avant de tirer des conclusions, il convient de comprendre ce que mesure réellement l'index TIOBE et ce qu'il ne mesure pas. L'index est calculé à partir du nombre de requêtes sur plus de vingt moteurs de recherche populaires, dont Google, Amazon, Wikipedia et Bing. Il ne prétend pas mesurer le nombre de lignes de code écrites dans un langage, ni la satisfaction des développeurs, ni l'usage en production.

Cette méthodologie a toujours posé problème. Comme le souligne un observateur, un langage dont les développeurs trouvent leurs réponses via un assistant IA plutôt qu'un moteur de recherche verra mécaniquement son score TIOBE s'éroder, indépendamment de son adoption réelle. À l'heure où GitHub Copilot, Claude ou ChatGPT répondent directement aux questions techniques, l'effet est loin d'être négligeable. Un observateur l'a formulé clairement : l'index TIOBE est très sensible aux variations des résultats des moteurs de recherche et aux biais introduits par les LLM, qui court-circuitent l'une des principales sources de données de l'index.

Par ailleurs, un simple coup d'œil au tableau révèle des absurdités qui fragilisent la crédibilité de l'outil : Delphi/Object Pascal figure en 10e position, devant Go (15e) et Rust (16e). Voir un langage dont l'heure de gloire remonte au tournant des années 2000 dépasser deux des technologies les plus actives de la décennie suffit à relativiser fortement la portée du classement.

Ce que les autres indices révèlent

Fort heureusement, TIOBE n'est pas le seul outil disponible, et les données alternatives dressent un portrait sensiblement différent.

RedMonk, qui croise le nombre de dépôts GitHub avec l'activité sur Stack Overflow, classe Rust en 19^e position dans son édition de janvier 2025. RedMonk note que c'est l'un des classements les moins mouvementés en quinze ans d'existence de l'index, signe de stabilisation plutôt que de recul. Pour un langage jeune qui s'attaque à un segment aussi technique que la programmation systèmes, se maintenir dans un top 20 mondial représente déjà une performance.

Stack Overflow Developer Survey, qui interroge chaque année des dizaines de milliers de développeurs actifs, raconte une histoire encore plus favorable. Pour la neuvième année consécutive, Rust a été désigné langage le plus admiré par les développeurs en 2025, avec un taux d'approbation de 72 %. Son gestionnaire de paquets Cargo a lui aussi été élu outil le plus apprécié parmi les outils de développement cloud et d'infrastructure. Un taux d'admiration record sur neuf ans n'est pas le portrait d'un langage qui s'essouffle, c'est celui d'un langage que ceux qui l'utilisent ne veulent plus lâcher.

JetBrains, dans son State of Developer Ecosystem annuel, estime que Rust comptait 2,27 millions de développeurs actifs en 2025, avec une croissance de 35 % des offres d'emploi sur l'année selon d'autres agrégateurs de données sectorielles. Sur GitHub, les dépôts Rust ont progressé de 89 % en glissement annuel en 2025, soit la plus forte croissance de tous les langages suivis. Ces chiffres témoignent d'une vitalité réelle de l'écosystème, que le filtre TIOBE ne capture tout simplement pas.

Une adoption institutionnelle sans précédent

Bien au-delà des sondages, la véritable mesure de la santé de Rust se lit dans les décisions structurelles prises par les acteurs qui comptent.

Fin 2025, au Maintainer Summit de Tokyo, le noyau Linux a officialisé l'intégration permanente de Rust. Le responsable du projet Rust for Linux, Miguel Ojeda, a confirmé que « l'expérimentation est terminée » : Rust est désormais là pour de bon dans le noyau. Greg Kroah-Hartman, l'un des mainteneurs les plus influents du projet Linux, a lui-même reconnu que les pilotes écrits en Rust s'avéraient plus sûrs que leurs équivalents en C. Android 16, basé sur le noyau Linux 6.12, embarque déjà l'allocateur mémoire ashmem écrit en Rust, déployé sur des millions d'appareils.

Microsoft compte aujourd'hui plus de 188 000 lignes de code dans le noyau Windows et dans DirectWrite réécrites en Rust. Mark Russinovich, directeur technique de Microsoft Azure, a déclaré lors de RustConf 2025 que « Rust s'infiltre dans l'infrastructure centrale de Microsoft et cela va continuer à s'accélérer ». Cloudflare, AWS, Discord et Google ont tous des charges de production significatives en Rust. Cloudflare a notamment développé Infire, un moteur d'inférence LLM en Rust offrant jusqu'à 7 % de performances supplémentaires par rapport à vLLM.

La pression ne vient pas seulement de l'industrie. La CISA et la NSA ont conjointement publié en 2025 un rapport enjoignant aux développeurs et opérateurs d'infrastructures critiques d'adopter des langages à sécurité mémoire, citant Rust en tête de liste. Le rapport souligne que la sécurité mémoire « ne saurait être surestimée » et évalue entre 66 % et 75 % la proportion de vulnérabilités critiques trouvant leur origine dans des erreurs mémoire en C et C++. La CISA avait par ailleurs fixé au 1^er janvier 2026 une échéance pour que les organisations publient des feuilles de route vers des langages à sécurité mémoire et dans les faits, plus de 296 entreprises avaient signé l'engagement « Secure by Design », dont GitHub et Google, citant quasi systématiquement Rust comme outil de conformité.

L'IA comme accélérateur, non comme frein

Une thèse circule chez certains observateurs : l'essor du « vibe coding » et de la génération de code par IA rendrait Rust moins pertinent, puisque l'IA écrirait pour vous du code en Python ou en JavaScript. C'est l'inverse qui semble se dessiner.

En janvier 2026, le directeur principal du plaidoyer développeur de GitHub a soutenu que l'IA poussait précisément les développeurs vers les langages typés statiquement, car les types « interceptent exactement la classe de surprises que le code généré par IA peut parfois introduire ». Une étude académique de 2025 a établi que 94 % des erreurs de compilation dans le code produit par des LLM étaient des erreurs de vérification de types. Dans ce contexte, le système de types et le vérificateur d'emprunts de Rust ne sont plus seulement des outils de rigueur pour experts, ils deviennent un filet de sécurité indispensable pour valider du code généré automatiquement.

DARPA a d'ailleurs lancé le programme TRACTOR (Translating All C to Rust), doté de 5 millions de dollars pour développer des méthodes automatisées de traduction de code C vers Rust en combinant LLM et méthodes formelles. L'IA n'est donc pas en train de marginaliser Rust, elle est en train de devenir l'un de ses principaux vecteurs d'adoption à grande échelle.

Le vrai débat : niche élitiste ou infrastructure de demain ?

Les critiques légitimes de Rust ne manquent pas, et elles méritent d'être prises au sérieux. La courbe d'apprentissage reste abrupte, en particulier le système d'emprunt (borrow checker) qui déconcerte même des développeurs expérimentés. Plusieurs développeurs soulignent que l'écosystème de paquets Cargo / crates.io présente des risques de chaîne d'approvisionnement analogues à ceux de npm, avec des dépendances transitives nombreuses et peu auditées. Des attaques par typosquatting et des charges malveillantes dans des crates Web3 ont affecté plus de 23 000 téléchargements lors des deux incidents les plus importants de 2025.

Rust souffre également de l'absence de spécification formelle du langage, contrairement à C++, ce qui rend certaines entreprises réticentes à y engager des investissements massifs à long terme. Et son ABI instable complique l'intégration de bibliothèques propriétaires en Rust pur.

Mais aucun de ces obstacles ne remet en cause la trajectoire d'ensemble. Rust n'a pas besoin de supplanter Python pour être stratégique. Son terrain d'élection (systèmes d'exploitation, noyaux, pilotes, hyperviseurs, composants cryptographiques, moteurs WebAssembly) est précisément celui où la fiabilité et la sécurité priment sur la vitesse de développement. Sur ce segment, il n'a aujourd'hui aucun concurrent sérieux.

La vraie question n'est donc pas de savoir si Rust va entrer dans le top 10 de TIOBE. C'est de savoir si Rust va continuer à s'imposer là où les défaillances logicielles ont des conséquences réelles. Et sur ce point, les signaux sont univoques.

Ces tendances ne sont pas représentatives du paysage français

Comme souligné plus haut, l'index TIOBE Programming Community est un indicateur de la popularité des langages de programmation. L'index est mis à jour une fois par mois. Les notes sont basées sur le nombre d'ingénieurs qualifiés dans le monde, les cours et les fournisseurs tiers. Les moteurs de recherche populaires tels que Google, Bing, Yahoo!, Wikipédia, Amazon, YouTube et Baidu sont utilisés pour calculer les notes.

Il est important de noter que l'index TIOBE ne concerne pas le meilleur langage de programmation ou le langage dans lequel la plupart des lignes de code ont été écrites. L'index peut être utilisé pour vérifier si vos compétences en programmation sont toujours à jour ou pour prendre une décision stratégique sur le langage de programmation à adopter lors du démarrage de la construction d'un nouveau système logiciel.

Emploi informatique : les langages les plus demandés et les mieux payés
Portail Emploi de Developpez.com

Sources : TIOBE, RedMonk, Stack Overflow Developper Survey

Et vous ?

Les indices de popularité comme TIOBE ont-ils encore un sens à l'ère des assistants de code IA, qui modifient profondément les comportements de recherche des développeurs ?

L'injonction gouvernementale (CISA, NSA, Maison-Blanche) à adopter des langages à sécurité mémoire est-elle une réponse technique légitime ou un alignement trop complaisant sur les intérêts des géants du cloud membres de la Rust Foundation ?

La difficulté d'apprentissage de Rust est-elle un obstacle conjoncturel, appelé à s'atténuer avec de meilleures formations et des outils IA, ou un plafond structurel qui condamnera le langage à rester une affaire de spécialistes ?

Zig, concurrent direct sur le segment de la programmation systèmes, peut-il menacer la position de Rust, ou les deux langages occupent-ils des niches suffisamment différentes pour coexister ?

Voir aussi :

L'IA abaisse les barrières mais amplifie les mauvais patterns : les données Octoverse de GitHub révèlent la mécanique silencieuse qui redistribue les parts de marché entre langages de programmation

« Les avions F-35 bannissent 90 % des fonctionnalités du C++ pour obtenir un code sûr », selon une Googler dont le partage d'expérience suscite des appels d'observateurs à passer au langage Rust

[koyosama]

Tu m'étonnes, il y a presque pas de tutorial pour débutant. Sauf les docs officiels qui sont chiant et longs à lire.

[d_d_v]

C'est surtout que la très grande majorité des entreprises n'en ont rien à faire de la qualité et sécurité du code, donc pourquoi s'infliger l'utilisation d'un langage aussi contraignant ?

[Uther]

La qualité du code ça a un impact sur la maintenabilité, et c'est un argument auquel certains sont sensible.

[smarties]

En tout cas je vois beaucoup de CLI et TUI qui sont développés en Rust, souvent des réécritures (sans doute pour se former) pour avoir quelque chose de plus léger ou avec moins de dépendances installé (Python, JS) vu qu'avec Rust on met un maximum dans le binaire.

Niveau maintenance, quand ça fonctionne on peut laisser son projet dans un coin et généralement faire un petite MAJ des dépendances une fois par an. En plus avoir la possibilité de mettre ses tests dans le même fichier que ce qui est testé c'est pratique !

[imperio]

Tu m'étonnes, il y a presque pas de tutorial pour débutant. Sauf les docs officiels qui sont chiant et longs à lire.

Il y a le livre officiel : https://doc.rust-lang.org/stable/book/ (que je n'aime pas beaucoup mais c'est une histoire de préférence personnelle).
Après en français il y a : https://blog.guillaume-gomez.fr/Rust

[JPLAROCHE]

bonjour, ça fait 6 mois que j'ai entamé ma conversion de mon projet ZIG en Rust .
Au début, c'était l'aventure, histoire de voir ce que je pouvais en tirer, Puis est venu la conception pour tirer parti du langage Rust, puis est venu les corrections de mon projet dut au langage Rust, puisje n'en suis toujours pas aux réflexions automatiques,
j'ai trouvé parfois plus complexe Rust , mais aussi parfois plus cohérent et plus simple.

je me fais aider par IA Mistral pour m'expliquer certain concept, avec des exemples, pas toujours facile de suivre l'IA, mais c'est intéressant et enrichissant.

j'ai dût en même temps choisir un IDE et le mettre à ma main (j'avais fait pareil avec Zig) j'aime que l'outil soit ciblé, je ne veux qn'un truc à tout faire. Ça m'a pris 2 mois sur les 6, mais pas à 100%.


je n'ai pas de contrainte je suis à la retraite (gros avantage car pas de pression) mais il m'arrive pour résoudre un problème que ne je passe une grosse semaine avec de grosses heures pleine ou la nuit devient toute petite.

parce que je suis un vieux et que je ne lâche pas les choses comme ça .

Je n'aime pas me servir de lib toute faite à tout vas, donc puisque je suis un informaticien, je dois être capable de fabriquer mes propres lib. Bien-sûr qu'il m'arrive d'utiliser, mais avec une étude des modules proposée et si je trouve qu'ils peuvent-être un gros plus alors je prends.

Cela m'amène à faire une petite comparaison avec Zig, zig je peux l'utiliser s'en lib extérieur au langage , je n'y suis pas arrivé pour le moment avec Rust ( je souhaite que cela soit dût à mon manque expérience).

un exemple , avec Zig il y a F128 cela m'a permis de gérer les nombres décimaux façon finance ou gestion d'entreprise, avec Rust j'ai été obligé de prendre le parti d'utiliser I128 avec un peu plus de complexité afin de pouvoir gérer 34 chiffres

pour la gestion du terminal j'ai pris une lib de base toute petite, j'aurai dû la réécrire, mais c'est dommage que cela ne fasse pas partie du langage.

j'aime dans ce langage l'intégrité référentiels, ça évite beaucoup d'erreur , bon ça ne change pas le paradigme que nous propose IBM avec OS400 ou le programme ne plante pas d'où je suis responsable du pot, mais pas du contenu. Même si vous avez mis des pare-fou (lol) si la personne saisie la mauvaise quantité commandée !!!!!!

j'aime cargo, je le trouve simple, OUI et NON mais sa philosophie dans les docs ne sont pas à la hauteur ( que Rust n'en prenne pas ombrage, j'ai du mal aussi à créer de A-z et écrire la doc, car pour le concepteur tout parait évident).


Suite au prochain numéro mes 6 mois ne m'ont pas fait de moi un expert en Rust ( heureusement sinon Rust aurait été le Basic).

[JPLAROCHE]

je pourrais rajouter les livres que l'on trouve sur le marché, trop touffu.... Bon pour Zig il n'y en tellement peu, mais le langage n'est pas en version 1

souvent les exemples sont d'une simplicité que l'on a l'impression d'être un idiot, alors que l'on aimerait des exemples avec de vrais projets . Je me dis que c'est une lacune sur lequel Rust devrait ce penché.

Le system c'est bien, ils ont prouvé que cela fonctionne maintenant, il devrait penser "entreprise" par exemple la GESTION et je peux vous dire que là, il y a des réels problèmes et que ce n'est pas uniquement de la gestion de BD.

[Bardaz]

C'est surtout que la très grande majorité des entreprises n'en ont rien à faire de la qualité et sécurité du code, donc pourquoi s'infliger l'utilisation d'un langage aussi contraignant ?

J'ajoute que les entreprises suceptibles de passer à Rust ont des outils similaires avec les dernières versions de C++ et le module Fil C . Pourquoi réapprendre un langage quand on a déjà les devs et les outils.

Rust a eu le mérite de remettre le débat autour de la sécurité au centre de la table.

[Uther]

un exemple , avec Zig il y a F128 cela m'a permis de gérer les nombres décimaux façon finance ou gestion d'entreprise, avec Rust j'ai été obligé de prendre le parti d'utiliser I128 avec un peu plus de complexité afin de pouvoir gérer 34 chiffres

Les flottants 128bit n'étant à ma connaissance pas gérés par le matériel, passer par une bibliothèque ou le langage lui même ne fait pas une grande différence, dans tout les cas il y aura un supplément de code embraqué, c'est juste que Zig embarque sa propre bibliothèque.
D'ailleurs je ne pense pas que les flottants, même à 128 bits, soient une bonne idée pour de la finance, tu vas quand même te retrouver avec des arrondis qui paraissent bizarre. En général on utilise plutôt les types décimaux, qui ne sont pas gérés nativement par la plupart des langages y compris Zig.

[fdecode]

un exemple , avec Zig il y a F128 cela m'a permis de gérer les nombres décimaux façon finance ou gestion d'entreprise, avec Rust j'ai été obligé de prendre le parti d'utiliser I128 avec un peu plus de complexité afin de pouvoir gérer 34 chiffres

f128 et f16 existent en nightly.
https://doc.rust-lang.org/std/primitive.f128.html
Dans les crates vous trouverez d'autres implémentations, p. ex. f256 et f512 (pas de trigo).

Mais comme cela a été mentionné par Uther, ces réels f128 et plus ne sont pas pris en charge au niveau matériel.

[OuftiBoy]

Uther,

J'espère que tout va pour le mieux pour toi

Mais je ne sais pas pourquoi, dès que j'ai vu le topic, j'étais certains à 100% que tu réagirais tôt ou tard Je ne me suis pas trompé .

Les flottants 128bit n'étant à ma connaissance pas gérés par le matériel, passer par une bibliothèque ou le langage lui même ne fait pas une grande différence, dans tout les cas il y aura un supplément de code embraqué, c'est juste que Zig embarque sa propre bibliothèque.

Tu as parfaitement raison.

D'ailleurs je ne pense pas que les flottants, même à 128 bits, soient une bonne idée pour de la finance, tu vas quand même te retrouver avec des arrondis qui paraissent bizarre. En général on utilise plutôt les types décimaux, qui ne sont pas gérés nativement par la plupart des langages y compris Zig.

Tu as encore ici raison, pour avoir une maîtrise des "arrondis", il faut utiliser des "BCD" à l'ancienne, qui sont des "FPN" (Fixed-Point-Number). On utilise souvent les FPN dans l'embarqué, car ils sont justement exempts d'erreurs d'arrondis "non maîtrisés" des types "float" ou "double" du C/C++. Ils ont en plus l'avantage, si le CPU n'intègre pas une FPU (Floating-Point-Unit), ce qui encore très souvent le cas dans des petits micro-contrôleurs, d'être très éfficient (en terme de vitesse), car un n'utilise que des entiers pour les représenter. Je suis d'ailleurs étonné que nombres de nouveaux langages ne les intègrent pas nativement - PS: Ils sont bien présents dans mon petit compilateur pour mon petit langage Home (https://www.developpez.net/forums/d2...uveau-langage/).

Pour ce développement, j'ai étudié de près (mais cela remonte déjà à plusieurs mois) ce que proposait Rust. Sur le plan 'technique", Rust fait très bien le taf, malgré des contraintes que l'équipe développant Rust se devait de prendre en compte.

Mais utiliser Rust et profiter de ses avantages n'est vraiment pas simple, même si on a déjà un passé important de développeur. Il y'a moyen de faire plus simple, mais il faut partir d'une feuille blanche. Toute cette problématique a maturé dans ma petite boîte grise, et je vais bientôt me confronter à la pratique pour l'intégration de la gestion dynamique de la mémoire (et de sa sécurité) et voir si ma théorie peut être réalisée en pratique.

Concernant les divers opinions déjà mentionnées :

- Oui, la "courbe d'apprentissage" est rude.
- Oui, comprendre le mécanisme du Borrow Checker est difficile.
- La syntaxe (ce n'est pas insurmontable) est (de mon point de vue) d'une laideur sans nom, rendant la lisibilité du code source difficile, et peut provoquer un rejet.

Malgré toutes ses qualités, Rust devrait se pencher sur ces points, et aussi, après plus d'une décennie de développement, se stabiliser.

BàT et Peace & Love.

[Uther]

Salut OuftiBoy, en effet j'aime bien parler de Rust sur le forum, pour contrebalancer les nombreuses personnes qui en parlent souvent sans le connaître vraiment, quoique les discours sont globalement bien plus renseignées ces derniers temps.

Oui, la "courbe d'apprentissage" est rude.

Certes les concept de Ownership et de Borrowing sont spécifique a Rust, mais je pense que la difficulté supplémentaire est souvent surestimée. C'est vraiment problématique au début car c'est des notions qui n'existent pas (ou ne sont pas validées par le compilateur), dans les autres langages, mais le compilateur est plutôt bon au niveau de ses message d'erreur pour aider a comprendre les problèmes. Le temps perdu a respecter les règles imposées est généralement regagné par les problèmes complexes a déboguer que l'on s'évite.
On a une équipe qui travaille en Rust chez nous, et la transition c'est globalement passé sans grosse difficulté. Ca prend un peu de temps avant de tout maîtriser mais on est capable de produire correctement assez vite et la progression se fait bien.

Oui, comprendre le mécanisme du Borrow Checker est difficile.

La mécanique en elle même n'est pas si compliquée, c'est anticiper les impacts que ça peut avoir sur la façon de structurer son code qui peut l'être.

La syntaxe (ce n'est pas insurmontable) est (de mon point de vue) d'une laideur sans nom, rendant la lisibilité du code source difficile, et peut provoquer un rejet.

Il faut quand même prendre en compte le fait que Rust a des notions technique qu'il faut exprimer explicitement ce qui implique le besoin de certaines syntaxes supplémentaires pour exprimer des notions qui n'existent pas dans d'autres langages plus simples.
Et en effet la syntaxe c'est une question de gout! Personnellement j'aurais fait pas mal de choses différemment, mais a l'usage on s'y fait, et au final je trouve quand même bien meilleur que le C++.

Malgré toutes ses qualités, Rust devrait se pencher sur ces points, et aussi, après plus d'une décennie de développement, se stabiliser.

Revoir la syntaxe et se stabiliser, c'est assez antinomique.
Dans les faits, Rust est stable depuis 2015, le mécanisme des editions permet certains changement de la syntaxe tout en maintenant la compatibilité, mais il s'agit surtout de résoudre les incohérences avec les nouvelles fonctionnalités, pas de revoir le langage en profondeur.
Il arrive de nouvelles fonctionnalités, mais pas plus ni moins que tous les langages actifs comme C++ ou Java.

[JPLAROCHE]

Les flottants 128bit n'étant à ma connaissance pas gérés par le matériel, passer par une bibliothèque ou le langage lui même ne fait pas une grande différence, dans tout les cas il y aura un supplément de code embraqué, c'est juste que Zig embarque sa propre bibliothèque.
D'ailleurs je ne pense pas que les flottants, même à 128 bits, soient une bonne idée pour de la finance, tu vas quand même te retrouver avec des arrondis qui paraissent bizarre. En général on utilise plutôt les types décimaux, qui ne sont pas gérés nativement par la plupart des langages y compris Zig.

Bonjour , j'aurais pu prendre la lib en c proposer par un ancien d'IBM ,....
Mais je voulais me servir de Rust en pure Rust pour apprendre et appréhender le langage, la question était d'avoir la gestion de chiffres ( 34 digits) étant la norme dans les bd et dans mon expérience en entreprise.

Vous me dites que ce n'est pas pris en charge par le matériel alors comment faire... bref quand vous avez Renault comme client et que le marché s'élève à plus de 32 millions d'Euros, il vous faut résoudre certain problème...

j'ai l'impression que du moment que ce n'est pas pris en charge par le matériel alors OUPS ... pourtant ma remarque n'était pas une attaque, mais un constat pour répondre à certain problème.

Mais si vous me dites que ce langage est uniquement fait pour le matériel alors il faut le préciser en tête clairement.

Quand on travaille avec 34 décimaux ce n'est pas pour faire du scientifique pour la gestion d'entreprise, c'est pour la cohérence. J'ai fait la bascule de l'Euro et quand les impôts sont venus, je n'avais que 3 centimes d'écart sur l'ensemble de la comptabilité alors les 13,15 était de mise pour les conversions. (AS400)

je ne cherche pas à avoir raison, et en plus, je dis bien clairement, je suis novice en Rust, même si mon projet commence à faire plus 20 000 lignes puisqu'il ne se limite pas au traitement des chiffres.

J'aimerais juste que Rust se penche sur les problèmes d'entreprise et pas seulement sur le noyau de Linux et pourtant je suis sur Arch et Linux depuis 2003 je ne compte pas les tentatives avant.

[JPLAROCHE]

f128 et f16 existent en nightly.
https://doc.rust-lang.org/std/primitive.f128.html
Dans les crates vous trouverez d'autres implémentations, p. ex. f256 et f512 (pas de trigo).

Mais comme cela a été mentionné par Uther, ces réels f128 et plus ne sont pas pris en charge au niveau matériel.

d'abord merci pour l'info, mais j'ai développé avec I128 avec les problèmes d'échelle pas très drôle. Mais ça fonctionne et j'ai respecté les règles de gestion telle qu'ils sont définis lors du traitement des chiffres décimaux sur l'OS400.

j'aurais vue f256 j'avoue que j'aurais embarqué et répondu plus simplement que I128 , là encore, je peux dire qu'il y en a de partout et quand on est novice les modules mis à disposition il faut fouiller des heures.

je ne regrette pas I128 ça m'a permis de découvrir des choses en Rust.

Par contre, dommage que pour valider une fonction on ne concentre que sur sa validité matérielle et on oublie le réel quotidien.

[Uther]

Vous me dites que ce n'est pas pris en charge par le matériel alors comment faire... bref quand vous avez Renault comme client et que le marché s'élève à plus de 32 millions d'Euros, il vous faut résoudre certain problème...

En effet quand ce n'est pas pris en compte par le matériel, il n'y a pas d'autre choix que de le faire logiciellement. Ce que je voulais dire c'est que niveau performance, ça ne change rien que ça soit géré directement par le langage ou par une bibliothèque, un langage qui gère ça nativement va générer du code équivalent à ce que ferait une bonne bibliothèque.

pourtant ma remarque n'était pas une attaque, mais un constat pour répondre à certain problème.

Je vous rassure, je ne l'ai absolument pas pris pour une attaque et implémenter à la main, pour le coté instructif c'est très bien.
Je signalais juste que passer par une bibliothèque n'est pas un gros problème, surtout que c'est assez facile en Rust.

Quand on travaille avec 34 décimaux ce n'est pas pour faire du scientifique pour la gestion d'entreprise, c'est pour la cohérence. J'ai fait la bascule de l'Euro et quand les impôts sont venus, je n'avais que 3 centimes d'écart sur l'ensemble de la comptabilité alors les 13,15 était de mise pour les conversions. (AS400)

Le soucis c'est que les type flottant basiques fonctionnent en mode binaire, ce qu'il fait que peu importe leur précision, ils vont faire des arrondis sur des opérations ou naturellement on ne s'y attend pas quand on a l'habitude de travailler avec des décimaux.

L'exemple classique est le 0.1+0.2 qui donne 0.30000000000000004 en 32 bit. Certes en 128 bits l'écart sera plus faible mais pas inexistant, alors que dans la finance, pour ce type de calcul, on s'attend a des valeurs parfaitement exactes. C'est pour cela que l'on recours souvent pour ces cas précis a des types en BCD (Binaire codant du décimal) qui va donner des résultat plus prédictibles pour nous les humains qui manipulons des nombres décimaux.

J'aimerais juste que Rust se penche sur les problèmes d'entreprise et pas seulement sur le noyau de Linux et pourtant je suis sur Arch et Linux depuis 2003 je ne compte pas les tentatives avant.

Rust ne se penche pas que sur le très bas niveau, mais en effet il a fait le choix, contrairement au Java ou au Python, d'une bibliothèque standard volontairement réduite. Ce qui est compensé par le fait qu'il est très facile d'ajouter des bibliothèques tierces.
Si vous voulez faire du plus haut niveau sans utiliser de bibliothèques tierces, en effet Rust n'est pas adapté pour vous.

[JPLAROCHE]

Rust ne se penche pas que sur le très bas niveau, mais en effet il a fait le choix, contrairement au Java ou au Python, d'une bibliothèque standard volontairement réduite. Ce qui est compensé par le fait qu'il est très facile d'ajouter des bibliothèques tierces.
Si vous voulez faire du plus haut niveau sans utiliser de bibliothèques tierces, en effet Rust n'est pas adapté pour vous.

d'abord merci pour votre éclaicicement.

Quant à faire du plus haut niveau à ma charge de faire des modules dont j'ai besoin , comme je le spécifie, j'essaye de ne pas prendre de LIB, à tout-va ce qui me parait plus simple (pas plus facile) pour rentrer dans le cheminement RUST ... je pense que l'aventure est intéressante.


Ps cela m'a obligé de corrigé 2 ou 3 beug que je n'avais pas vu en ZIG , bravo Rust

[fdecode]

j'essaye de ne pas prendre de LIB, à tout-va ce qui me parait plus simple

C'est quand même dans la philosophie rust de déléguer certaines fonctionnalités à des crates.

Et certains crates sont pour ainsi dire du quasi standard. Par exemple serde, num, rand, tokio, syn/quote/proc-macro/proc-macro2, rayon...
La liste des crates par downloads peut vous donner une petite idée des librairies importantes:
https://crates.io/crates?sort=downloads

[OuftiBoy]

Uther,

Salut OuftiBoy, en effet j'aime bien parler de Rust sur le forum, pour contrebalancer les nombreuses personnes qui en parlent souvent sans le connaître vraiment, quoique les discours sont globalement bien plus renseignées ces derniers temps.

Oui, je l'ai remarqué aussi, c'est une preuve que Rust intéresse de plus en plus de monde (l'index Tiobé disant le contraire n'est pas une métrique représentative, selon-moi).

Certes les concept de Ownership et de Borrowing sont spécifique à Rust, mais je pense que la difficulté supplémentaire est souvent surestimée. C'est vraiment problématique au début car c'est des notions qui n'existent pas (ou ne sont pas validées par le compilateur), dans les autres langages, mais le compilateur est plutôt bon au niveau de ses message d'erreur pour aider a comprendre les problèmes. Le temps perdu a respecter les règles imposées est généralement regagné par les problèmes complexes a déboguer que l'on s'évite. On a une équipe qui travaille en Rust chez nous, et la transition c'est globalement passé sans grosse difficulté. Ca prend un peu de temps avant de tout maîtriser mais on est capable de produire correctement assez vite et la progression se fait bien.

Oui, je suis d'accord, la difficulté est surestimée, mais cela reste tout de même une difficulté propre a Rust. Mais je suis parfaitement d'accord avec toi sur le fait que le compilateur fait du bon travail sur ses messages d'erreurs (meilleurs que les erreurs générées par le C++ lorsqu'il était au même stade de développement), et que s'affranchir de cette difficulté n'a rien d'impossible, et aussi qu'après ce passage, l'utilisation de Rust n'est pas plus compliquée que le C++, mais les 2 se positionnent quand même à un niveau où il faut de l'expérience avant de bien les maîtriser, ce qui n'a rien d'impossible.

La mécanique en elle même n'est pas si compliquée, c'est anticiper les impacts que ça peut avoir sur la façon de structurer son code qui peut l'être.

Oui, on peut voir les choses ainsi, mais il n'en reste pas moins qu'on peut mal structurer son code avant de comprendre ces impacts. Il faut, selon-moi, d'abord bien comprendre ces derniers avant de se lancer dans un projet d'une certaine envergure avec Rust (mais c'est pareil pour le C++). Il faut se former sur des projets d'une taille moyenne pour comprendre ces impacts. Avec des exemples trop simples, on risque de passer à côté de la compréhension de ces impacts. Mais c'est vrai pour tout langage de ce niveau. C'est juste différent, cela n'a rien d'impossible, mais je pense que cela reste un frein relatif à l'adoption plus massive de Rust. Il faut du temps, du temps que tout le monde n'a pas forcément.

Il faut quand même prendre en compte le fait que Rust a des notions technique qu'il faut exprimer explicitement ce qui implique le besoin de certaines syntaxes supplémentaires pour exprimer des notions qui n'existent pas dans d'autres langages plus simples. Et en effet la syntaxe c'est une question de gout! Personnellement j'aurais fait pas mal de choses différemment, mais a l'usage on s'y fait, et au final je trouve quand même bien meilleur que le C++.

Tout a fait, je te rejoins, c'est juste que ces syntaxes supplémentaires ne sont pas (selon-moi et mon passé) très explicites, dans le sens où la syntaxe choisie n'est pas facilement lisible (et tu dois savoir maintenant que pour moi, la lisibilité d'un code source est un point fondamentale). Comme toi, je n'aurais pas exprimé ces notions techniques de la même manière que celle choisie par l'équipe développant Rust. Certes, on s'y fait à l'usage, mais cela demande une fois encore du temps. Perso C++ et Rust sont (globalement) équivalant sur ce point.

Revoir la syntaxe et se stabiliser, c'est assez antinomique.

Sauf erreur de ma part, je n'ai pas dis qu'il fallait revoir la syntaxe, mais qu'elle a été mal choisie au départ, sans, je le répète, être d'une difficulté insurmontable.

Dans les faits, Rust est stable depuis 2015, le mécanisme des editions permet certains changement de la syntaxe tout en maintenant la compatibilité, mais il s'agit surtout de résoudre les incohérences avec les nouvelles fonctionnalités, pas de revoir le langage en profondeur.

Etre stable, mais (comme tu le dis), permettre des changements de la syntaxe via le mécanisme des éditions, font que l'ensemble n'est pas encore stabilisé suffisamment (c'est mon avis). Il faut bien évidemment permettre à un langage d'évoluer, mais il ne faut pas tomber dans une spirale à la C++ où certaines fonctionnalités sont ajoutées et compliquent le langage, alors que ces nouvelles fonctionnalités ne sont que très rarement utilisées, pour des cas qui ne se présentent pas forcément lors d'un développement classique. Il y a des fonctionnalités dans C++ dont il faut se creuser la tête pour savoir où, comment et pourquoi les utiliser (alors qu'il est déjà possible d'arriver à un résultat semblable via d'autres moyens plus classiques). Pour qu'un langage soit adapté massivement, il doit pouvoir être utilisé par un développeur moyen, et pas uniquement par des super développeurs. Dans une équipe de développement, tous n'ont pas le même niveau, et il faut faire avec. Constituer une équipe uniquement composées d'experts d'un langage n'est pas possible dans toutes les structures. Perso, et quelque soit le langage, j'évite d'utiliser le Cutting Edge d'un langage, pour que le code reste suffisamment lisible et compréhensible par tous.

Il arrive de nouvelles fonctionnalités, mais pas plus ni moins que tous les langages actifs comme C++ ou Java.

Oui, je comprend cela, mais il faut aussi faire attention à ne pas mettre tout et son contraire (je ne dis pas que c'est la cas de Rust) en terme fonctionnalité au risque de complexifier trop ce langage. C'est plus facile a dire qu'a faire, et sûrement plus facile lorsque l'on peut se permettre de partir d'une feuille blanche ;-)

BàT et Peace & Love Uther.

[fdecode]

Etre stable, mais (comme tu le dis), permettre des changements de la syntaxe via le mécanisme des éditions, font que l'ensemble n'est pas encore stabilisé suffisamment (c'est mon avis).

J'utilise Rust depuis 2016, et on perçoit que la stabilisation de l'ensemble converge.
Pourriez-vous donner un exemple de stabilité insuffisante pour la librairie std?

Pour ma part, le changement d'édition ne m'a jamais posé de problème et il reste assez naturel, même pour les anciennes éditions.

il ne faut pas tomber dans une spirale à la C++ où certaines fonctionnalités sont ajoutées et compliquent le langage, alors que ces nouvelles fonctionnalités ne sont que très rarement utilisées, pour des cas qui ne se présentent pas forcément lors d'un développement classique.

C'est quoi un développement classique?
Il m'est arrivé d'utiliser des fonctionnalités de C++ jusqu'au standard C++23. Je ne les ai pas trouvées artificielles.
Je regarde aussi avec un certain intérêt les ajouts faits au système de template et les possibilités qui émergent relativement aux coroutines.
Je les trouve pour ma part plutôt bienvenues.

La critique que je ferais serait sur la rétrocompatibilité trop forte. Sans doute le langage pourrait être allégé et rationalisé par un système d'édition qui réformerait davantage certaines formes anciennes.

l'utilisation de Rust n'est pas plus compliquée que le C++, mais les 2 se positionnent quand même à un niveau où il faut de l'expérience avant de bien les maîtriser, ce qui n'a rien d'impossible

Comme beaucoup, j'ai appris Rust en autodidacte. Un mois de souffrance en 2016 avant de comprendre la démarche du langage. Mais cela se fit sans trop de problème; le compilateur aide beaucoup pour l'amélioration du code et la compréhension des règles.
Sincèrement, la difficulté est plus grande pour le C++. Mais, les IA aident beaucoup désormais.