C2 : un langage qui se présente comme une évolution de C

**Michael Guilloux** · 01/02/2018, 15h14

C2 : un langage qui se présente comme une évolution de C
plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements

Malgré ses 45 ans, le langage C a certainement encore de beaux jours devant lui, parce qu'il est déjà largement utilisé et qu'il y a des domaines qui restent encore sa chasse gardée, notamment l'embarqué et le développement d'applications où il est essentiel d'avoir du contrôle sur le matériel. N'empêche que certains essaient de se montrer comme un meilleur C. C'est le cas par exemple des langages D et Ritchie. Parmi ces langages, il y a également C2 qui est présenté par ses créateurs comme une évolution de C, plutôt qu'un remplaçant du langage de Dennis Ritchie.

« Le langage de programmation C existe depuis longtemps et est encore très utilisé de nos jours. Le noyau du langage est très solide, mais d'autres aspects montrent leurs limites avec le temps. C2 tente de moderniser ces parties, tout en gardant l'expérience de C. Il devrait être vu comme une évolution de C », est-il indiqué sur le site officiel du langage C2, en guise de philosophie du projet.

Cette philosophie a conduit l'équipe C2 aux objectifs de conception suivants :

une vitesse de développement plus grande ;
une vitesse d'exécution similaire, voire meilleure ;
de meilleurs temps de compilation ;
un système de build intégré ;
une syntaxe plus stricte (plus facile pour le tooling) ;
un excellent tooling (outil de formatage, outil graphique de refactorisation) ;
une intégration facile avec les bibliothèques C ;
un langage qui devrait être facile à apprendre pour les programmeurs en C ;
un langage qui devrait aider à éviter les erreurs communes.

Essayant de positionner leur langage par rapport aux langages de programmation actuels, l'équipe derrière C2 explique qu'il y a eu une tendance vers davantage d'abstractions de plus haut niveau, dans l'évolution des langages au fil du temps. « Java et C# reflètent particulièrement cette tendance. Pour les langages de niveau système, D et Rust se sont éloignés de cette tendance, pour fournir de meilleures performances et un meilleur contrôle », dit-elle. Avant d'ajouter que « pour un langage de niveau système, les fonctionnalités offertes par C++, D et Rust sont très appropriées. Cependant, ces langages ne semblent pas combler le vide pour les programmes de bas niveau/embarqués, car ils sont souvent encore programmés en C. C'est exactement ce vide que C2 tente de combler. »

C2 vise à être utilisé pour les problèmes où C est actuellement utilisé. Donc, les programmes de bas niveau comme les chargeurs d'amorçage (bootloaders), les noyaux, les pilotes et les outils de niveau système. Puisqu'il se veut une évolution de C, son équipe de développement a explicitement précisé que son objectif n'est pas d'introduire des fonctionnalités de niveau supérieur (comme l'orientation-objet, la récupération de mémoire, etc.) ou créer un langage complètement nouveau. Si C2 se présente comme une évolution de C, quels sont donc les changements par rapport à C ?

Ce qu'il faut savoir parmi les principales différences entre C et C2, c'est qu'il n'y a aucun fichier d'en-tête dans C2. C2 utilise en effet une approche dite moderne pour l'utilisation de symboles externes. Il n'y a qu'un seul type de fichiers, les fichiers source .c2. Pour remplacer #include, il existe une instruction d'importation. Tout le code source est également divisé en modules.

C2 vient en plus avec un système de build intégré. L'intégration du système de build dans le compilateur peut sembler restrictive, mais d'après les développeurs du langage, cela permet en réalité de nombreuses améliorations. L'une des fonctionnalités offertes par le système de build intégré est la compilation par cible (pas par fichier). Traditionnellement, les programmes C sont compilés par fichier, c'est-à-dire que chaque fichier est d'abord transformé en module LLVM. Mais en C2, le développeur peut choisir entre deux modes : le mode multimodule et le mode module unique. En mode multimodule (par défaut), tous les fichiers source d'un même module C2 sont transformés en un seul module LLVM. Le mode module unique quant à lui vise à permettre encore plus d'optimisation, car C2 convertit tous les fichiers source en un seul module LLVM, permettant une LTO (link-time optimization ou optimisation à l'édition des liens) complète.

Compilation (par fichier) avec C

Compilation avec C2 : mode multimodule (par défaut)

Compilation avec C2 : mode module unique

