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 !

Les innovations de C++26 : comment les dernières améliorations vont transformer le développement en C++
Dans un contexte où plusieurs entités recommandent de remplacer C++ par des alternatives

Le , par Stéphane le calme

113PARTAGES

5  0 
Le langage de programmation C++ continue d'évoluer avec l'introduction de nouvelles fonctionnalités et améliorations. La version C++26, bien que toujours en cours de développement, apporte déjà plusieurs nouveautés : spécifier une raison pour la suppression d'une fonction, variables de remplacement sans nom, déclaration d'une liaison structurée en tant que condition. Mais certains encouragent plutôt le passage à Rust ou Carbon, pourquoi ?

Spécifier une raison pour la suppression d'une fonction

Depuis le C++11, il est possible de déclarer une fonction comme supprimée, afin que le compilateur empêche son utilisation. Cela peut être utilisé pour empêcher l'utilisation de fonctions membres spéciales d'une classe, mais aussi pour supprimer toute autre fonction.

Introduits en C++11, = default et = delete ont rejoint = 0 en tant que spécification alternative possible pour le corps d'une fonction, au lieu d'un corps d'instructions ordinaire entouré d'accolades. La motivation initiale de la déclaration de fonction supprimée via = delete est de remplacer (et d'annuler) la pratique courante de l'ère C++98/03 consistant à déclarer les fonctions membres spéciales comme privées et à ne pas les définir afin de désactiver leur génération automatique. Cependant, l'ajout de = delete a acquis un pouvoir encore plus grand, car il peut être utilisé pour n'importe quelle fonction, et pas seulement pour les membres spéciaux.

Aujourd'hui, dix ans après l'introduction des fonctions supprimées, nous pouvons conclure en toute confiance que = delete est devenu l'une des fonctionnalités clés de C++11 qui a grandement amélioré l'expérience des utilisateurs en cas d'erreurs dans l'utilisation des fonctions de la bibliothèque et a été une réussite de la révolution du « C++ moderne ».

Il y a plusieurs raisons pour lesquelles les fonctions supprimées ont été préféré aux fonctions traditionnelles privées mais non définies, notamment une meilleure sémantique (friend et les autres membres sont toujours inaccessibles, ce qui transforme une erreur de l'éditeur de liens en une erreur à la compilation), de meilleurs diagnostics (au lieu d'erreurs cryptiques « fonction inaccessible », l'utilisateur sait directement que la fonction est supprimée) et une plus grande puissance (pas seulement pour les SMF).

Au lieu d'une erreur déjà plus conviviale mais toujours un peu énigmatique « calling deleted function », les éditeurs veulent permettre directement aux auteurs de bibliothèques de présenter un message supplémentaire facultatif qui devrait être inclus dans le message d'erreur, de sorte que l'utilisateur connaisse le raisonnement exact de la raison pour laquelle la fonction est supprimée, et dans certains cas, vers quel remplacement l'utilisateur devrait se diriger à la place.

Une fonction peut être supprimée comme suit (exemple tiré du document de proposition) :

Code C++ : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
class NonCopyable 
{ 
public: 
    // ... 
    NonCopyable() = default; 
    // les membres de la copie 
    NonCopyable(const NonCopyable&) = delete; 
    NonCopyable& operator=(const NonCopyable&) = delete; 
  
};

En C++26, vous pouvez spécifier la raison pour laquelle cette fonction est supprimée :

Code C++ : Sélectionner tout
1
2
3
4
5
6
class NonCopyable { 
public: 
    NonCopyable() = default; 
    NonCopyable(const NonCopyable&) = delete("Cette classe gère des ressources uniques, la copie n'est pas supportée; utilisez le déplacement à la place."); 
    NonCopyable& operator=(const NonCopyable&) = delete("Cette classe gère des ressources uniques, la copie n'est pas supportée; utilisez le déplacement à la place."); 
};

Variables de remplacement sans nom

Il existe des cas où une variable doit être déclarée sans que son nom soit utilisé, comme dans les liaisons de structure ou les verrous (lock_guard). C++26 introduit la possibilité d’utiliser un seul trait de soulignement (_) pour définir une variable sans nom.

Par exemple, dans l'exemple suivant, unused est une variable qui n'est pas utilisée :

Code C++ : Sélectionner tout
[[maybe_unused]] auto [data, unused] = get_data();

En C++26, la variable unused peut être nommée _ (simple trait de soulignement) :

Code C++ : Sélectionner tout
auto [data, _] = get_data();

Lorsque l'identificateur de soulignement unique est utilisé pour la déclaration d'une variable, d'une variable membre de classe non statique, d'une capture lambda ou d'une liaison de structure, l'attribut [[maybe_unused]] est implicitement ajouté, il n'est donc pas nécessaire de l'utiliser explicitement.

Une déclaration portant le nom _ est dite indépendante du nom si elle déclare :
  • une variable avec une durée de stockage automatique
  • une liaison de structure, mais pas dans un espace de noms
  • une variable introduite par une capture init
  • un membre de données non statique

Le compilateur n'émet pas d'avertissement quant à l'utilisation ou non d'une déclaration indépendante du nom. De plus, plusieurs déclarations indépendantes du nom peuvent être utilisées dans la même portée (qui n'est pas une portée d'espace de noms) :

Code C++ : Sélectionner tout
1
2
3
4
5
6
7
int main() 
{ 
  int _; 
  _ = 0;         // OK 
  std::string _; // OK, parce que _ est une déclaration indépendante du nom 
  _ = "0";       // Erreur : référence ambiguë au caractère générique « _ », qui est défini plusieurs fois. 
}

En revanche, ce qui suit n'est pas possible :

Code C++ : Sélectionner tout
1
2
3
4
5
6
int main() 
{ 
  int _; 
  _ = 0;                // OK 
  static std::string _; // Erreur : les variables statiques ne sont pas indépendantes du nom 
}

L'opération suivante n'est pas non plus possible, car les déclarations se trouvent dans un espace de noms :

Code C++ : Sélectionner tout
1
2
3
4
5
6
namespace n 
{ 
  int f() {return 42;} 
  auto _ = f(); // OK 
  auto _ = f(); // Erreur : redéfinition de _ 
}

Déclaration d'une liaison structurée en tant que condition

Une liaison de structure définit un ensemble de variables liées à des sous-objets ou à des éléments de leur initialisateur.

Code C++ : Sélectionner tout
auto [position, length] = get_next_token(text, offset);

Une liaison de structure peut apparaître dans une déclaration for-range, comme dans l'exemple suivant :

Code C++ : Sélectionner tout
1
2
3
4
for (auto [position, length] : tokenize(text, offset)) 
{ 
  std::println("pos {}, len {}", position, length); 
}

En revanche, les variables peuvent apparaître dans la condition d'une instruction if, while ou for :

Code C++ : Sélectionner tout
1
2
3
4
if (auto it = std::find_if(begin(arr), end(arr), is_even); it != std::end(arr)) 
{ 
  std::println("{} est le premier nombre pair", *it); 
}

Cependant, les liaisons de structure ne peuvent pas être déclarées dans la condition d'une instruction if, while ou for. Cela change en C++26, ce qui rend la chose possible :

Code C++ : Sélectionner tout
1
2
3
4
if(auto [position, length] = get_next_token(text, offset); position >= 0) 
{ 
  std::println("pos {}, len {}", position, length); 
}

Un cas intéressant et très utile est présenté dans le document de proposition (P0963). Considérons l'exemple C++26 suivant pour l'utilisation de std::to_chars :

Code C++ : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
if (auto result = std::to_chars(p, last, 42)) 
{ 
​​​​    auto [ptr, _] = result; 
​​​​    // ok pour continuer 
​​​​}  
else  
{ 
​​​​    auto [ptr, ec] = result; 
​​​​    // gestion des erreurs 
​​​​}

Lorsque la fonction réussit, seul le membre ptr de std::to_chars_result nous intéresse, car il contient un pointeur sur le pointeur de fin de ligne des caractères écrits. Si la fonction échoue, nous devons également examiner le membre ec (du type std::errc) qui représente un code d'erreur.

Ce code peut être simplifié avec des liaisons de structure, en C++26, comme suit :

Code C++ : Sélectionner tout
1
2
3
4
5
6
7
8
​​​​if (auto [ptr, ec] = std::to_chars(p, last, 42)) 
{ 
​​​​    // ok pour continuer 
​​​​}  
else  
{ 
​​​​    // gestion des erreurs 
​​​​}

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

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.

Les développeurs de Carbon expliquent que certes, le C++ est le langage dominant pour les logiciels à performances critiques, mais son héritage et sa dette technique signifient que son amélioration incrémentale est une tâche très ardue. 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. Selon l'équipe Carbon, les concepteurs du C++ ont ajouté plutôt que remplacé des fonctionnalités du langage au fil du temps...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.

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

Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 12/09/2024 à 18:34
Bjarne Stroustup, le créateur original de C++, a dénoncé lui-même la dérive qu'a prit le comité qui dirigent les évolutions de C++.
Ils leurs reproche d'ajouter des micro-fonctionnalités, qui ne sont utilent qu'à 0,01% des projets ou des développeurs, et qui pourrait être déjà fait avec l'existant. En fait, le C++ est maintenant piloté par un comité de gens certes très compétants, mais qui font de la masturbation intellectuel pour pondre des concepts qui sont très éloignés de ce dont ont besoin les développeurs dans le monde réel.

C'est malheureux, car voilà un langage qui avaient du succès, qui répondait à un besoin, mais qui va crouler sous sont propre poids.

BàV et Peace & Love.
7  0 
Avatar de OuftiBoy
Membre éprouvé https://www.developpez.com
Le 15/09/2024 à 10:42


Citation Envoyé par Brunoo  Voir le message
Pour remplacer le C++ n'y a-t-il pas déjà le langage D ? C'est en tout cas son ambition affichée.

D aurait pu être ce "nouveau C++", mais il n'a pas décollé, parce qu'au moment où il est sorti:

  • il n'était pas rétrocompatible avec le C
  • C++ n'était pas encore devenu le monstre qu'il est aujourd'hui, et a prit naturellement la relève.
  • Grâce à sa compatibilité avec le C, il avait déjà tout un éco-système, et une communauté autours de lui.


Quitte a repenser le C++, ce serait judicieux d'éviter de créer un langage a la syntaxe moche.
Car, selon moi, ce qui a fait le succès des langages comme Java et C# c'est aussi la lisibilité de leurs syntaxes.

La syntaxe, c'est une affaire de goût, d'habitude, mais surtout de lisibilité. Je dis souvent qu'on lit plus souvent son code qu'on ne l'écrit. Java, possédait (et possède toujours) des atouts, mais:

  • Il est très verbeux, rendant le code "surchargé" et difficile à lire.
  • Il tourne via une "machine virtuelle", qui même si elle possèce un JIT maintenant, ce n'était pas le cas à ses débuts.
  • Et à cause du fait qu'il tourne en s'appuyant sur une "machine virtuelle", il ne pouvait et ne peut pas être comparé au C/C++ qui peuvent compiler du code natif, pour plusieurs architecture. Il y a toujours un compilateur 'C' pour chaque architecture, de la plus petite à la plus grande.
  • Puis Python est arrivé est s'est fortement implenté. On dit qu'il est lent (parce que lui aussi tourne sur une machine virtuelle), mais il sait très facilemment utiliser du code 'C', ce qui fait que tout traitent "lourd" est souvent exécuté à la vitesse du 'C'.


Pour C#, c'est un peu le "java" de microsoft. La puissance de microsoft est derrière ce langage, mais lui aussi tourne sur une "machine virtuelle", même s'il a maintenant aussi un JIT, il ne peut en rien être comparé (tout comme Java), question vitesse, à C/C++. Il a prit de l'importance et est très utilisé, car il y'a microsoft derrière, est ça "rassure" les entreprises quant à sa pérénité.

Le Go, je ne connais pas, donc j'évite de faire des commentaires sur une technologie qui m'est inconnue.

Et je ne parle même pas du fait que l'adoption d'un nouveau langage tien aussi au fait que chaque instruction soit non seulement documentée mais surtout accompagnée d'un exemple pratique et utile (codes snippets), afin de faciliter la mise en pratique.

Il n'y a pas que ça, il faut tout un écosystème autours d'un langage. De la doc, oui, mais aussi des librairies, des éditeurs, bref, toute une floppée d'outils.
Il faut aussi créer tout une communauté, qui perdure et sait acceuillir les développeurs qui se pencheront sur un langage.

Et un petit dernier pour la route Il n'y a pas langage qui soit adapté à toutes les situations. Il ne me viendrait pas à l'idée de faire une grosse application en 'C'. C'est plutôt le C++ qui serait utilisé dans ce cas. Dans le domaine de l'embarqué, le seul langage que tu es certains d'avoir, c'est le 'C'. Dans le domaine banquaire, c'est toujours du COBOL qui est utilisé. Certains ont bien tenté de ré-écrire les vielles application COBOL en java ou en C++, mais tout les essais ont échoués, car c'est très difficile de reconstruire un système qui fonctionne à l'identique.

Et il y a une grosse masse de code 'C' dans la nature, et on ne remplacera pas celui-ci du jour au lendemain.

Actuellement, quelques langages se démarquent des autres:

  • Python chez les "data scientist", et les "ingénieurs", car il est trés simple à écrire et à relire, et à tout ce qu'il faut pour les satisfaire question librairires (numPy par exemple) pour s'affranchir sa "relative" lenteur.
  • lua, est lui aussi un langage "dynamique" comme Python, et est simple à utiliser. Sa machine virtuelle est aussi plus rapide que celle de Python, car c'est une "register based VM", là ou Python/Javan reposent sur des "stack based VM".
  • C# pour ceux qui ne veulent être "rassuré" par le fait que Microsift soit derrière.
  • Le 'C' reste indispensable grâce à sa vitesse, son éco-système, et qu'il reste le plus rapide, car très proche de ma machine. Son désavantage, c'est que si on ne fait pas très attention, on peut vite introduire des vulnérabilités. Mais dans l'embarqué, c'est toujours 'LA' référence, et avec la base de code installée, il est encore là pour très longtemps.
  • C++, car (tout comme le C), il il peut produire du code natif et est de ce fait très utilisé. Et il a profité de la vague POO à ses début. Il est également très installé.
  • COBOL reste utilisé dans le domaine bancaire.


Et puis, il y'a maintenant le petit nouveau (enfin, a quand même 10 ans) Rust qui peut pratiquement égaler C/C++ niveau vitesse, mais qui est nettement plus sécurisé niveau gestion mémoire et évite pas mal d'erreurs qu'on peut faire en C/C++, car le langage (et son compilateur) fournira des erreurs et ne compilera pas un code dangereux.

C'est je pense le seul langage (qui produit du code machine) qui peut/pourra rivaliser avec le C/C++. Je suis en train de me pencher dessus, et pour un vieux développeur 'C' comme moi, sa "syntaxe" me déroute énormément (mais avec le temps, ça viendra), et il faut parfois se battre avec le compilateur pour qu'il accepte de compiler un code, car les différents verrous qu'il possèdent pour être "sécure" sont parfois "lourds" a digérer pour les vieux développeurs 'C', qui savent ce qu'il font. Mais on fait tous des erreurs, et si le langage permet d'en éviter, ça ne peut être d'une bonne chose.

[B]Rust[B] est déroutant, et il faut s'accrocher et persévérer, car oui, les concepts qu'il aborde sont traités différement que d'autres language, mais rend le code plus "sécure".

Mais, je le répête, il n'y a pas de langage meilleurs qu'un autres. Il faut choisir son outils par rapport à ses besoins. On utilise un marteau pour enfoncer un clou, et un tournevis pour viser une vise. L'inverse n'aurait pas de sens.

BàV et Peace & Love.
6  0 
Avatar de smarties
Expert confirmé https://www.developpez.com
Le 12/09/2024 à 11:07
Quels autres aspects du langage C++ aimeriez-vous voir améliorés dans les futures versions ?
Un gestionnaire de dépendances, je n'ai fais plus de C++ depuis 2006 mais j'ai parfois cherché à compiler certains programmes et c'est une galère à chaque fois car la bibliothèque manquante n'était pas clairement notée : il faut se baser sur le nom du fichier ou chercher dans le makefile et ça demande du temps à chaque fois.
5  0 
Avatar de d_d_v
Membre expérimenté https://www.developpez.com
Le 12/09/2024 à 11:03
il faudrait surtout "nettoyer" les fonctions existantes, peu utilisées/utilisables, mais ils ne peuvent s'empêcher de rajouter de nouvelles variantes de fonctions existantes. Je me demande qui les utilisent réellement. Par exemple, il existe maintenant 14 variantes de la fonction replace de std::basic_string !!
Et pourtant, on n'a toujours pas une fonction simple pour remplacer une ou plusieurs occurrences d'une sous-chaîne par une autre (case sensitive/insenstive) dans une chaîne. On n'a toujours pas accès non plus à des fonctions de trim. Pour chaque nouveau poste en entreprise, chaque projet utilise soit boost ou a sa propre librairie pour manipuler les string !
Pendant ce temps, le comité c++ invente des nouveaux concepts ou des nouvelles variantes de fonctions que je n'ai personnellement jamais croisées dans aucun projet. J'ai pourtant plus de 20 ans d'expérience !
4  0 
Avatar de Brunoo
Membre régulier https://www.developpez.com
Le 14/09/2024 à 21:18
Pour remplacer le C++ n'y a-t-il pas déjà le langage D ? C'est en tout cas son ambition affichée.

Quitte a repenser le C++, ce serait judicieux d'éviter de créer un langage a la syntaxe moche.
Car, selon moi, ce qui a fait le succès des langages comme Java et C# c'est aussi la lisibilité de leurs syntaxes.
Et je ne parle même pas du fait que l'adoption d'un nouveau langage tien aussi au fait que chaque instruction soit non seulement documentée mais surtout accompagnée d'un exemple pratique et utile (codes snippets), afin de faciliter la mise en pratique.
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 17/09/2024 à 4:49
Citation Envoyé par 23JFK Voir le message
Je vous concède que les évolutions incessantes et discutables du C++ sont pénibles à suivre/comprendre. Mais le C++ reste malgré tout 95% compatible C. A vrai dire, il reste permissif et vous permet d'organiser votre code sans vous obliger à avoir recours à toutes ces évolutions syntaxiques et ajouts du "modern C++". On peut très bien s'en sortir en ne l'utilisant que comme un C enrichi du concept de classes, et d'ailleurs, ça peut parfois être la seule manière d'obtenir un code plus rapide.
Le soucis c'est que le code compatible avec le C, c'est du code pas vraiment recommandé de nos jour en C++ par la plupart des gens qui enseignent le C++, et pourtant il peut toujours se mélanger avec du code dit moderne, que ça soit volontairement ou par inadvertance. De même si on veut que C++ produise du code vraiment sécurisé, cela demandera aussi de nouvelles fonctionnalités avec de nouveaux usages qui créeront de fait un nouveau dialecte.
C'est pour ça que parfois, partir sur un nouveau langage cohérent peut être plus intéressant que de trainer un héritage lourd, avec différents dialecte que certains trouveront des améliorations alors que d'autres les voient comme des régressions.

Citation Envoyé par 23JFK Voir le message
Le problème c'est que Google a mis le doigt dans le "Go Woke Go Broke" et que Rust, pour une raison qui m'échappe encore, est devenu "LE langage de programmation" de cette communauté, alors donc... Peut-on encore se fier ici à l'avis de Google ? (souvenez-vous du plantage magistral de leur IA wokisée Google_Gemini).
C'est fou cette propension a certains adeptes du C++ a ramener à la religion ou au Wokisme l'usage de Rust quand en face on parle de technique et de chiffres qui n'ont rien a voir. Le fait d'être black, gay, trans ou autre ne change pas la productivité, contrairement au langage que l'on utilise. Les utilisateurs de Rust restant d'ailleurs, comme pour presque tout ce qui touche a l'informatique, principalement des hommes blancs hétéro.
3  0 
Avatar de NotABread
Membre actif https://www.developpez.com
Le 18/09/2024 à 10:57
Je trouve l'initiative intéressant surtout si on peut garder l'héritage du C++ et une compatibilité avec le C.

Après, peut-on encore dire qu'il s'agit de C++ ? Cela ajoute une syntaxe et des notions ne faisant pas partie de C++. De plus, si par défaut toute fonction C++ sont marquées unsafe à moins de spécifier le contraire, est-ce que l'on ne se retrouverait pas avec de grosse lourdeur à exposer l'existant au safe C++ ? Il faudrait que j'en lise plus sur ce projet
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 16/09/2024 à 20:01
Citation Envoyé par archqt Voir le message
Quand j'ai dit cela à propos de Rust, en disant que c'était dommage de ne pas avoir conservé une syntaxe "C like" on m'a "moinsé" sans donner de contre argument. On est donc d'accord, et effectivement si java, C# ont décollé c'est en partie grâce à cela. Il suffit de regarder le Go, très performant aussi, il a plus de mal à décoller.
En effet certaines choses ne sont pas exactement identiques mais tout l’intérêt de faire un nouveau langage et que faire des choix mieux adaptés par défaut et pas se trainer des spécificités d'un vieux langage. C'est un gros défaut du C++ qui se traine l'héritage du C.

Rust n'a jamais prétendu être un surensemble de C++. Il a quand même une syntaxe relativement inspirée du C++ (acolades, point-virgules, opérateurs, espace insignifiant, le let n'est pas très différent du auto,...). Il y a des spécificités mais elles font sens quand on apprend les fonctionnalités spécifiques du langage.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 16/09/2024 à 22:37
Citation Envoyé par 23JFK Voir le message
Qui peut croire que les politiques savent ce qui est bon pour une industrie ? Rust est poussé par une communauté actuellement anormalement puissante dans les milieux de pouvoirs
Je suppose que vous parlez du rapport de la maison blanche préconise d'éviter les langage memory unsafe, il ne pousse pas uniquement Rust. Je ne connais pas d'autre exemple d'institution d'état demandant l'utilisation de Rust. Bien sur que les politiques n'y connaissent rien eux même, mais il s'appuient bien évidement sur des rapports de vrais experts de la sécurité.

Citation Envoyé par 23JFK Voir le message
ce n'est pas un mauvais langage, mais il n'est pas taillé pour la rentabilité/productivité et les faits d'armes de ce langage se résument à avoir réécrit des choses qui existent déjà et sans réelle nécessité de réécriture
On peut tout a fait dire la même chose de C++ qui n'a pas permis de faire quoique ce soit qui n'était pas possible avec C sans réelle nécessité de réécriture.
Pour ce qui est de la productivité, c'est discutable. Rust nécessite certes d'apprendre des notions qui n'existent pas en C++, mais ne nécessite pas d'en apprendre d'autre spécifiques au C++. Les contraintes qu'il ajoute à la compilation permettent d'éviter des erreurs couteuses en débogage. Google qui est le seul a ma connaissance a avoir mesuré la productivité entre les différent langage qu'il utilise, sur un nombre significatif d'équipes, a classé Rust au niveau de Go, deux fois plus productif que C++.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 17/09/2024 à 7:37
Je vois beaucoup de procès en wokisme contre Rust basés sur beaucoup de fantasmes et un seul fait : le code de conduite de Rust qui dit en gros d'éviter de discriminer des gens dans les canaux de communication officiels de la communauté et invite a garder les débats dépassionnés. Certes c'est un grave problème si l'on considère que harasser les minorités est un droit fondamental. Mais pour moi ce n'est pas du tout woke (si tant est que ce mot ait un sens), c'est le respect minimal que l'on est en droit d'attendre dans un groupe de travail. En dehors de la règle de non discrimination, Rust ne porte pas de projet politique particulier. je sais qu'il y a au moins un communiste, et conservateur revendiqués dans les équipes, mais une écrasante majorité est sans opinion affichée. Tous ces gens travaillent ensemble sans trop de difficulté, car il n'y a pas grand chose de mois politique qu'un langage de programmation.

Quand bien même Rust serait géré par des idéologistes woke, ça ne changerait absolument rien à ces capacité techniques. Un langage n'est pas un projet politique, c'est un outil qui n'a de sens que suivant la façon dont on l'utilise et c'est d'autant plus vrai pour un langage libre qui ne peut introduire de limitation d'usage. Rust est clairement utilisable pour tout. Pour citer quelque usages particulièrement woke de Rust, il y a les très nombreux projets de crypto-monnaies (les wokes adorant détruire l’environnement pour permettre une meilleure spéculation), chez Space X (Elon Musk étant un woke bien connu) ou pour du piratage pour des intérêts Russes (Poutine étant lui aussi un woke convaincu).
2  0