Discussion :

[Patrick Ruiz]

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

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

[Pierre Louis Chevalier]

Trè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 ?

[Madmac]

Trè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 ?

Simple question. Pourquoi Objective C n'est pas inclus dans ton analyse?

[dourouc05]

Probablement parce que Objective-C n'a pas vraiment de futur (contrairement au C, au C++, etc.) ? Il est plus ou moins limité aux plateformes Apple et est en cours de remplacement par Swift, qui est lui en développement plus actif.

[daerlnaxe]

Est ce que la perte de l'héritage multiple ne va pas poser problème ?

[OuftiBoy]

Est ce que la perte de l'héritage multiple ne va pas poser problème ?

L'héritage multiple, ce n'est pas forcément nécessaire, ni forcément une bonne pratique. Il faut parler en terme d'interface, et toujours préférer la composition plutôt que l'héritage lorsque c'est possible.

BàT et Peace & Love.

[archqt]

Je ne vois pas l'intérêt si la syntaxe ressemble à Rust, autant prendre Rust qui vise aussi la performance.

[Pyramidev]

Je ne vois pas l'intérêt si la syntaxe ressemble à Rust, autant prendre Rust qui vise aussi la performance.

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

[yahiko]

Plutôt sceptique après un premier survol de l'article, un nième langage de plus, je commence à être convaincu, ou en tout cas davantage ouverts aux arguments avancés par l'équipe de ce projet Carbon.

Si cela peut aider à migrer les grosses bases de code écrites en C++ vers une syntaxe plus lisible et proche des nouveaux langages tout en garantissant les performances et l'interopérabilité bi-directionnelle avec le C++, ça peut être une solution intéressante.

Après, il est dommage que la syntaxe de Carbon est tout de même bien différente du C++ et n'est pas un sur-ensemble de ce dernier comme peut l'être TypeScript envers JavaScript, exemple qui est cité mais un peu abusivement je trouve.

Pourquoi pas en tout cas. Attendons de voir.

[Astraya]

Je suis d'accord avec le constat sur l'état du C++. Les décisions prises sont discutables sur de nombreux points. Un super article ici qui compare le move C++ et Rust et pourquoi C++ n'est pas fait pour ça!
Jason Turner a fait une vidéo intéressante sur le sujet de l'ABI C++ et qu'il fallait la casser pour sauver le C++.

C'est très intéressant et je suis entièrement d'accord avec ça.
Maintenant faire un nouveau langage en disant uniquement que c'est fait pour être brancher avec le C++ je ne vois pas l'intérêt... Pour avoir un gestionnaire de paquets? une nouvelle syntaxe?
C'est bien dans l'idée mais dans les faits, il existe déjà Conan, certes c'est pas terrible... Mais est-ce que un gestionnaire de paquets justifie à lui seul un nouveau langage? Non je ne pense pas.

De plus, une fois que Carbon est branché au C++. Qui va maintenir la partie C++ et la partie Carbon? Un mouton à 5 pattes qui connait les 2? Ou embaucher 2 programmeurs et doubler les couts de maintenance? Migrer dans ce cas?
Si la solution est une migration petit à petit... Rust peut le faire, brique par brique, réécrire, fournir une interface C et C++ peut l'utiliser.

D'un point de vue financier, ressource humaine et sur le long terme je ne vois aucun intérêt à ce langage comparé à l'existant.

[raphchar]

Bof.
Première remarque, je n'aime pas la syntaxe

Code :

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

var nom : type

. Mais bon passons.
Je n'ai pas envie de changer pour carbone parce que j'aime le c++. On n'est pas obligé de connaitre tout le c++ pour commencer à l'utiliser.
J'aime le fait d'avoir un fichier header pour référencer les classes/fonctions de manière compacte.
J'aime le fait d'avoir le contrôle en c++. Je peux créer ma structure de donnée qui utilise des pointeurs nus et est efficace pour mes besoins. Et je peux utiliser des pointeurs intelligents quand je ne veux pas me casser la tête.

Mais ouais, le c++ n'est pas sûr pour le novice. On peut faire n'importe quoi avec les pointeurs ou autre. Alors oui, on peut créer un langage pour virer tout potentiel problème de sécurité. Mais on va perdre en performance. Et c'est ainsi qu'on se retrouve avec des programmes qui consomment beaucoup trop pour ce qu'ils font.

Vous voulez améliorer le c++, j'ai des pistes sans créer un nouveau langage :
Améliorer la compilation des templates.
Changez l'ABI si ça vous chante.

