Le projet Carbon, un successeur expérimental du C++, explore une direction future possible pour le C++ étant donné les difficultés à l'améliorer
Et mise sur l'interopérabilité comme base de travail
Le 2022-07-20 14:32:02, par Patrick Ruiz, Chroniqueur Actualités
En février 2020, un vote crucial a eu lieu au sein du comité de normalisation du C++ sur la rupture de la compatibilité ABI en faveur de la performance. L’initiative principalement poussée par les employés de Google a échoué. Résultat : de nombreux Googlers ont cessé de participer à la normalisation du C++, ont démissionné de leur rôle officiel au sein du comité, et le développement de clang a considérablement ralenti. C’est de cette rupture que naît le projet Carbon annoncé comme successeur du C++. L’objectif : explorer une direction future possible pour le C++ étant donné les difficultés à l’améliorer. Le projet Carbon mise sur l’interopérabilité avec le C++ comme base de travail.
Lors d'un récent évènement dédié au langage C++ cette semaine à Toronto, Chandler Caruth, ingénieur logiciel chez Google, a présenté le langage Carbon, décrit comme un successeur expérimental du C++, suscitant un vif intérêt au sein de la communauté C++.
« Nous comprenons l'intérêt de la communauté pour cette keynote. Nous publierons l'enregistrement selon un calendrier accéléré », ont déclaré les organisateurs de la conférence sur Twitter. Carruth est responsable technique des principaux langages de programmation et de l'évolution des langages de Google. Il représente Google au sein du comité des normes C++ et contribue à LLVM et Clang.
Les développeurs de Carbon expliquent que si le C++ est le langage dominant pour les logiciels à performances critiques, son héritage et sa dette technique signifient que l'amélioration incrémentale du C++ est extrêmement difficile.
Une solution consiste à migrer vers d'autres langages tels que Rust, Kotlin, Swift ou Go, mais il est difficile de migrer vers ces derniers à partir du C++. De plus, dans certains cas, ces derniers présentent une surcharge de performance. Carbon est un nouveau langage qui vise à égaler les performances de C++ et à maintenir une interopérabilité bidirectionnelle transparente, ainsi qu'une courbe d'apprentissage douce pour les développeurs C++.
L'équipe promet en sus un certain niveau de traduction de source à source pour le code C++. Le projet présente des parallèles avec TypeScript pour les développeurs JavaScript, ou Kotlin pour les développeurs Java, bien que la comparaison ne soit pas exacte. Carbon est conçu pour être interopérable avec le code C++ et pour faciliter la migration. La chaîne d'outils Carbon prendra en charge la compilation du code C++.
Pourquoi le C++ est-il difficile à améliorer ? Parce que le langage lui-même a commencé comme une bifurcation du C. Le langage C a 50 ans, il n'est donc pas surprenant qu'il y ait beaucoup d'héritage. Selon l'équipe Carbon, les concepteurs du C++ ont ajouté plutôt que remplacé des fonctionnalités du langage au fil du temps, créant ainsi des interactions complexes entre les fonctionnalités. La préservation de la compatibilité binaire est un autre problème hérité. En outre, le comité C++ et le processus d'évolution sont orientés vers la normalisation plutôt que la conception, sont lents et ne parviennent pas toujours à prendre des décisions.
Carbon s'efforce de contourner ces problèmes en adoptant une nouvelle approche fondée sur les principes de l'open source. « Nous tenterons même de combler une énorme lacune dans l'écosystème C++ avec un gestionnaire de paquets intégré », peut-on lire dans les documents. La feuille de route actuelle vise à terminer la version 0.1 du langage cette année, la 0.2 en 2023 et la version 1.0 en 2024 ou 2025.
Le langage Carbon sera familier aux développeurs C++ et C, mais il y a aussi de nombreuses différences. Les fonctions sont déclarées avec le mot clé fn et les variables avec var. Il existe également des tuples fortement typés. L'inférence de type est supportée par le mot-clé auto. Les pointeurs sont pris en charge mais pas l'arithmétique des pointeurs ; les seules opérations sur les pointeurs sont l'adressage et le déréférencement. Les classes supportent l'héritage simple mais pas l'héritage multiple.
La sécurité de la mémoire est une considération importante mais n'est pas l'objectif initial. « La différence entre l'approche de Rust et celle de Carbon est que Rust commence par la sécurité et que Carbon commence par la migration », peut-on lire dans la documentation. L'approche consiste à simplifier le langage afin de créer de l'espace pour les fonctionnalités de sécurité, puis à refaire l'ingénierie des fondations pour modéliser et appliquer la sécurité.
Le projet est sous licence Apache 2 avec des exceptions LLVM. L'équipe prévoit de créer une fondation open source et de lui transférer tous les droits liés à Carbon. « Notre objectif est que la configuration de la fondation soit similaire à d'autres projets open source tels que LLVM ou Kubernetes », ajoute-t-elle. Cependant, le projet exige actuellement que les contributeurs acceptent le CLA (contributor license agreement) de Google, ce qui peut poser problème à certains. Google finance également l'infrastructure de Carbon.
Sur la question de savoir pourquoi ne pas utiliser d’autres langages comme Rust, les têtes derrière l’initiative répondent : « Si vous voulez utiliser Rust, et que c'est techniquement et économiquement viable pour votre projet, vous devriez utiliser Rust ». Toutefois, la question de Rust est au cœur de la réussite future du projet Carbon. En effet, Rust est de l’avis de plusieurs observateurs en passe de devenir le langage de bas niveau standard. Néanmoins, on continue de compter plus de lancements de projets pilotés en C++ qu’en Rust et donc toute possibilité d’aller au-delà du C++ tout en conservant l’interopérabilité doit faire office de bonne nouvelle.
Source : Carbon
Et vous ?
Êtes-vous en accord avec l’argumentaire (le langage C++ est difficile à faire évoluer) qui a mené au lancement du projet Carbon ?
Êtes-vous développeur C++ ? Quelle plus-value reconnaissez-vous à ce projet ? Sinon qu’en attendez-vous ?
Le projet Carbon vient-il avec une plus-value véritable en comparaison à un langage comme le Rust considéré le futur pour ce qui est du développement d’applications système ?
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
Lors d'un récent évènement dédié au langage C++ cette semaine à Toronto, Chandler Caruth, ingénieur logiciel chez Google, a présenté le langage Carbon, décrit comme un successeur expérimental du C++, suscitant un vif intérêt au sein de la communauté C++.
« Nous comprenons l'intérêt de la communauté pour cette keynote. Nous publierons l'enregistrement selon un calendrier accéléré », ont déclaré les organisateurs de la conférence sur Twitter. Carruth est responsable technique des principaux langages de programmation et de l'évolution des langages de Google. Il représente Google au sein du comité des normes C++ et contribue à LLVM et Clang.
Les développeurs de Carbon expliquent que si le C++ est le langage dominant pour les logiciels à performances critiques, son héritage et sa dette technique signifient que l'amélioration incrémentale du C++ est extrêmement difficile.
Une solution consiste à migrer vers d'autres langages tels que Rust, Kotlin, Swift ou Go, mais il est difficile de migrer vers ces derniers à partir du C++. De plus, dans certains cas, ces derniers présentent une surcharge de performance. Carbon est un nouveau langage qui vise à égaler les performances de C++ et à maintenir une interopérabilité bidirectionnelle transparente, ainsi qu'une courbe d'apprentissage douce pour les développeurs C++.
L'équipe promet en sus un certain niveau de traduction de source à source pour le code C++. Le projet présente des parallèles avec TypeScript pour les développeurs JavaScript, ou Kotlin pour les développeurs Java, bien que la comparaison ne soit pas exacte. Carbon est conçu pour être interopérable avec le code C++ et pour faciliter la migration. La chaîne d'outils Carbon prendra en charge la compilation du code C++.
Pourquoi le C++ est-il difficile à améliorer ? Parce que le langage lui-même a commencé comme une bifurcation du C. Le langage C a 50 ans, il n'est donc pas surprenant qu'il y ait beaucoup d'héritage. Selon l'équipe Carbon, les concepteurs du C++ ont ajouté plutôt que remplacé des fonctionnalités du langage au fil du temps, créant ainsi des interactions complexes entre les fonctionnalités. La préservation de la compatibilité binaire est un autre problème hérité. En outre, le comité C++ et le processus d'évolution sont orientés vers la normalisation plutôt que la conception, sont lents et ne parviennent pas toujours à prendre des décisions.
Carbon s'efforce de contourner ces problèmes en adoptant une nouvelle approche fondée sur les principes de l'open source. « Nous tenterons même de combler une énorme lacune dans l'écosystème C++ avec un gestionnaire de paquets intégré », peut-on lire dans les documents. La feuille de route actuelle vise à terminer la version 0.1 du langage cette année, la 0.2 en 2023 et la version 1.0 en 2024 ou 2025.
Le langage Carbon sera familier aux développeurs C++ et C, mais il y a aussi de nombreuses différences. Les fonctions sont déclarées avec le mot clé fn et les variables avec var. Il existe également des tuples fortement typés. L'inférence de type est supportée par le mot-clé auto. Les pointeurs sont pris en charge mais pas l'arithmétique des pointeurs ; les seules opérations sur les pointeurs sont l'adressage et le déréférencement. Les classes supportent l'héritage simple mais pas l'héritage multiple.
La sécurité de la mémoire est une considération importante mais n'est pas l'objectif initial. « La différence entre l'approche de Rust et celle de Carbon est que Rust commence par la sécurité et que Carbon commence par la migration », peut-on lire dans la documentation. L'approche consiste à simplifier le langage afin de créer de l'espace pour les fonctionnalités de sécurité, puis à refaire l'ingénierie des fondations pour modéliser et appliquer la sécurité.
Le projet est sous licence Apache 2 avec des exceptions LLVM. L'équipe prévoit de créer une fondation open source et de lui transférer tous les droits liés à Carbon. « Notre objectif est que la configuration de la fondation soit similaire à d'autres projets open source tels que LLVM ou Kubernetes », ajoute-t-elle. Cependant, le projet exige actuellement que les contributeurs acceptent le CLA (contributor license agreement) de Google, ce qui peut poser problème à certains. Google finance également l'infrastructure de Carbon.
Sur la question de savoir pourquoi ne pas utiliser d’autres langages comme Rust, les têtes derrière l’initiative répondent : « Si vous voulez utiliser Rust, et que c'est techniquement et économiquement viable pour votre projet, vous devriez utiliser Rust ». Toutefois, la question de Rust est au cœur de la réussite future du projet Carbon. En effet, Rust est de l’avis de plusieurs observateurs en passe de devenir le langage de bas niveau standard. Néanmoins, on continue de compter plus de lancements de projets pilotés en C++ qu’en Rust et donc toute possibilité d’aller au-delà du C++ tout en conservant l’interopérabilité doit faire office de bonne nouvelle.
Source : Carbon
Et vous ?
Voir aussi :
-
grunkModérateurDepuis C++11 tu as les smartpointer qui permettent dans la grande majorité des cas de ne pas faire de fuite mémoire puisqu'on à plus gérer la désallocation
Et au contraire je trouve que la direction de C++ est très claire => faciliter son utilisation et se rapprocher des langages de plus haut niveau dans l'utilisation tout en gardant les performances qui font le succès de C++.
Entre du C++98 et du C++20 c'est le jour et la nuit.
Pour moi le gros défaut de C++ c'est qu'il y'a des dizaines de façon différentes de faire la même chose en fonction du niveau d'optimisation qu'on veux atteindre. Ca rend les choses extrêmement compliqué et la courbe d'apprentissage plutôt raide.
Je me débrouille en C++ et parfois je me mets à lire le code de certaines lib (genre boost) et je me rend compte que je suis une sous merde parce que je ne comprend pas la moindre ligne de ce que je lisle 27/07/2022 à 11:35 -
AoCannailleExpert confirméça me fait plaisir de lire ça, je suis exactement dans le même cas ^^' ça soulage un peu mon syndrome de l'imposteurle 27/07/2022 à 11:55
-
Pierre Louis ChevalierExpert éminent séniorTrès bon article
C++ est devenu clairement une usine à gaz compliquée et incompréhensible sauf pour quelques experts.
La syntaxe de Carbon semble ressembler pas mal à Rust, comment un tel projet pourrais t'il se positionner par exemple par rapport à C++, D et Rust ?le 20/07/2022 à 15:42 -
walfratMembre éméritele 25/07/2022 à 8:56
-
AstrayaMembre chevronnéEt le fait qu'il soit recompilé pour CHAQUE translation unit aussi? Que l'on dois jouer avec les namespaces et les collisions de noms? Et donc qu'on se retrouve avec des préfixes dans les noms pour comblé un problème du langage?
Et le mainteneur ou collègue qui passe derrière dois se plonger dans la tête de l'ancien programmeur? C'est pas une vision égoïste du travaille? "Moi je comprends ce que j'ai fais c'est pas compliqué, ils sont nulles les autres si il arrive pas a passer derrière".
Après plusieurs années à faire du C++, mon principal sujet quand je code c'est "comment protégés mon code", "comment le rendre maintenable sans effort" sans ajouter de commentaire partout en disant "Attention c'est super compliqué".
Il n'est sûr pour personne, et le novice pense toujours être un dieu en C++ jusqu’à ce qu'il se plante et généralement c'est dans la semaine après son embauche...
Renseigne toi avant de dire ça. Rust est plus rapide que C++ sur de nombreux points ET apporte de la sécurité. La contrepartie n'est pas la performance, c'est plus d'effort de la part du programmeur pour penser correctement son application en terme de design, architecture et utilisation mémoire.
D'autres aspect rentre en compte, comme l'aliasing de pointeur.
Je t'invite à leur proposer tes solutions = > https://isocpp.org/std/meetings-and-...s-and-mailings
Ah bon? sur de sur? alors où placer std::initializer_list? Comment faire std::vector<int> v = {1,2,3}; sans ça? c'est pourtant dans la std... et l'implémentation dépend de la librairie standard qui est fortement lié au compilateur.
Et ou placer std::construct_at qui est le seul autorisé à construire un objet à un emplacement mémoire spécifique dans une évaluation constante (aka constexpr)?
Le C++ est coincé, il se débloque en ajoutant un peu plus de flou et de complexité partout mais ça ne fait que grossir la complexité et au final le ralentir dans certains cas.
Un peu comme les instructions x86 des processeurs Intel ou AMD qui sont toujours ajoutés, jamais retiré, jamais modifié. Résultat... plus de 1300 instructions dans les CPU X86 contre ~40 pou RISC-V 32bits et ~500 pour ARM 32 bits... Et pour faire la meme chose.le 21/07/2022 à 11:36 -
smartiesExpert confirméSur Android en partie
En Web, je dirais que c'est plutôt Go
Mais JAVA est encore énormément utilisé
Il aurait peut été été plus judicieux d'enrichir RUST (langage, bibliothèques, documentation, best practices, exemples) plutôt que de créer un autre langagele 26/07/2022 à 12:43 -
PyramidevExpert éminentLes auteurs de Carbon ont répondu dans leur FAQ : Why not Rust?
Je ne copie-colle pas la réponse en entier, mais seulement le début :If you can use Rust, ignore Carbon
If you want to use Rust, and it is technically and economically viable for your project, you should use Rust. In fact, if you can use Rust or any other established programming language, you should. Carbon is for organizations and projects that heavily depend on C++; for example, projects that have a lot of C++ code or use many third-party C++ libraries.
We believe that Rust is an excellent choice for writing software within the pure Rust ecosystem. Software written in Rust has properties that neither C++ nor Carbon have. When you need to call other languages from Rust, RPCs are a good option. Rust is also good for using APIs implemented in a different language in-process, when the cost of maintaining the FFI boundary is reasonable.le 20/07/2022 à 23:37 -
23JFKMembre expertC'est la mode du moment de tout "révolutionner" avec des var et de fn, et pourquoi pas aussi des begin et des end... Mais au final, l'original restera dominant et ces forks vulgaires péricliteront avec leurs utilisateurs.le 21/07/2022 à 14:40
-
smartiesExpert confirméPour avoir fait un peu de C et de C++ il y a eu des problèmes très agaçants :
- les bibliothèques non portées sur différents OS et une compilation pas toujours facile, sur RUST c'est beaucoup moins le cas
- une syntaxe pas toujours lisible, avec RUST il faut plutôt comprendre certains concepts
- des fuites mémoires pas toujours facile à trouver
- un manque d'industrialisation, quand je vois Cargo et la facilité d'écrire des tests unitaires en RUST, je me demande si les autres langages ont pensé à mettre ça dans leur feuille de route (OK pour les dépendances, JAVA a Maven, Go a quelque chose de similaire, Python a pip, ...)
PS : je suis développeur pythonle 26/07/2022 à 22:04 -
FagusMembre expertC'est peut être justement pour ça que google a lancé des langages neufs simplifiés comme go. Justement pour que les gens arrêtent d'être créatifs en écrivant un code génial que personne d'autre n'arrive à comprendre, ce qui arrive assez vite grâce à 50 ans d'héritage, sans compter les concepts qui cachent du code comme la surcharge...
Plus haut quelqu'un a dit que c'est dommage d'avoir retiré l'héritage multiple. Ben oui, ça sert, mais quand on se retrouve avec un objet qui hérite de 25 autres classes avec des schémas tordus, ça augmente les chances d'avoir un comportement différent de ce qu'on avait imaginé.
J'imagine que c'est dans ce but qu'ils l'ont enlevé.There should be one– and preferably only one –obvious way to do it.) le 27/07/2022 à 19:03