C2 fournit aussi les types primitifs prédéfinis suivants : bool ; i8, i16, i32, i64 ; u8, u16, u32, u64 ; f32, f64 ; et char (égal à i8). Les types int et float par défaut ont été supprimés avec les modificateurs de type short, long, signed ou unsigned. La macro NULL a aussi été remplacée par le mot-clé nil.

Une autre différence entre C et C2 est que C2 introduit une syntaxe de type uniforme. L'équipe derrière C2 estime en effet que les définitions de type en C sont parfois difficiles à lire. Aussi la syntaxe est un peu bizarre avec le typedef. Pour cela, C2 fournit une syntaxe uniforme pour définir de nouveaux types. Entre autres différences entre les deux langages, on peut encore noter des diagnostics plus stricts, les attributs, un tooling et des fonctionnalités spéciales dans C2. Les changements par rapport à C sont plus détaillés dans la documentation officielle de C2.

Cela dit, pourquoi donc choisir C2 par rapport C ? La réponse à cette question, d'après les créateurs de C2, se trouve dans les avantages que présente leur langage :

un développement plus rapide. Leurs tests auraient en effet montré une diminution d'environ 30 % du temps de développement avec C2 ;
un accès facile à des fonctionnalités telles que LTO (link-time optimization) ;
de meilleurs diagnostics (ce qui, encore une fois, accélère le développement) ; et
un contrôle plus facile de l'architecture avec c2reto.

Source : C2lang

Et vous ?

Que pensez-vous des objectifs du langage C2 ?

Croyez-vous qu'il fera une bonne alternative à C ? Pourquoi ?

Voir aussi :

Pourquoi les langages C et C++ auraient-ils encore de nombreuses années devant eux ? Donnez votre avis

Index TIOBE : C sacré langage de programmation de l'année 2017, Python enregistre encore la plus forte progression annuelle sur PYPL

Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D

**Matthieu76** · 01/02/2018, 16h22

Bof, je sais pas trop quoi en penser ... Je trouve que c'est beaucoup pour pas apporter grand-chose.

Personnellement, je pense qu'il y a trop de language de programmation. Après ça sera quoi, le C++2 ???

**transgohan** · 01/02/2018, 16h52

Je reste très sceptique...
Cela ne semble pas apporter grand chose, de plus quand je vois qu'ils annoncent 30% de gain de temps de codage alors que l'exemple hello world :

Code :

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

1
2
3
4
5
6
7
8
module hello_world;
 
import stdio as io;
 
func i32 main(i32 argc, char*[] argv) {
    io.printf("Hello World!\n");
    return 0;
}

Comporte plus de mot clé qu'un programme codé en C... On a envie de leur demander un compte rendu exhaustif de leurs tests...
Parce que personnellement je mettrai forcément plus de temps à écrire ce code que le même en C, c'est physique...

**MrKuja** · 01/02/2018, 17h03

Envoyé par transgohan

Je reste très sceptique...
Cela ne semble pas apporter grand chose, de plus quand je vois qu'ils annoncent 30% de gain de temps de codage alors que l'exemple hello world :

Code :

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

1
2
3
4
5
6
7
8
module hello_world;
 
import stdio as io;
 
func i32 main(i32 argc, char*[] argv) {
    io.printf("Hello World!\n");
    return 0;
}

Comporte plus de mot clé qu'un programme codé en C... On a envie de leur demander un compte rendu exhaustif de leurs tests...
Parce que personnellement je mettrai forcément plus de temps à écrire ce code que le même en C, c'est physique...

Pour voir son intérêt il ne faut pas se limiter à un simple hello world.
Si le C2 apporte plus de cohérence cognitive, quitte à ce que certains morceaux soit un poil plus verbeux sincèrement c'est mieux.

Le gain de la syntaxe et du système se verrait sur des cas concrets dépassant le hello world.

On verra dans le temps si ça prend. Ou non...

**grunk** · 01/02/2018, 17h06

Envoyé par Matthieu76

Après ça sera quoi, le C++2 ???

C++20

Le "problème" de C c'est qu'il évolue très doucement. Une spec en 99 , une en 2011 , je comprend que si on commence un projet en 2018 , travaillé avec un spec d'il y'a 7 ans peu être frustrant.
C++ de son coté à un rythme de màj de 3 ans (11,14,17,20,...) qui apporte à chaque fois des évolutions bienvenues

**huguesacker** · 01/02/2018, 17h18