La stl ne fait pas partie du langage, mais l'enrichir est une bonne chose

[Astraya]

J'aime le fait d'avoir un fichier header pour référencer les classes/fonctions de manière compacte.

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?

J'aime le fait d'avoir le contrôle en c++. Je peux créer ma structure de donnée qui utilise des pointeurs nus et est efficace pour mes besoins. Et je peux utiliser des pointeurs intelligents quand je ne veux pas me casser la tête.

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

Mais ouais, le c++ n'est pas sûr pour le novice. On peut faire n'importe quoi avec les pointeurs ou autre.

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

Alors oui, on peut créer un langage pour virer tout potentiel problème de sécurité. Mais on va perdre en performance. Et c'est ainsi qu'on se retrouve avec des programmes qui consomment beaucoup trop pour ce qu'ils font.

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.

Vous voulez améliorer le c++, j'ai des pistes sans créer un nouveau langage :
Améliorer la compilation des templates.
Changez l'ABI si ça vous chante.

Je t'invite à leur proposer tes solutions = > https://isocpp.org/std/meetings-and-...s-and-mailings

La stl ne fait pas partie du langage, mais l'enrichir est une bonne chose

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.

[raphchar]

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?

C'est vrai pour les templates, mais une déclaration n'est pas compilée. Donc je l'accorde, il faudrait améliorer la compilation des templates, mais sans template, un header ne devrait pas être compilé.
Je ne vois pas en quoi les collisions de noms seraient spécifiques au c++.

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

Je vais commencer par clarifier un point : quand je parle de structure de donnée, je parle d'un objet bien défini, qui n'a pas vocation à être modifié (Un code contient à priori très peu de structures de données). Donc, en théorie, si une structure de donnée est bien faite, elle devrait être auto-suffisante, et la cuisine interne n'est pas le problème de l'utilisateur, seule l'interface compte. Maintenant, si le travail est bien fait, un document explique le fonctionnement de la structure parce qu'il n'est pas forcément trivial. Oui, il va falloir se plonger dans la tête de l'ancien programmeur en lisant la doc, parce qu'il s'est cassé la tête à faire une structure qui fonctionne bien et qui est efficace. Je ne vois rien d'égoïste là-dedans. (À ne pas confondre avec, les variables n'ont pas des noms explicites, pas de documentation)

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

Oui, mais ça rejoint mon point précédent, une structure de donnée est auto-suffisante, donc pour le reste qui est susceptible d'être modifié fréquemment, je suis d'accord qu'on va utiliser des précautions.

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

D'accord, c'est pour cela qu'on n'accepte pas n'importe qui sur un projet C++. C++ n'est pas fait pour faire du prototypage et requiert une réflexion en amont. C'est pour cela qu'il y a d'autres langages aussi.
Je n'ai fait qu'expliquer pourquoi, moi, j'aime le c++. Je n'attends pas des autres qu'ils adorent le c++.

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.

Okay, je ne connais pas Rust.

Je t'invite à leur proposer tes solutions = > https://isocpp.org/std/meetings-and-participation/papers-and-mailings

Je suis sûr que ces personnes sont au courant de ces problèmes, et ont sans doute bien plus de compétences en compilation pour trouver des solutions.

[Fagus]

Je ne vois pas en quoi les collisions de noms seraient spécifiques au c++.

Je pratique plus le c++, mais de ce que je sais, il "suffit" d'utiliser des namespaces dans chaque source pour éviter le problème. Les choses deviennent plus compliquées si on inclue des sources ou des binaires qui ne l'ont pas fait...
En python le problème n'existe pas avec le système des modules. Chaque module (ou fichier) a son propre espace de nommage par défaut, et on peut changer ce nom à l'importation s'il ne nous plait pas.
Je suppose que ce problème a de même été résolu dans les divers langages modernes.

Code Python :

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

1
2
import tkinter.messagebox as msg # importation du module externe binaire dans un espace arbitraire "msg" par flemme d'écrire plus de 3 caractères
msg.showinfo("coucou","le monde") #appel de la méthode externe par la syntaxe objet

[Dutiona]

La stl ne fait pas partie du langage, mais l'enrichir est une bonne chose

Sisi, la STL figure dans la norme ISO du langage, son API et les contrats avec dès fois des contraintes d'implémentation. Tout est publié dans le même fichier de norme : core langage + STL.

[23JFK]

C'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.

