Discussion :

[Patrick Ruiz]

Est-il possible de remplacer le C ? Le créateur du langage C3 donne des raisons pour lesquelles ce type d’initiative est voué à l’échec
Au moment où le noyau Linux s’ouvre de plus en plus au Rust

Go, C3, D, … La liste des langages présentés comme des alternatives au C s’allonge avec les années qui passent. Celui qui a frappé un grand coup dans ces tentatives multiples de mise au rebut du langage C est le Rust. En effet, le noyau Linux s’ouvre de plus en plus au langage de programmation système de Mozilla. Le créateur du langage C3 met néanmoins en avant une liste de raisons pour soutenir que toutes ces initiatives de remplacement du langage C ont de fortes chances de se casser la figure.

Le créateur du langage C3 s’exprime sur divers aspects dont :

La chaîne d'outils du langage C

Le langage C n'est pas seulement le langage lui-même, mais aussi tous les outils de développement développés pour ce langage. Vous voulez faire une analyse statique de votre code source ? - Il y a beaucoup de gens qui travaillent sur ce sujet pour le C. Des outils pour détecter les fuites de mémoire, les courses de données et autres bogues ? Il y en a beaucoup, même si votre langage est mieux outillé.

Si vous voulez cibler une plateforme obscure, il est probable que vous utilisiez le C. Le statut du C en tant que lingua franca de l'informatique d'aujourd'hui fait qu'il vaut la peine d'écrire des outils pour ce langage, et de nombreux outils sont donc écrits.

Si quelqu'un a mis en place une chaîne d'outils qui fonctionne, pourquoi risquer de changer de langage ? Un "meilleur C" doit apporter beaucoup de productivité supplémentaire pour motiver le temps passé à mettre en place une nouvelle chaîne d'outils. Reste même à savoir si cela est possible.


Les incertitudes d'un nouveau langage

Avant qu'un langage ne soit arrivé à maturité, il est probable qu'il comporte des bogues et qu'il soit modifié de manière significative pour résoudre les problèmes de sémantique du langage. Et le langage est-il même conforme à la publicité ? Il offre peut-être quelque chose comme "des temps de compilation exceptionnels" ou "plus rapide que le C" - mais ces objectifs s'avèrent difficiles à atteindre lorsque le langage ajoute l'ensemble des fonctionnalités.

Et qu'en est-il des mainteneurs ? Bien sûr, un langage open source peut être bifurqué, mais je doute que de nombreuses entreprises soient intéressées par l'utilisation d'un langage qu'elles pourraient être obligées de maintenir plus tard. Parier sur un nouveau langage est un gros risque.

Le fait que le langage pourrait tout simplement ne pas être assez bon

Le langage s'attaque-t-il aux véritables points faibles du C ? Il s'avère que les gens ne sont pas toujours d'accord sur ce que sont les points sensibles du C. L'allocation de mémoire, la gestion des tableaux et des chaînes de caractères sont souvent délicates, mais avec les bonnes bibliothèques et une bonne stratégie mémoire, elles peuvent être minimisées. Le langage ne traite-t-il pas des problèmes dont les utilisateurs avancés ne se soucient pas vraiment ? Si c'est le cas, sa valeur réelle pourrait être beaucoup plus faible que prévu.

Et pire encore, que se passe-t-il si le langage omet des fonctionnalités cruciales qui sont présentes en C ? Des fonctionnalités sur lesquelles les programmeurs avancés du C comptent ? Ce risque est accru si le concepteur du langage n'a pas beaucoup utilisé le C, mais vient du C++, du Java, etc.

L’absence de développeurs expérimentés pour un nouveau langage

Un nouveau langage disposera naturellement d'un groupe beaucoup plus restreint de développeurs expérimentés. Pour toute entreprise de taille moyenne ou grande, c'est un énorme problème. Plus il y a de développeurs disponibles pour une entreprise, mieux elle se porte.

De plus, si l'entreprise a l'expérience du recrutement de développeurs C, elle ne sait pas comment recruter pour ce nouveau langage.

L'ABI C

Si le langage ne peut pas facilement appeler - ou être appelé - par du code C, alors toute personne utilisant le langage devra faire un travail supplémentaire pour faire à peu près tout ce qui est interface avec du code extérieur. C'est potentiellement un énorme inconvénient.

