Au-delà de C++ : la promesse de Rust, Carbon et Cppfront

À certains égards, C et C++ dirigent le monde. Vous ne le sauriez jamais de tout le battage médiatique autour d’autres langages de programmation, tels que Python et Go, mais la grande majorité des applications de bureau et des systèmes d’exploitation hautes performances du marché de masse sont écrits en C++, et la grande majorité des applications embarquées sont écrit en C. Nous ne parlons pas d’applications pour smartphone ou d’applications Web : celles-ci ont des langages spéciaux, tels que Java et Kotlin pour Android et Objective-C et Swift pour iOS. Ils n’utilisent C/C++ que pour les boucles internes qui ont un besoin criant de vitesse et pour les bibliothèques partagées entre les systèmes d’exploitation.

C et C++ ont dominé les systèmes de programmation pendant si longtemps qu’il est difficile d’imaginer qu’ils soient déplacés. Pourtant, de nombreux experts disent qu’il est temps pour eux de partir et pour les programmeurs d’adopter de meilleures alternatives. Microsoft Azure CTO Mark Russinovich a récemment fait des vagues lorsqu’il a suggéré que les développeurs C et C++ devraient plutôt passer à Rust. “L’industrie devrait déclarer ces langues comme obsolètes”, Russinovich a tweeté.

De nombreux développeurs explorent Rust comme une alternative prête pour la production à C/C++, et il existe d’autres options à l’horizon. Dans cet article, nous examinerons les mérites et l’état de préparation des trois alternatives de langage C/C++ les plus citées : Rust, Carbon et cppfront. Tout d’abord, jetons un coup d’œil à l’histoire et à certains des points faibles de C/C++.

Problèmes C++

C++ a été développé par Bjarne Stroustrup aux Bell Laboratories à partir de 1979. Étant donné que C++ est une tentative d’ajouter des fonctionnalités orientées objet (ainsi que d’autres améliorations) à C, Stroustrup l’a initialement appelé “C avec des objets.” Stroustrup a renommé le langage en C++ en 1983 , et le langage a été mis à disposition en dehors des laboratoires Bell en 1985. Le premier compilateur C++ commercial, Cfront, a été publié à cette époque. Cfront a traduit C++ en C, qui pouvait ensuite être compilé et lié. Les compilateurs C++ ultérieurs ont produit des fichiers de code objet pour alimenter directement dans un linker.

Depuis lors, l’effort de normalisation C++ a été continu, à commencer par la publication de Stroustrup’s 1985 Le langage de programmation C++ et années 1990 BRASLa UNC++ noté Rréférence Mannuel. Celles-ci ont été suivies par toute une série de normes ANSI/ISO C++, en 1998, 2003, 2011, 2014, 2017, 2020, la prochaine étant prévue pour 2023. Il existe également des spécifications techniques intermédiaires pour définir des compléments.

Chaque révision de la norme C++ a ajouté des fonctionnalités, mais aucune n’a rendu le langage plus facile à apprendre ou plus rapide à compiler. Quiconque a construit un programme C++ de plusieurs millions de lignes comprend le fardeau d’attendre les compilations. Rob Pike cite le temps de compilation de C++ comme sa motivation pour développer Go : « Vers septembre 2007, je faisais un travail mineur mais central sur un énorme programme Google C++, avec lequel vous avez tous interagi, et mes compilations prenaient environ 45 minutes. … sur notre énorme cluster de compilation distribué. La solution de Pike était de développer un nouveau langage, Go, qui a finalement attiré beaucoup d’adoption, mais pas de la part des programmeurs C++.

J’ai personnellement travaillé sur un programme C++ qui ne comptait « que » 2 millions de lignes de code. À l’époque, il fallait plusieurs heures pour effectuer une compilation et une liaison complètes sur un seul ordinateur à huit cœurs, et environ 10 minutes pour charger dans Visual Studio et résoudre tous les symboles. J’ai contourné le problème de compilation avec l’automatisation : j’avais un script qui extrayait une nouvelle copie du code du référentiel partagé dans l’obscurité de la nuit, puis compilait le tout à partir de zéro. J’ai contourné le problème de chargement lent en faisant bouillir de l’eau, en préparant du thé et en le buvant avec des coéquipiers tous les matins après avoir ouvert Visual Studio. (Visual Studio a depuis résolu le problème de chargement lent, me dit-on.)

Pour les développeurs à la recherche d’alternatives à C++, Rust, Carbon et Cppfront sont tous de bons candidats. Des trois, seul Rust est actuellement prêt pour la production.

Rust comme alternative C++

La page d’accueil de Rust-lang déclare trois raisons principales de choisir Rust : performances, fiabilité et productivité. Rust a été conçu pour être rapide, sûr et facile à utiliser, avec l’objectif primordial de permettre à chacun de créer des logiciels fiables et efficaces.

