Discussion :

[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.

[Fagus]

... 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...)

Juste pour illustrer les limites d'un type decimal qui ont été évoquées plus haut, je ne peux rien dire en rust ou cobol, par contre je confirme qu'en python les modules standards sont vraiment pratiques pour le calcul. Le problème d'arrondi peut être géré voire totalement évité.
Le module decimal a une précision par défaut de 28 chiffres (précision pouvant être changée de manière arbitraire). Le module fractions permet le calcul exact des fractions.

Code :

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

1
2
3
4
5
6
7
8
9
In [2]: from decimal import *
 
In [3]: from fractions import *
 
In [4]: Decimal(1) / Decimal (3)
Out[4]: Decimal('0.3333333333333333333333333333')
 
In [5]: Fraction(1,3)+ Fraction(2,3)
Out[5]: Fraction(1, 1)

[Guesset]

Bonjour SVE,

...comme le Trésor Public qui est en train de remplacer le COBOL par Python...

Je ne savais pas mais je suis assez surpris qu'on remplace un langage compilé par un langage interprété qui même avec toutes les techniques de caches, JIT et autres, restera moins efficace ce qui veut dire plus lent et consommateur de ressources qu'un langage compilé (la portabilité n'est plus vraiment un critère vue l'homogénéité des parcs informatiques de la fonction publique).

Et les bibliothèques de Python, apparemment argument du choix, sont écrites en natif, vraisemblablement en C ou C++.

Qu'un langage interprété soit utilisé en front office peut se comprendre (contraintes d'efficacité plus faibles et facilité d'adaptation notamment) mais en back office, là où œuvre COBOL, me laisse perplexe.

Salut