Linus Torvalds fait-il fausse route en ouvrant le développement du noyau Linux au langage Rust ?

Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Du coup, la communauté du célèbre noyau open source commence à penser au changement de générations. Une nouvelle dont la tranche d’âge se situe dans la trentaine gravit les échelons, mais comme Linus lui-même le souligne : « Il s'avère qu'il est vraiment difficile de trouver des personnes qui sont des mainteneurs » ; un fait lié à ceci que le développement du kernel Linux continue de se faire en C et assembleur – des langages auxquels la vieille génération est plus accoutumée ? C’est une possibilité et elle est susceptible d’expliquer pourquoi 2022 pourrait être l’année du langage Rust au sein du noyau Linux. Linus Torvalds annonce en effet que Rust for Linux est susceptible d’être prêt pour la version 5.20 du noyau.

Linus Torvalds et Dirk Hohndel ont eu leur habituel échange lors d’une session de l’édition 2022 de l’Open Source Summit au cours du mois de juin 2022. Linus Torvalds commentait alors sur les évolutions du projet Rust for Linux en soulignant qu’il est susceptible d’être prêt pour Linux 5.20. Les publications de Miguel Ojeda, chef du projet Rust for Linux, avait déjà permis de dresser une liste des progrès de l’initiative : support d’un compilateur Rust bêta, test du support des architectures ARM et RISC-V, nouvelles abstractions Rust, etc.

15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans (chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE)) sont liées à des tares que traînent le langage C : problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. Linus Torvalds s’est penché il y a peu sur un potentiel problème de sécurité avec les fonctions primitives d'exécution spéculative de la liste liée du noyau écrit en ANSI C. C’est en corrigeant ce problème qu’il s’est rendu compte qu’en C99 l'itérateur passé aux macros de parcours de liste doit être déclaré dans une portée en dehors de la boucle elle-même. C’est de ce constat que venait sa récente décision de faire passer le noyau Linux au C moderne (C11) dont la normalisation est achevée en 2011. C’est le genre de raisons techniques susceptibles de justifier la mise au rebut du langage C au profit du Rust pour le développement du noyau sur le long terme.

La nouvelle arrive dans un contexte où le regard de Linus Torvalds sur le langage Rust a changé. En effet, la prise en charge de Rust pour le développement du noyau Linux commence à prendre forme et est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

Et vous ?

Quel commentaire faites-vous de l’argumentaire du créateur du langage C3 ? Quels sont les aspects les plus pertinents ? Quels sont ceux qui le sont moins ?
La difficulté de trouver des mainteneurs est-elle la conséquence de ce que le développement du noyau Linux continue de se faire en C et en assembleur au moment où les développeurs s’intéressent de plus en plus à des langages comme Rust ?
Êtes-vous aussi d’avis que la communauté Linux anticipe non seulement sur les départs en retraite des actuels mainteneurs et sur les qualités que Rust offre en comparaison au langage C ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

[steel-finger]

Pour moi, aucun langage ne peut le remplacer, il a ce petit truc à lui, parfois, on l'aime comme on le déteste !
Blague à part, les bases de code existant en C sont immenses, ça aurait un coût financier non négligeable et je vois mal les entreprises ou projet changer de langage du jour au lendemain.
Malgré tout le bien que je pense de Rust, pour moi le C à encore de belle année devant lui.

[Sve@r]

Moi je ne comprends même pas le concept "remplacer le C". Il a quoi de tellement mauvais qu'on veuille à tout prix le remplacer??? Ok il n'est pas parfait, mais aucun langage ne l'est (Herbert Mayer). Donc s'il est adapté à l'usage qu"on en fait, pourquoi chercher alors à le remplacer??? Pourquoi on ne voit pas le même genre de question avec "est-il possible de remplacer le COBOL" ou "est-il possible de remplacer ADA" ???
C'est quand-même fou ça, il y a un langage spécifique à un usage ; pour cet usage il est alors majoritairement utilisé (un peu normal, le bateau est fait pour aller sur l'eau, tous ceux qui vont sur l'eau utilisent donc un bateau ce qui est parfaitement logique) et tout va bien. Mais non, on voit arriver des illuminés qui disent "il faut remplacer le C" et tout le monde embraye à chercher le "comment faire" sans même chercher le pourquoi de ce "il faut". Sans déconner, il n'y aurait pas des problèmes informatiques plus intelligents vers lesquels orienter les efforts ?