En ce qui concerne les performances, Rust est à la fois rapide et économe en mémoire : sans runtime ni ramasse-miettes, il peut alimenter des services critiques en termes de performances, s’exécuter sur des appareils intégrés et s’intégrer facilement à d’autres langages. Du côté de la fiabilité, le système de type riche de Rust et la propriété du modèle garantissent la sécurité de la mémoire et la sécurité des threads, que les développeurs peuvent utiliser pour éliminer de nombreuses classes de bogues au moment de la compilation. Pour la productivité, Rust propose une excellente documentation, un compilateur convivial avec des messages d’erreur utiles et des outils de premier ordre – un gestionnaire de packages intégré et un outil de construction, une prise en charge intelligente de plusieurs éditeurs avec auto-complétion et inspections de type, un formatteur automatique, etc. . .

Les cas d’utilisation de Rust pris en charge incluent la création d’outils de ligne de commande, la compilation en WebAssembly (un moyen de suralimenter votre JavaScript), la création de services réseau et la création de logiciels pour les systèmes embarqués à faibles ressources. L’adoption de Rust en production prend de l’ampleur, notamment dans Firefox, Dropbox, Cloudflare, NPM, Yelp et InfluxDB IOx. InfluxDB utilise également DataFusion, un moteur de requête SQL natif Rust pour Apache Arrow.

Rust a la réputation d’être difficile à apprendre, bien que probablement pas aussi difficile que C++. Un gros argument de vente est qu’il est sûr par défaut, ce qui signifie que dans Safe Rust, vous n’avez pas à vous soucier de la sécurité du type ou de la sécurité de la mémoire. Vous pouvez également activer les pratiques de codage non sécurisées si vous en avez besoin, en utilisant le unsafe attribut. Parfois, vous devez déréférencer des pointeurs bruts, appeler des fonctions C, muter des statiques ou accéder à des champs d’un union. Tous ces éléments sont dangereux, vous devez donc les marquer comme dangereux afin de les utiliser dans un programme de rouille. (Vous devriez également les vérifier manuellement, car vous ne pouvez pas compter sur le compilateur pour corriger les erreurs que vous faites dans un code non sécurisé.)

Carbon comme alternative au C++

Le nouveau langage expérimental Carbon, annoncé lors de la réunion du CPP North le 19 juillet 2022, se veut un éventuel langage successeur du C++. Bien que Carbon soit loin d’être prêt à l’emploi, il dispose d’un référentiel source, d’un Discord, d’un modèle de gouvernance et d’un interpréteur que vous pouvez utiliser en ligne ou installer sur macOS ou Linux. Il lui manque actuellement un compilateur, une chaîne d’outils ou même une conception complète du langage 0.1.

Les objectifs du projet de langage Carbon sont les suivants : logiciel déclaré critique pour les performances ; évolution du logiciel et du langage ; un code facile à lire, à comprendre et à écrire ; mécanismes pratiques de sécurité et de test; développement rapide et évolutif ; plates-formes de système d’exploitation, architectures matérielles et environnements modernes ; et l’interopérabilité avec le code C++ existant et la migration à partir de celui-ci.

Le projet a également des non-buts. Développer une interface binaire d’application (ABI) stable pour l’ensemble du langage et de la bibliothèque et assurer une compatibilité ascendante ou descendante parfaite ne sont pas des objectifs pour Carbon.

Selon Kate Gregory, l’un des chefs de projet avec Richard Smith (du comité des normes ISO C++) et Chandler Carruth (un ingénieur logiciel principal chez Google), l’abandon de la rétrocompatibilité libère le projet pour apporter des changements positifs qui ne le feraient pas. être autorisé dans le langage C++, avec l’avantage majeur de réduire la dette technique. Au lieu de la rétrocompatibilité, Carbon proposera des mises à niveau de version basées sur des outils et une migration C++. Les mises à niveau et la migration basées sur des outils sonnent bien mieux que les longues et atroces mises à niveau manuelles que les développeurs C++ doivent effectuer à chaque modification majeure du langage.

Il y a beaucoup à assimiler dans l’exemple de code ci-dessous, qui provient du référentiel Carbon. J’ai ajouté des commentaires pour vous aider.


//packages are namespaces as well as units of distribution
//Nothing in Carbon goes into the global namespace, unlike C++
//There is only one api file per package. Other files are impl
 
package Sorting api;
 
//fn declares a function
//[T means the parameter type T is generic
//Note the change from <...> to [...] for generics
//:! Means the passed type is checked at compile time
//Comparable and Movable are attributes of the generic T
//Slice hasn’t been fully specified, but think Go slices
//-> is a return value type
//i64 is a 64-bit signed integer type
//var declares a mutable variable
//& is the address-of operator, as in C/C++
 
fn Partition[T:! Comparable & Movable](s: Slice(T))
     -> i64 {
  var i: i64 = -1;
 
  for (e: T in s) {
    if (e <= s.Last()) {
      ++i;
      Swap(&s[i], &e);
    }
  }
  return i;
}
 