Je trouve que c'est une bonne nouvelle. Oui, il y a beaucoup de langages, mais le boulot c'est aussi de choisir celui qui est le plus adapté, et qui offre le plus d'outils et facilités de développement, pour ce qu'on veut faire.
Bien entendu il faut aussi des bibliothèques, mais rien que le fait d'avoir des importations de modules plutôt que des includes, sans parler de toutes les simplifications au niveau du préprocesseur et des types, c'est déjà formidable. En effet, u64 pour "unsigned long long" (par exemple), c'est quand même plus parlant, sans compter que les tailles int et long varient en fonction des machines et/ou compilateurs...
Cela fait plaisir de voir que des informaticiens continuent à réfléchir à comment améliorer nos outils de développement, je trouve.
Chez nous, on a décidé de l'essayer, et on va voir ce que cela va donner. C'est le genre d'initiatives à encourager.

MikeRowSoft · 01/02/2018, 17h29

Envoyé par grunk

Le "problème" de C c'est qu'il évolue très doucement. Une spec en 99 , une en 2011 , je comprend que si on commence un projet en 2018 , travaillé avec un spec d'il y'a 7 ans peu être frustrant.
C++ de son coté à un rythme de màj de 3 ans (11,14,17,20,...) qui apporte à chaque fois des évolutions bienvenues

Comme tu semble vraiment bien t'y connaitre, je me permet de te poser une question qui me tracasse depuis quelque temps et pour laquelle je n'ai pas vraiment envie de fouiller sur Internet.

Question E.D.I. , des changements ont-ils été nécessaires lors de " l'évolution " du compilateur ?

**Kannagi** · 01/02/2018, 17h54

Je doute que le langage C sera remplacé , encore une fois concurrencer le C veut dire vouloir concurrencer toutes les plateformes qu'ils visent (et ça doit être le seul qui vise effectivement tout les CPU existants ) , les lib et tout le code fourni jusqu’à présent chose très peu probable que C2 va être une alternative sérieuse.
Surtout que le C est utilisé sur des programmes très spécifiques , qui code une GUI en C ? presque personne x)
Qui va le faire donc en C2 ? Ben presque personne xD

Par contre un truc ou il risque pas de concurrencer le C , c'est dans un langage portable et performant (et je me demande vraiment si les concepteurs du langages ont réfléchi mûrement a leur décisions) :
"Les types int et float par défaut ont été supprimés"
Cool on va devoir remplacer manuellement tout nos i32 par i16 ou i8 suivant la plateforme

Le C est utilisé pour Linux , bon la c'est certain on va pas recodé les millions de lignes sur C2 (en plus il vise moins de plateforme que le compilo GCC ).
L'embarqué ? oui en utilise le C , mais aussi son remplaçant commence a être le C++.

De toute façon depuis l'arrivé de LLVM j'ai remarqué que de nombreux nouveau langages sont apparu :p

**Uther** · 01/02/2018, 19h29

A première vue je trouve qu'il y a de très bonnes choses mais le positionnement est mauvais.
Viser a se présenter en successeur du C peut être une bonne stratégie, mais dans ce cas là, il faudrait garder une compatibilité maximale avec l'existant, quitte a ce que ça soit sous forme dépréciée. Or là, de ce que je vois, des points basique de la syntaxe comme la déclaration des fonction et des types sont changés.

Si c'est pour avoir un langage incompatible, autant prendre un langage qui propose plus. Parce que des langage qui se posent en remplaçant de C pour la programmation bas niveau, et qui offrent tout ce que propose C2 et bien plus, ça se bouscule déjà au portillon avec notamment Rust, Jai ou Nim.

Envoyé par Kannagi

Je doute que le langage C sera remplacé , encore une fois concurrencer le C veut dire vouloir concurrencer toutes les plateformes qu'ils visent (et ça doit être le seul qui vise effectivement tout les CPU existants ) , les lib et tout le code fourni jusqu’à présent chose très peu probable que C2 va être une alternative sérieuse.

Pour les libs, à peu près tous les langages savent plus ou moins bien s'interfacer avec du C. Et comme le C2 se veut un langage de bas niveau, comme Rust et Nim, ça devrait se faire sans problème.
Et de ce que j'ai pu voir de la doc il est prévu de pouvoir générer du C ce qui résoudrait le problèmes des CPU non mainstream.

**Madmac** · 01/02/2018, 20h34