[foetus]

Il a quoi de tellement mauvais qu'on veuille à tout prix le remplacer???

Parce qu'en C (comme avec le C++ avant 2011, quoique), on se focalise plus sur le "comment faire" et non sur le "ce que je dois faire"
Ce n'est pas pour rien que les mêmes "critiques" reviennent : gestion de la mémoire, gestion des dépendances, chaînes de caractères, multitâches, ...

Et je pense que ce qui embête les développeurs, 1 langage bas niveau rapide, il n'y a que le C ... et éventuellement le C++.
Le C "responsable" de "15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans" : je ne trouve pas cela énorme ... mais Linus et son équipe ont dû fournir 1 travail très très rigoureux

Moi je ne comprends même pas le concept "remplacer le C"

on peut toujours créer 1 langage qui transpile en C, comme le faisait le C++ (+ le cas depuis longtemps) et 1 autre exemple, le TypeScript vers JavaScript. Et ainsi, au prix d'1 complexité à la compilation et d'1 temps + long, on peut garder le langage C ... et les anciens projets.

[foetus]

Après on peut penser qu'il y a 1 intérêt politique

Actuellement :

• les systèmes d'exploitation grand public sont américains : Windows/ Microsoft, Android (Linux)/ Google, OS et iOS (Unix)/ Apple et Linux (Linus Torvalds est américain et vit aux États-Unis)
• les processeurs grand public sont américains : Intel et AMD. PowerPc/ IBM est américain.

Donc, si tu arrives à faire 1 langage bas niveau rapide et qu'il soit "simple" à coder, au moins la Chine et la Russie (peut-être l'Inde) pourront faire leur propre système d'exploitation souverain.
La Chine est en train de faire des processeurs [RISC].
De toute façon, à terme, c'est ce qu'il va se passer : les américains vont perdre leur monopole technologique mais dans combien de temps ?
Ces pays là ont potentiellement des millions de développeurs, cela peut aller très vite.

[Invité]

Aucun langage informatique d'envergure n'a été massivement adopté à cause de ses qualités intrinsèques, mais parce qu'il correspondait aux besoins du moment.

La vraie question à se poser est donc : quel besoin pourrait satisfaire Rust que le C ne comble pas ?

Début de réponse : peut-être que la popularité de Rust grandira le jour où webassembly décollera.

[Rep.Movs]

Si c'est pour implémenter du code qui limite les failles "techniques", rust peut être une solution.

Pour le reste... C est un langage de bas niveau, et à ce niveau il est plutôt bon. Si c'est pour manipuler des matrices/faire du calcul réparti, certains ont pensé que python serait bon, mais de mon point de vue fortran+MPI (ou autre) était déjà mieux avant.

Le problème des langages informatique n'est pas la complexité du langage: c'est le temps pour maîtriser le langage. Alors tous les 4 ans, on nous sort un langage qui promet d'être meilleur, plus rapide, plus simple... Et qui au bout de 4 ans s'est complexifié au niveau du langage d'origine.

Et c'est se masquer la difficulté actuelle qui est la maîtrise des bibliothèques, des risques de sécurité, des interactions entre briques...

Si un nouvel ordi se programme dans un dérivé de Pascal, C et Basic, je n'y vois pas d'inconvénient.

Ayant ressorti un vieil atari 800, je peux dire une chose: à l'époque le basic était lent, mais très efficace: pas de configuration à rallonge, pas d'initialisation technique dans tous les sens... Juste une ligne de sélection de mode et le code du programme.
Et cette simplicité, sans le besoin de faire des imports, des init, des $(document).ready(), de connaître ses includes, son int main(char** argc), c'est ça qui manque pour ne pas faire peur aux nouveaux venus.

[smarties]

Le C n'est pas parfait ni RUST.
Cependant, je trouve pertinent de pousser le développement de nouveaux modules en RUST si on peut avoir un code sécure du premier coup.
Si un module complexe en C a souvent des vulnérabilités, l'écriture en RUST peut aussi s'étudier.