[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.

[kilroyFR]

J'ai essayé Rust pour voir ce qu'il en etait et si ca valait le coup d'investir du temps. J'ai rapidement laissé tomber. Pourquoi se reformer de 0 pour un langage qui fera la meme chose au final.
Je prefere peaufiner mes connaissances sur C++ et les dernieres normes pour me mettre a jour et tirer partie des ameliorations du langage (sans tout jeter les outils et autres que j'ai l'habitude d'utiliser).

Pour moi c'est autant une mauvaise raison que ceux qui se plaignaient de la gestion memoire ou des pointeurs en C. Trop compliqué de liberer la memoire allouée ? Il faut juste etre rigoureux. D'ailleurs ca se retrouve maintenant avec les nouveaux devs qui n'ont connu que C# dans mes equipes. Ils n'ont aucune notion de gestion des ressources; croient que les ressources sont infinies, l'optimisation de code pour eux c'est remplacer des foreach par des for etc. montent en memoire des listes de plusieurs GOs sans que ca ne les interpelle. Et quand ca ne va pas assez vite, ils mettent en cause le reseau, le manque de memoire etc. Bref jamais aucune remise en cause de leur code.
Bref, mauvais diagnostic et mauvaises optimisations a chaque fois car ils ne comprennent pas comment ca fonctionne et ce que fait concretement leur langage préféré.

J'ai repris recemment un bout de code que j'avais ecrit en C++ il y a 20 ans. Voulu le refaire en C# en equivalent (sans pointeur).
Beaucoup de manipulation de listes en memoire. Au final une perf catastrophique (x5) en C#.
Du coup j'ai prefere remettre a niveau le code vers C++20 pour beneficier des simplifications du langage mais en conservant le code ecrit il y a 20 ans qui fonctionnait toujours de maniere aussi performante (meme plus avec les nouveaux processeurs et compilos).
Bref j'ai arrete de vouloir reecrire des choses perennes qui font le boulot juste pour passer vers un langage a la mode dont la duree de vie n'est pas garantie.

[Uther]

J'ai essayé Rust pour voir ce qu'il en etait et si ca valait le coup d'investir du temps. J'ai rapidement laissé tomber. Pourquoi se reformer de 0 pour un langage qui fera la meme chose au final.

Avec ce type de raisonnement on en serait encore a l'assembleur.
Rust ne permet évidemment pas à l'application finale de faire plus qu'une application écrite en C, cependant, il apporte des abstractions évoluées, de bien plus fortes garanties sur la sécurité, un ensemble d'outils intégrés cohérents, ...

Pour moi c'est autant une mauvaise raison que ceux qui se plaignaient de la gestion memoire ou des pointeurs en C. Trop compliqué de liberer la memoire allouée ? Il faut juste etre rigoureux.

Ce qui ne marche pas dans la pratique. Si on a un programme un minimum complexe, même les développeur chevronnés finissent par laisser passer des erreurs mémoire qui passeront inaperçues.

D'ailleurs ça se retrouve maintenant avec les nouveaux devs qui n'ont connu que C# dans mes equipes. Ils n'ont aucune notion de gestion des ressources; croient que les ressources sont infinies, l'optimisation de code pour eux c'est remplacer des foreach par des for etc. montent en memoire des listes de plusieurs GOs sans que ca ne les interpelle. Et quand ca ne va pas assez vite, ils mettent en cause le reseau, le manque de memoire etc. Bref jamais aucune remise en cause de leur code.

Bref, mauvais diagnostic et mauvaises optimisations a chaque fois car ils ne comprennent pas comment ca fonctionne et ce que fait concretement leur langage préféré.

Des mauvais développeurs, il y en a toujours quelque soient les langages, mais pour le coup, c'est plutôt une excellente raison d'utiliser Rust qui est un langage très peu permissif et qui les oblige à apprendre a gérer correctement soi même pas mal de choses qui sont gérées automatiquement par C#/Java avec un impact sur les performances, ou qui seraient ignorées en C/C++ avec au final des problèmes de qualité.

J'ai repris recemment un bout de code que j'avais ecrit en C++ il y a 20 ans. Voulu le refaire en C# en equivalent (sans pointeur).
Beaucoup de manipulation de listes en memoire. Au final une perf catastrophique (x5) en C#.

Oui mais la on parle pas du même type de langage. Si tu passe d'un langage système à un langage managé, bien sur qu'il faut t'attendre a des performances inférieures. Là on parle des remplaçants à C, donc des langages systèmes comme Zig ou Rust qui sont censés avoir des capacités et des performances similaires.

[Kannagi]

Il faut juste etre rigoureux.

Fallait dire ça aux programmeur de Ariane 5: https://fr.wikipedia.org/wiki/Vol_501_d%27Ariane_5

Le gros désavantage du C , c'est son nombre d'UB et de manque de sécurité.
Et plus le programme est complexe, plus il est difficile de penser à toutes les "possibilité" pour éviter un bug.

[Madmac]

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++.

On peut faire l'équivalent de l'héritage avec la composition. Avec les risques du multi-héritage. l'Idéal serait que le langage introduisent un langage macro qui support l'héritage pour gérer les risques.

Ou ptêt qu'on revient du paradigme «tout est objet partout tout le temps, seul le mécanisme d'héritage compte, et de toute façon si on crée un langage c'est pour des experts, etc.»

L'héritage n'est pas existant dans tout les langages de programmation. Oberon ne supporte pas l'héritage.

La POO a été inventée dans un Bureau de Complication des Affaires Simples. On en reviendra, oui.

Ou par quelqu'un qui voulait réduire au maximum les variables et les constantes globales.

[thamn]

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++.

Y'a pas de null en rust que je sache ou je me trompe?

[Metal3d]

Je comprends l'engouement pour Rust et il a sa place dans ce type de projet (pour une fois qu'il sera choisi pour de bonnes raisons...)
Sauf qu'il a aussi des travers et il ça apporter son lot de crasses. Du coup on va avoir 3 langages dans le noyau, des soucis de compilation et des comportements de gestion de mémoire parfois compliqués à gérer. Rust c'est une bonne idée mais il ne faut pas le voir comme le messie.

[TJ1985]

Je ne comprends pas bien ce que fait C3 d'après cet article, puisqu'on nous dit que le successeur naturel de C devrait être Rust. Pas un mot sur C3. Bizarre, non ?
A part ça, sur l'argument d'un commentateur de la base de code existante, si on va par là on se retrouve en COBOL pour les applications. On survivrait, mais bon...

[Uther]

Y'a pas de null en rust que je sache ou je me trompe?

Non tu ne te trompe pas Zig a repris les type de retours de Rust qui lui même les a repris des langages fonctionnel comme OCaml.

Je ne comprends pas bien ce que fait C3 d'après cet article, puisqu'on nous dit que le successeur naturel de C devrait être Rust. Pas un mot sur C3. Bizarre, non ?

C'est juste que l'article cite les propos du créateur du langage C3.
Aucun langage n'a le statut de successeur naturel du C, même si il y a plusieurs prétendants comme Rust, Zig ou C3.

[smarties]

Aucun langage ne remplacera le C mais le RUST a déjà commencé à s'intégrer dans des systèmes (Google avait réécrit le module bluetooth pour Android qui est devenu plus rapide et stable, il y a une implémentation de SSL aussi, ...)

[gzii69]

J'ai testé Rust pour un projet perso au départ. Pour moi le C et le C++ (à l'ancienne façon C objet) restaient les langages les plus puissants.

J'ai un peu galéré parce que ça change, mais ensuite je ne me suis pas senti enfermé par rapport au C. J'ai bien eu l'impression de toujours gérer ma mémoire, juste un peu différemment.
Puis j'ai eu besoin de mon projet perso pour sauver un projet pro et là je dois dire que j'ai quand même été épaté, ça tourne aussi vite qu'en C (du même ordre en tout cas), et c'est d'une stabilité qui fait plaisir (le moteur tourne pendant longtemps avec forte charge sur des serveurs sans aucun souci).
J'ai quand même un peu galéré faute de connaissance du langage pour trouver la structure sans jamais utilisé de unsafe.
Et je suis toujours un débutant en Rust, il y a encore beaucoup de choses à voir.
C'est multi-threads, multi-user avec les sockets réseau, super rapide et puissant là où les autres solutions pétaient sous la charge (pourtant gros serveurs 32 à 40 coeurs et RAM énorme).

J'ai été conquis par le langage et je m'y retrouve vraiment par rapport à du C.
Est-ce que ça le remplace ? Pour de nouvelles choses oui peut-être (en tout cas pour moi),
mais j'aimais bien le C quand même parce que je trouve qu'il reste très proche du langage machine et je suis peut-être maso mais j'ai toujours aimé les pointeurs (de pointeurs de ...).
Et je trouve qu'on programme mieux si on comprend ce qui se passe. Alors le C reste sans doute important comme part de l'apprentissage ?