[lsbkf]

"Les pointeurs sont pris en charge mais pas l'arithmétique des pointeurs"

Non mais avec ça et le changement de syntaxe c'est un autre langage là, les références au C++ c'est juste du pipeau marketing ?

[dourouc05]

"Les pointeurs sont pris en charge mais pas l'arithmétique des pointeurs"

Non mais avec ça et le changement de syntaxe c'est un autre langage là, les références au C++ c'est juste du pipeau marketing ?

L'idée est plutôt de retirer de C++ des éléments obsolètes de C qui mènent à des problèmes de sécurité, tout en ayant à sa disposition des constructions équivalentes mais plus sûres. Ainsi, avec Carbon, il n'est normalement plus possible d'avoir un pointeur qui ne pointe sur rien : si on veut cette possibilité de ne pointer sur rien, il faut le rendre explicite, via Optional(T*).

Pour l'arithmétique, est-ce quelque chose de véritablement plus utile que néfaste ? Les concepteurs de Carbon ont décidé que les problèmes de sécurité qui en découlaient étaient plus importants : l'utilité principale de l'arithmétique de pointeur, c'est de pointer vers un élément dans un tableau qui n'est pas le premier, d'où l'objet Slice (équivalent de std::span en C++20), qui est une bien meilleure solution (voir https://stackoverflow.com/a/45723820, par exemple) et pas plus chère en temps de calcul (après optimisation par le compilateur).

[Astraya]

L'idée est plutôt de retirer de C++ des éléments obsolètes de C qui mènent à des problèmes de sécurité, tout en ayant à sa disposition des constructions équivalentes mais plus sûres. Ainsi, avec Carbon, il n'est normalement plus possible d'avoir un pointeur qui ne pointe sur rien : si on veut cette possibilité de ne pointer sur rien, il faut le rendre explicite, via Optional(T*).

Pour l'arithmétique, est-ce quelque chose de véritablement plus utile que néfaste ? Les concepteurs de Carbon ont décidé que les problèmes de sécurité qui en découlaient étaient plus importants : l'utilité principale de l'arithmétique de pointeur, c'est de pointer vers un élément dans un tableau qui n'est pas le premier, d'où l'objet Slice (équivalent de std::span en C++20), qui est une bien meilleure solution (voir https://stackoverflow.com/a/45723820, par exemple) et pas plus chère en temps de calcul (après optimisation par le compilateur).

Sur ce point justement je suis toujours étonné que le std::span soit un ensemble pointeur + taille plutôt que pointeur + pointeur de fin en interne.
Cela veux dire que à chaque fois que l'on veut faire une boucle, il faut calculer le pointeur de fin. C'est le principe même des itérateurs et des ranges de pouvoir faire des boucles while(ptr < ptr_end). Je trouve ce choix en contradiction avec le reste de la STL.

EDIT: En faite, ce n'est pas juste pour représentation du collection continue en mémoire... Au temps pour moi.

[lsbkf]

L'idée est plutôt de retirer de C++ des éléments obsolètes de C qui mènent à des problèmes de sécurité, tout en ayant à sa disposition des constructions équivalentes mais plus sûres. Ainsi, avec Carbon, il n'est normalement plus possible d'avoir un pointeur qui ne pointe sur rien : si on veut cette possibilité de ne pointer sur rien, il faut le rendre explicite, via Optional(T*).

Pour l'arithmétique, est-ce quelque chose de véritablement plus utile que néfaste ? Les concepteurs de Carbon ont décidé que les problèmes de sécurité qui en découlaient étaient plus importants : l'utilité principale de l'arithmétique de pointeur, c'est de pointer vers un élément dans un tableau qui n'est pas le premier, d'où l'objet Slice (équivalent de std::span en C++20), qui est une bien meilleure solution (voir https://stackoverflow.com/a/45723820, par exemple) et pas plus chère en temps de calcul (après optimisation par le compilateur).

Je comprend les arguments qui poussent à créer un nouveau langage, mais ce qui me chiffonne dans l'affaire c'est qu'on parle de successeur à C++ et pas de "nouveau langage" qui s'en inspire au même titre que Rust ou Go. Tu peux argumenter comme tu veux si c'est mieux ou pas, c'est pas la question, la syntaxe est différente, les idiomes sont différents, ce n'est pas un candidat de remplacement du C++ et je maintiens que c'est une lubie marketing pour tenter de maintenir l'illusion que ce n'est pas juste un énième langage de programmation.