[Madmac]

C excellent dans les trucs qui nécessite une gestion serrée de la mémoire. Et il y aura des situation où cela va rester une nécessité. Comme par exemple dans la fabrication de micro-contrôleurs.

Parce qu'il y avait une pénurie de langage compilé pendant l'émergence des ordinateurs personnels, le C est devenu un langage bouche-trou. Dans les faits, il y a très peu de raison de faire encore des programmes en C. Des librairies en C, dans certains cas, cela reste valable, mais ce n'est plus essentiel.

Début de réponse : peut-être que la popularité de Rust grandira le jour où webassembly décollera.

Ou quelque chose de semblable à webassembly. Mais ce qui devient de plus en plus flagrant est que nous pouvons pas exploiter les CPU multi-coeurs de façon optimal avec l'approche actuel.

[arthuro555]

Perso, je pense que rust n'est pas plus fait pour remplacer le C que python. C'est un langage de programmation système, certes, et de ce fait c'est un langage fait pour des utilisations telles qu'au sein d'un Kernel. Mais le C n'est pas qu'un langage pour Kernel, et idem pour rust. Mis à part cela, je trouve qu'ils ont des objectifs et designs très différent: je ne pense pas que l'on puisse parler de rust comme une amélioration du C, c'est un tout autre langage qui n'a que peux a voir avec C.

Si on cherche un compétiteur au C, je suggérerais plutôt Zig: ce langage est vraiment basé sur le design et les buts de C, et a une interopérabilité avec le C quasi parfaite.

[Uther]

Blague à part, les bases de code existant en C sont immenses, ça aurait un coût financier non négligeable et je vois mal les entreprises ou projet changer de langage du jour au lendemain.

Tout dépend ce que l'on entend par "remplacer le C". S'il s'agit de réécrire tout le code C existant dans un autre langage, ça serait évidement idiot et même irréalisable dans des conditions normales de productivité.
Je pense que la seule façon intéressante de comprendre "remplacer le C", c'est "prendre sa place en tant que langage de choix pour faire des projets bas niveau".

Pourquoi on ne voit pas le même genre de question avec "est-il possible de remplacer le COBOL" ou "est-il possible de remplacer ADA" ???

Soit sûr que ces questions ont été posées un nombre incalculable de fois, particulièrement pour COBOL où on se la pose encore aujourd'hui chez nous. C'est compliqué à faire à cause de la base de code existant, mais sans ça il aurait disparu il y a bien longtemps. Si COBOL est encore là, ce n'est certainement pas pour ses qualités intrinsèques.
Si on ne voit plus ces question partout dans les articles qui traitent de programmation ces derniers temps, c'est surtout parce que les alternatives à COBOL sont déjà très bien implantées depuis les années 90, alors que les alternatives au C étaient plutôt discrètes avant l'émergence de Rust ou Zig.

C'est quand-même fou ça, il y a un langage spécifique à un usage ; pour cet usage il est alors majoritairement utilisé (un peu normal, le bateau est fait pour aller sur l'eau, tous ceux qui vont sur l'eau utilisent donc un bateau ce qui est parfaitement logique) et tout va bien. Mais non, on voit arriver des illuminés qui disent "il faut remplacer le C" et tout le monde embraye à chercher le "comment faire" sans même chercher le pourquoi de ce "il faut". Sans déconner, il n'y aurait pas des problèmes informatiques plus intelligents vers lesquels orienter les efforts ?

Bien évidement qu'on c'est posé la question du "pourquoi". Le C a beau répondre a un usage, les besoin évoluent aussi.
Le C traine derrière lui 50 ans d'histoire. Il a été créé dans les années 70 où il devait pouvoir être compilé sur des machines avec au plus quelques Mhz de fréquence d'horloge et quelques Mo de RAM. Des choix ont été fait à l'époque pour permettre une compilation simple qui ne se justifient plus vraiment aujourd'hui. De même à cette époque la sécurité du code était une préoccupation plutôt lointaine, les considération de qualité et de réutilisabilité du code étaient différentes, les besoins de modules tiers étaient bien moins importants, ...