//let declares an immutable constant r-value
 
fn QuickSort[T:! Comparable & Movable](s: Slice(T)) {
  if (s.Size() <= 1) {
    return;
  }
  let p: i64 = Partition(s);
  QuickSort(s[:p - 1]);
  QuickSort(s[p + 1:]);
}

Pour plus d'exemples de code carbone, consultez le document de conception du langage et les données de test de l'explorateur carbone.

Que pense Stroustrup de tout cela ? Pas grand-chose, à ce stade. "Le carbone est tellement nouveau et sous-spécifié que je ne peux pas vraiment faire de commentaires techniques significatifs."

Cppfront comme alternative C++

Herb Sutter a présidé pendant une décennie le comité des normes ISO C++. Il est architecte logiciel chez Microsoft, où il a dirigé la conception des extensions de langage C++/CLI, C++/CX, C++ AMP et d'autres technologies. Avec Cpp2 et cppfront, Sutter déclare que son "objectif est d'explorer s'il existe un moyen de faire évoluer C++ lui-même pour devenir 10 fois plus simple, plus sûr et plus facile à utiliser". Il explique:

Si nous avions une syntaxe C++ alternative, cela nous donnerait une "bulle de nouveau code qui n'existe pas aujourd'hui" où nous pourrions apporter des améliorations arbitraires (par exemple, modifier les valeurs par défaut, supprimer les parties non sûres, rendre le langage sans contexte et commander- indépendants, et appliquent généralement 30 ans d'apprentissages), sans contraintes de rétrocompatibilité des sources.

Sutter a travaillé sur la conception de la "syntaxe 2" (Cpp2) en 2015 et 2016, et depuis 2021, il écrit le compilateur Cppfront pour prototyper toutes les propositions d'évolution ISO C++ et les conférences qu'il a données depuis 2015. Le prototype inclut désormais la syntaxe alternative 2 pour C++ qui permet leurs conceptions complètes, y compris les modifications autrement cassantes.

La suite de régression Cppfront de Sutter comprend quelques dizaines d'exemples de code mixte C++ et Cpp2, et quelques autres exemples de code Cpp2 pur. Comme avec le Stroustrup Cfront original, le Cppfront de Sutter est un pont pour permettre le développement de Cpp2 et expérimenter la nouvelle syntaxe jusqu'à ce qu'il soit possible de compiler Cpp2 directement en code objet.

Rouille, Carbone ou Cppfront ?

Rust, Carbon et Cppfront sont tous prometteurs en tant qu'alternatives C++. Pour Carbon, nous envisageons probablement un cycle de développement de cinq ans jusqu'à ce qu'il soit mis en production. Cppfront pourrait être disponible pour la production plus tôt, et Rust est déjà là.

Les trois langages sont (ou seront) interopérables avec C++ au niveau binaire. Cela implique que les trois langages pourraient vous permettre d'apporter des améliorations progressives aux programmes C++ existants en ajoutant de nouveaux modules non C++.

Dans le cas de Cppfront, le mélange de code source C++ et Cpp2 est déjà implémenté, au moins partiellement, et est inclus dans la suite de régression de Sutter. L'outillage de Carbon inclura la migration automatique du code source C++. Une question ouverte est de savoir si cela migrera 100% de votre code C++, ou vous obligera à réécrire manuellement un pourcentage de votre code qui autrement fonctionnerait mal, enfreindrait les normes carbone ou vous obligerait à le marquer comme dangereux si vous voulez le laisser seul.

Rust démontre déjà la sécurité de la mémoire. Vous ne pouvez littéralement pas compiler du code Rust qui violerait la sécurité de la mémoire à moins que vous ne le marquiez comme dangereux. Carbon et Cppfront mettront certainement en place des mécanismes de sécurité mémoire. Nous ne savons pas encore exactement ce qu'ils seront.

Rust n'est pas très facile à apprendre, même si vous connaissez le C++, bien qu'on me dise qu'apprendre Rust est en fait un peu plus facile que d'apprendre le C++ si vous partez de zéro. Néanmoins, les programmeurs C++ et Go parviennent généralement à récupérer Rust en une semaine ou deux.

Ce que nous avons vu de Cpp2 de Herb Sutter montre clairement que les programmeurs C++ trouveront une transition relativement facile, même si le C++ généré par Cppfront est actuellement assez moche. L'outil de conversion C++ de Carbon devrait permettre un outil d'édition côte à côte, un peu comme le support IntelliJ pour apprendre Kotlin en convertissant le code Java existant.

En fin de compte, comme Stroustrup l'a laissé entendre dans ses commentaires sur Carbon, nous devrons attendre et voir comment chaque langue et ses outils se déroulent.

Copyright © 2022 IDG Communications, Inc. Tous droits réservés.

Leave a Comment

Your email address will not be published. Required fields are marked *