Il n'y a pas beaucoup de chair sur l'os. L'introduction de nouveaux type de base va nous débarrassé de la gestion de la destruction de ces types. Un véritable progrès aurait été de nous débarrasser de ces corvées, même pour les type définies par l'utilisateur. Après tout, le principal handicap de ce langage est les fuites de mémoire qu'il produit.

D'un autre coté, le principal progrès n'est peut-être pas évident. Cette nouvelle représentation interne du langage va peut-être permettre de nouvelle optimisation. En C++, l'utilisation des directives d'optimisation ressemblent encore à une forme de loto. Espérons du progrès de ce coté

**nougatine999** · 02/02/2018, 02h52

Je pense que chaque nouveau langage qui émerge de nos jours n'est qu'une surcouche du C avec une optimisation de la façon de le coder pour certains (comme le C2). On simplifie peut-être la forme mais on ne change pas le fond ..

**LordMacharius** · 02/02/2018, 10h03

Envoyé par Madmac

Il n'y a pas beaucoup de chair sur l'os. L'introduction de nouveaux type de base va nous débarrassé de la gestion de la destruction de ces types. Un véritable progrès aurait été de nous débarrasser de ces corvées, même pour les type définies par l'utilisateur. Après tout, le principal handicap de ce langage est les fuites de mémoire qu'il produit.

Tu sembles encore une fois donner un défaut au C qui n'en n'est pas un. Les fuites mémoires du C sont le fait des développeurs et non pas du langage. Le C est là pour avoir le contrôle sur la mémoire justement et donc c'est de la responsabilité des développeurs de savoir la gérer. Si tu retires cette partie de ce que propose le C, l'intérêt est moins grand d'un coup pour ce langage.

Pour revenir sur le sujet, effectivement le manque de compatibilité avec l’existant est un vrai frein à son adoption en tant que successeur.

Je pense que chaque nouveau langage qui émerge de nos jours n'est qu'une surcouche du C avec une optimisation de la façon de le coder pour certains (comme le C2). On simplifie peut-être la forme mais on ne change pas le fond ..

Je suis tout à fait d'accord avec ce que tu dis nougatine, néanmoins je ne manquerais pas de me pencher dessus et de le tester pour un projet perso ou deux histoire de me faire une opinion plus construite.

**hotcryx** · 02/02/2018, 11h03

Envoyé par Kannagi

Cool on va devoir remplacer manuellement tout nos i32 par i16 ou i8 suivant la plateforme

Dans le genre "code bien pourri", il suffirait de les laisser typer sans préciser la taille int, short, long, bigint... (comme le fait le c).
C'est à la compilation que tout va se définir pour les tailles réelles en 8, 16, 32.
De cette manière, le code source ne change pas.

**Matthieu76** · 02/02/2018, 11h54

Envoyé par hotcryx

il suffirait de les laisser typer sans préciser la taille int, short, long, bigint... (comme le fait le c).
C'est à la compilation que tout va se définir pour les tailles réelles en 8, 16, 32.
De cette manière, le code source ne change pas.

Oui mais des fois on a besoin que de 16 bits pour certain calcul et d'autre fois 64. Par exemple dans les dernières version de CUDA les calculs ont été optimiser pour le 16 bits donc dans pas mal de cas où la précision importe peu comme le deep learning ou le jeux vidéo, utiliser des float 16 au lieu de float 32 double théoriquement le temps de calcul.
Je pense sincèrement que le C2 peut être très intéressant pour du code sur GPU.

**Uther** · 02/02/2018, 11h56

Envoyé par Kannagi

Surtout que le C est utilisé sur des programmes très spécifiques , qui code une GUI en C ? presque personne x)
Qui va le faire donc en C2 ? Ben presque personne xD

C'est un biais que je retrouve tous le temps dans les commentaires de developpez.com qui m'agace de plus en plus. Un technologie n'a pas obligation d'être utilisée par tout le monde pour avoir un intérêt.
Pas grand monde ne code de GUI en C, pourtant ça reste un des langages les plus utilisés. Donc si C2 arrive a répondre aux besoin de ceux qui font du C, il peut tout a fait avoir son intérêt.

Envoyé par Kannagi

Par contre un truc ou il risque pas de concurrencer le C , c'est dans un langage portable et performant (et je me demande vraiment si les concepteurs du langages ont réfléchi mûrement a leur décisions) :
"Les types int et float par défaut ont été supprimés"
Cool on va devoir remplacer manuellement tout nos i32 par i16 ou i8 suivant la plateforme