Je ne dis pas que le C n'a pas évolué, mais il est clairement encore très contraint par des choix de design de l'époque qu'il ne peux pas remettre en cause, c'est pour cela que la question d'un langage alternatif n'est pas idiote.

C excellent dans les trucs qui nécessite une gestion serrée de la mémoire. Et il y aura des situation où cela va rester une nécessité. Comme par exemple dans la fabrication de micro-contrôleurs.

Dans ce domaine, des langages comme Zig ou Rust peuvent faire aussi bien le travail que le C. La contrainte technique pour le moment étant la disponibilité des compilateurs pour les architectures plus rare.

[Madmac]

Dans ce domaine, des langages comme Zig ou Rust peuvent faire aussi bien le travail que le C. La contrainte technique pour le moment étant la disponibilité des compilateurs pour les architectures plus rare.

Je ne connaissait pas Zig. Et effectivement il me semble être une alternative vraiment intéressante. Le fuites de mémoire en C m'ont tenu loin de ce langage. Ce langage semble offrir des solutions sérieuses pour s'en protéger. Et c'est le seul que j'ai vu qui offre une façon de se débarrasser de null. https://ziglang.org/fr/learn/overview/

Je vois plus Rust comme alternative pour des application plus lourdes qui demanderait l'utilisation de l'héritage en C++.

[droggo]

Bonjour,

Bien entendu, on ne peut pas affirmer que le C ne sera jamais remplacé, mais il est tellement implanté que ça va demander du temps.

Pensez au "bon vieux" Cobol encore utilisé ...

[Sve@r]

Pensez au "bon vieux" Cobol encore utilisé ...

Il n'y a pas de quoi être dépité. Le COBOL possède deux avantages

• c'est une locomotive. Il est lent à se mettre en marche, mais une fois lancé, il avale tout fichier quel que soit sa taille
• c'est un des seuls langages à savoir calculer les décimaux sans la perte due à la conversion décimal => binaire. Sa façon de définir les nombres (exemple pic 99v99 signifiant 4 chiffres dont 2 après la virgule) en fait un langage privilégié pour tout ce qui a trait aux calculs où la vitesse compte moins que la précision (banques, impôts, etc)

