IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Patrick Ruiz

54PARTAGES

30  0 
Quel langage pour remplacer le C ?
Rust
42 %
Je n'ai pas d'avis
8 %
Autre langage (à préciser)
4 %
Go
0 %
D
0 %
C3
0 %
Aucun langage ne peut remplacer le C
46 %
Voter 48 votants
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de steel-finger
Membre averti https://www.developpez.com
Le 12/08/2022 à 13:18
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.
8  0 
Avatar de Sve@r
Expert éminent sénior https://www.developpez.com
Le 12/08/2022 à 13:41
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 ?
12  5 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 13/08/2022 à 9:04
Citation Envoyé par steel-finger Voir le message

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

Citation Envoyé par Sve@r Voir le message
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.

Citation Envoyé par Sve@r Voir le message
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.

Citation Envoyé par Madmac Voir le message
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.
7  0 
Avatar de Jeff_67
Membre chevronné https://www.developpez.com
Le 12/08/2022 à 15:28
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.
6  0 
Avatar de sergio_is_back
Expert confirmé https://www.developpez.com
Le 19/08/2022 à 10:56
Citation Envoyé par Jamatronic Voir le message
La POO a été inventée dans un Bureau de Complication des Affaires Simples. On en reviendra, oui.
Non je n'ai pas cette approche.
La POO, comme l'approche procédurale, doit être utilisée à bon escient et d'ailleurs on peut parfois mixer les deux quand c'est nécessaire.

Que soit le style de programmation, ou le langage (et même parfois le système d'exploitation), le choix doit être fait en fonction de la nature du projet et du résultat visé.
Ceci dit, bien souvent, c'est pas possible dans certaines entreprises où une culture informatique définie depuis des lustres va contraindre le développeur...
6  0 
Avatar de foetus
Expert éminent https://www.developpez.com
Le 12/08/2022 à 14:01
Citation Envoyé par Sve@r Voir le message
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

Citation Envoyé par Sve@r Voir le message
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.
6  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 17/08/2022 à 7:29
Citation Envoyé par kilroyFR Voir le message
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, ...

Citation Envoyé par kilroyFR Voir le message
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.

Citation Envoyé par kilroyFR Voir le message
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é.

Citation Envoyé par kilroyFR Voir le message
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.
6  1 
Avatar de smarties
Membre émérite https://www.developpez.com
Le 12/08/2022 à 17:32
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.
4  0 
Avatar de Fagus
Membre chevronné https://www.developpez.com
Le 16/08/2022 à 13:46
Citation Envoyé par Sve@r Voir le message
... 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
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)
4  0 
Avatar de Rep.Movs
Membre habitué https://www.developpez.com
Le 12/08/2022 à 15:37
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.
4  1