Alors justement les int et float de taille variable sont un vrai problème pour les performance et la portabilité. Car avoir des performances et des résultats de calculs qui peuvent être différents en fonction de la plateforme, c'est un vrai souci. C'est pas pour rien que tous les langages modernes ont fait le choix de privilégier les types de taille fixe.

Envoyé par Kannagi

Le C est utilisé pour Linux , bon la c'est certain on va pas recodé les millions de lignes sur C2 (en plus il vise moins de plateforme que le compilo GCC ).

Encore une fois, c'est une vision bien trop binaire du problème. Bien sur que l'on ne va pas réécrire un projet comme Linux dans un autre langage du jour au lendemain. Mais il n'est pas idiot de considérer la pertinence d'un nouveau langage pour de nouvelles applications ou lors de la refonte en profondeur de parties cohérentes de l'existant. Le fait que le langage s'intègre bien avec l'existant est cela dit un point essentiel pour pourvoir faire ça.
Par exemple Mozilla utilise le langage Rust pour les nouveaux composants de Firefox, tout en gardant JavaScript et C++ pour le code existant.

Envoyé par Kannagi

De toute façon depuis l'arrivé de LLVM j'ai remarqué que de nombreux nouveau langages sont apparu :p

C'est sur que LLVM facilite grandement la création d'un nouveau compilateur, tout particulièrement en ce qui concerne l'optimisation qui est la partie la plus complexe.

Envoyé par LordMacharius

Tu sembles encore une fois donner un défaut au C qui n'en n'est pas un. Les fuites mémoires du C sont le fait des développeurs et non pas du langage. Le C est là pour avoir le contrôle sur la mémoire justement et donc c'est de la responsabilité des développeurs de savoir la gérer. Si tu retires cette partie de ce que propose le C, l'intérêt est moins grand d'un coup pour ce langage.

Sauf que ça nécessite de supposer que les programmeurs sont parfaits et ne commettent pas d'erreur, or même les meilleurs programmeurs font des erreurs, c'est prouvé. Il suffit de regarder les patch notes des principaux OS et navigateurs web pour voir qu'une très grosse partie des erreurs critiques corrigées ne seraient pas arrivés avec un langage plus sur. Pourtant il s'agit de projet surveillés qui sont développés par des gens compétents et qui sont relus.

Alors c'est vrai que parfois il faut certaines libertés pour atteindre un certain niveau de performances, mais on ne peux pas dire que la possibilité de faire tout et n'importe quoi n'est pas un problème. Et il y a quand même pas mal de chose que l'on peut améliorer sans compromettre les performances. Typiquement c'est ce que vise a faire Rust.

Envoyé par nougatine999

Je pense que chaque nouveau langage qui émerge de nos jours n'est qu'une surcouche du C avec une optimisation de la façon de le coder pour certains (comme le C2). On simplifie peut-être la forme mais on ne change pas le fond ..

Il faudrait que tu détailles plus ce que tu veux dire, parce que là ça me parles pas vraiment. Tu peux tout aussi dire que le C est une surcouche de l'assembleur qui est lui même une surcouche du langage machine. Ça ne rend pas le C inintéressant pour autant.

Nim, Rust, C++ apportent quand même pas mal de nouveaux concepts par rapport au C tout en restant foncièrement des langages impératifs. Tu peux appeler ça une surcouche du C, mais le C lui même c'est pas le premier langage impératif, loin de là.

Par contre si tu regardes du coté de Haskell, R, F# ... tu verras quand même des façons très différentes d'aborder la programmation. C'est difficile de comparer ces langages à des surcouches du C

**grunk** · 02/02/2018, 13h22

Envoyé par MikeRowSoft

Question E.D.I. , des changements ont-ils été nécessaires lors de " l'évolution " du compilateur ?

Oui et non.
Disont que si ton compilo est à jour et que ton EDI est capable de travailler avec n'importe quel compilo tu n'as pas forcément besoin de mettre à jour ton EDI pour développer.
Dans les faits , même si le compilo n'est pas étroitement lié, l'EDI propose tout un tas de fonctionnalité (auto complétion , analyse statique , etc ...) qui ne sont compatible que jusqu'à une certaine version de C ou C++. Si tu veux utiliser une fonctionalité de C++17 dans un EDI qui ne supporte que C++11 par exemple tu aura des erreurs.

**Kannagi** · 02/02/2018, 13h30