Comme quoi, le coup des vieilles marmites qui font les meilleures soupes, ça marche aussi avec les langages. Peut-être que le C sera remplacé, je n'en sais rien, mais ce dont je suis sûr c'est que si ça doit se faire, cela se fera naturellement sans "forcer" les choses, comme le Trésor Public qui est en train de remplacer le COBOL par Python, autre langage qui peut aussi calculer les décimux avec précision via son module "decimal". Et Python est né en 1989 (33 ans à mûrir avant qu'il soit pris en considération pour commencer à remplacer le COBOL...)

[Pyramidev]

c'est un des seuls langages à savoir calculer les décimaux sans la perte due à la conversion décimal => binaire. Sa façon de définir les nombres (exemple pic 99v99 signifiant 4 chiffres dont 2 après la virgule) en fait un langage privilégié pour tout ce qui a trait aux calculs où la vitesse compte moins que la précision (banques, impôts, etc)

N'importe quel langage un tout petit peu évolué permet de coder une bibliothèque avec un type décimal. Parmi ces langages, n'importe quel langage qui supporte la surcharge d'opérateurs permet de manipuler ces nombres décimaux avec une syntaxe pas trop casse-pieds.

Par exemple, voici un script Rust qui utilise les crates rust_decimal et rust_decimal_macros :

Code Rust :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#!/usr/bin/env rust-script
 
// cargo-deps: rust_decimal="1.26.1", rust_decimal_macros="1.26.1"
extern crate rust_decimal;
extern crate rust_decimal_macros;
 
use rust_decimal::Decimal;
use rust_decimal_macros::dec;
 
fn main() {
    let amount = dec!(25.12);
    let tax = dec!(0.085);
    let total = amount + (amount * tax);
    let price = total.round_dp(2);
    println!("total == {total}");
    println!("price == {price}");
    println!("Size of each Decimal object: {} bytes", std::mem::size_of::<Decimal>());
    println!("Smallest possible value: {}", Decimal::MIN);
    println!("Largest possible value:   {}", Decimal::MAX);
}

Résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
total == 27.25520
price == 27.26
Size of each Decimal object: 16 bytes
Smallest possible value: -79228162514264337593543950335
Largest possible value:   79228162514264337593543950335

[Uther]

Pour rajouter à ce que dit Pyramidev, même si le résultat affiché correspond mieux à ce que s'attend à voir un utilisateur final, l'utilisation d'un type décimal ne garantit absolument pas qu'il n'y aura pas de problème d'arrondis, sur les divisions par exemple, c'est juste qu'il n'arrivent pas dans les mêmes cas.

[Sve@r]

N'importe quel langage un tout petit peu évolué permet de coder une bibliothèque avec un type décimal. Parmi ces langages, n'importe quel langage qui supporte la surcharge d'opérateurs permet de manipuler ces nombres décimaux avec une syntaxe pas trop casse-pieds.

Oui évidemment. Mais ce sont les langages du jour. Le COBOL lui date de 1970 et à l'époque était le seul. Donc fatalement c'est celui qui a été utilisé pour ça.
Attention, je ne dis pas que j'aime le COBOL. C'est un langage ignoble rempli de contraintes innomables (identification division, data division et autres). Obligé de déclarer et définir les caractéristiques de tout fichier qui sera traité. Obligé de commencer toute instruction à la 8° position de la ligne car les 7 premières ne sont pas prises en compte (raison???). Aucune instruction de boucle autre que "goto".
Mais comme à l'époque c'était le seul capable d'additionner des décimaux, ça a été la raison qui a fait que. Et si on veut le remplacer par un langage plus récent il faudra tout recoder (d'ailleurs comme je l'ai dit c'est en cours car fin 2019 j'ai vu passer une offre de poste au Ministère des Finances de Nantes demandant un dev connaissant COBOL et Python pour réécrire tout leurs programmes).

l'utilisation d'un type décimal ne garantit absolument pas qu'il n'y aura pas de problème d'arrondis, sur les divisions par exemple

Ah effectivement, je n'ai jamais dit que le type decimal pouvait régler ce genre de souci et trouver le résultat exact de par exemple 1/3.
En fait, le type decimal est fait pour travailler sur les nombres décimaux, ce que n'est pas la fraction 1/3 qui est un nombre rationnel.
Le type decimal pourra donc calculer avec exactitude des sommes (positives ou négatives) ainsi que des multiplications de décimaux (ce qui est parfait pour tout ce qui a trait aux finances et/ou domaine bancaire, raison pour laquelle le COBOL est encore si présent dans ce domaine) mais si on le confronte à des divisions ou autres calculs plus complexes, lui aussi sera bloqué par ce mur que sont les limites mathématiques.

[chrtophe]

Obligé de commencer toute instruction à la 8° position de la ligne car les 7 premières ne sont pas prises en compte (raison???)

Les six premières colonnes de chaque ligne de programme sont considérées comme une zone de commentaire, servant autrefois à numéroter les cartes perforées (en cas de chute du paquet, il suffisait de les passer sur une trieuse pour reconstituer la version correcte du programme). La septième colonne contient un caractère de contrôle : espace pour les lignes actives, étoile pour les commentaires, tiret comme caractère de continuation.

[Uther]

Ah effectivement, je n'ai jamais dit que le type decimal pouvait régler ce genre de souci et trouver le résultat exact de par exemple 1/3.
En fait, le type decimal est fait pour travailler sur les nombres décimaux, ce que n'est pas la fraction 1/3 qui est un nombre rationnel.

C'est même plus subtil que ça. Si en COBOL tu as une précision décimale de deux chiffres (cas classique) un bête 1/8 qui est bien un décimal (0,125) sera arrondi alors qu'en binaire ça serait passé sans perte de précision. Le décimal n'est pas foncièrement plus précis, juste plus facile a appréhender pour les humains qui sont habitués à calculer en base 10.

[Bktero]

Je vois plus Rust comme alternative pour des application plus lourdes qui demanderait l'utilisation de l'héritage en C++.

Sauf qu'il n'y a pas vraiment de classes et d'héritage en Rust.

En tout cas, on est très loin des possibilités de C++.

Je ne connaissait pas Zig. [...] Et c'est le seul que j'ai vu qui offre une façon de se débarrasser de null

Rust non plus ne connait pas null.