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 !

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 , par Patrick Ruiz

27PARTAGES

17  0 
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 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

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

Avatar de Pierre Louis Chevalier
Expert éminent sénior https://www.developpez.com
Le 20/07/2022 à 15:42
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 ?
6  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 27/07/2022 à 11:35
Citation Envoyé par Madmac Voir le message
Moi ce qui me dérange le plus est qu'ils me semble pas avoir une idée très clair de la direction de l'évolution. Plutôt que de tenter de modifier le language, il devrait développer un surchose pour rendre le langage plus accessible et moins sujet aux fuites. J'ai jamais compris la raison pour laquelle, personne n'a développer une librairie pour faire du pure objet en C++..
Depuis 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 lis
6  0 
Avatar de AoCannaille
Membre expert https://www.developpez.com
Le 27/07/2022 à 11:55
Citation Envoyé par grunk Voir le message
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 lis
ça me fait plaisir de lire ça, je suis exactement dans le même cas ^^' ça soulage un peu mon syndrome de l'imposteur
6  0 
Avatar de Astraya
Membre chevronné https://www.developpez.com
Le 21/07/2022 à 11:36
Citation Envoyé par raphchar Voir le message
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?

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

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

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

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

Citation Envoyé par raphchar Voir le message
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.
5  0 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 20/07/2022 à 23:37
Citation Envoyé par archqt Voir le message
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.
3  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 21/07/2022 à 8:33
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.
2  0 
Avatar de 23JFK
Membre expert https://www.developpez.com
Le 21/07/2022 à 14:40
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.
3  1 
Avatar de walfrat
Membre chevronné https://www.developpez.com
Le 25/07/2022 à 8:56
Ma pensée sur le sujet :

https://xkcd.com/927/
4  2 
Avatar de smarties
Membre chevronné https://www.developpez.com
Le 26/07/2022 à 12:43
Citation Envoyé par progz_du_dimanche Voir le message
Kotlin à vraiement remplacer Java ?
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 langage
2  0 
Avatar de smarties
Membre chevronné https://www.developpez.com
Le 26/07/2022 à 22:04
Citation Envoyé par jpouly Voir le message
Je ne comprend pas cette obstination à vouloir remplacer le C/C++ par un autre langage.
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 python
2  0