Envoyé par Uther

C'est un biais que je retrouve tous le temps dans les commentaires de developpez.com qui m'agace de plus en plus. Un technologie n'a pas obligation d'être utilisée par tout le monde pour avoir un intérêt.
Pas grand monde ne code de GUI en C, pourtant ça reste un des langages les plus utilisés. Donc si C2 arrive a répondre aux besoin de ceux qui font du C, il peut tout a fait avoir son intérêt.

La raison de l'utilisation du C le plus utilisé , c'est que c'est le langage le plus utilisé par les étudiants voila l'explication

On tout cas il ne répond clairement pas a mes besoins pour le moment (et je programme en C au passage ).

Envoyé par Uther

Alors justement les int et float de taille variable sont un vrai problème pour les performance et la portabilité. Car avoir des performances et des résultats de calculs qui peuvent être différents en fonction de la plateforme, c'est un vrai souci. C'est pas pour rien que tous les langages modernes ont fait le choix de privilégier les types de taille fixe.

Non définir la taille enlève les performances obligatoirement

Faire des calculs 32 bits sur du 8/16 bits te prendra forcément beaucoup plus de temps que de faire un calcul sur 8 bits , donc définir les tailles sans prendre en compte les contraintes de la plateforme cible , brime forcément les performances.
Et donc la seule façon de concilier les deux (portabilité et performance) et que le int varie suivant la cible.

Et si tu en doute toujours en pseudo-assembleur 8 bits si tu veux faire du 16 bit tu ferait ça :
Pour un load

Code :

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

1
2
3
 
load  r0,addr+0
load  r1,addr+1

Pour une addition

Code :

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

1
2
3
 
add  r0,r2
adc  r1,r3

ect ect , en-faite tu augmente le taux de cycle par deux en faisant du 16 bits(pour être exact ça peut être plus parce que faudra forcément clear le carry) , sur du 8 bits pour faire du 32 bits par 4 etc , mais bien sur c'est performant ... et en plus ça complexifie le code générer (et ça prend pas mal de registre)

(et inversement tu ne peux avoir que du full 32 bits sur certain CPU ).

Pour les floats , j'ai pas compris ou tu veux en venir (parce que le float existe partout quasiment comparé au double qui est plus long a l’exécution et donc peut être moins courant ), de plus il est plus intéressant d'utiliser les float , deja parce qu'il est normalisé (donc sa taille est toujours de 32 bits), et deux que le compilo bien optimiser pourra utiliser des instructions SIMD qui utilise ... des floats !

**KsassPeuk** · 02/02/2018, 13h35

Il y a pas mal de trucs qui me gênent avec ce "nouveau" langage. Le premier point, et à mon avis le plus important, c'est : "bordel où est la définition du langage ?". Le principal problème de C aujourd'hui reste quand même que sa norme, même si elle n'est pas si longue, est un bordel d'enfer avec des corner-cases partout, des ambiguïtés, des trucs franchement déplorable d'un point de vue définition (coucou strict aliasing rule) et la combinaison de ça c'est un joyeux foutoir. Et là, on a juste l'impression que c'est encore pire. La doc est pour ainsi dire inexistante.

Ensuite, on annonce sur le site "better diagnostics" dans les objectifs. Et là direct la question c'est : on a quoi pour les diagnostiques en question ? Parce que C commence à être bien équipé avec de l'analyse dynamique efficace (les debuggers C ont un overhead acceptable, on a les sanitizers), des analyseurs statiques qui marchent bien (clang-tidy et autres trucs du genre) et même des analyseurs statiques formels et sound (Frama-C, VCC, Verifast, ...). Et pour ces derniers, ça a notamment impliqué de définir formellement ce qu'est un programme C correct, ce qui a demandé un sacré boulot. Là l'idée c'est de recommencer pour ce langage qui ne semble franchement pas être mieux défini que C.

Concrètement sur les points de la capacité à analyser les programmes qu'on écrit Rust semble largement mieux parti (par exemple avec des choses comme Patina ou le projet RustBelt). Et on a quelque part de besoin de quelque chose de mieux conçu que C pour les tâches qu'on réalise avec (notamment dans le critique), parce que la norme est un vrai problème pour avoir des compilateurs et des programmes qui tiennent la route avec un très haut niveau de qualité. Il y a qu'à voir comment les développeurs de CompCert ou seL4 en ont chié alors que c'est des tueurs.