IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Rust Discussion :

C++ vs Rust : une comparaison pratique de la vitesse de compilation et de test des deux langages


Sujet :

Rust

  1. #1
    Chroniqueur Actualités
    Avatar de Bruno
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mai 2019
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2019
    Messages : 1 215
    Points : 24 364
    Points
    24 364
    Par défaut C++ vs Rust : une comparaison pratique de la vitesse de compilation et de test des deux langages
    C++ vs Rust : une comparaison pratique de la vitesse de compilation et de test des deux langages de programmation,
    par Matthew Glazar, ingénieur en génie logiciel

    L’ingénieur en génie logiciel, Matthew Glazar, pour qui coder en C++ serait « un cauchemar » reproche entre autre au langage de programmation C++ sa lenteur. Ce dernier n’est pas le seul à haïr le langage de programmation qui, de par son histoire, ou encore son intérêt pour des projets importants, mériterait mieux en termes de respect. On se souvient que Linus Torvalds avait déjà qualifié le C++ « de langage horrible » en 2011, pour ensuite indiquer en 2021 qu’il s’agit « d’un langage de m... » Le codage en Rust est-il aussi mauvais qu'en C++ ? S'interroge Matthew Glazar

    Nous avons vu de nombreux langages de programmation se développer en fonction de leur fonctionnalité et de leur popularité, mais les langages ne sont pas destinés à être utilisés en fonction de leur popularité. Nous devrions considérer l'efficacité et la productivité globales lorsqu'il s'agit d'utiliser un langage de programmation. En parlant d'efficacité et de popularité, l'un des langages de programmation les plus utilisés à l'heure actuelle est le C++. Il est connu pour sa contribution aux systèmes d'exploitation et à l'industrie du jeu, et c'est le langage le plus utilisé en termes de programmation compétitive en raison de sa bibliothèque prédéfinie de modèles standard (STL). D'autre part, Rust semble être un sujet brûlant ces temps-ci en référence au C++ en raison de « sa syntaxe similaire ». En-dehors de la syntaxe, il existe d'autres facteurs comme le temps de compilation qui explique pourquoi Rust se fait de la place face au C++.

    Nom : RvsCB.png
Affichages : 53364
Taille : 84,6 Ko

    C++

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    #include <iostream>
    int main() {
        std::cout << "Hello, world!";
        return 0;
    }
    Hello, world!

    Rust

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    fn main() {
        println!("Hello World!");
    }
    Hello, world!

    Rust est un langage de niveau système plus innovant en termes de gestion plus sûre de la mémoire. Il est créé pour être sûr et sécurisé sans affecter les performances et la vitesse. Rust est principalement utilisé pour développer des pilotes de périphériques, des systèmes d'exploitation tels que BlogOS, intermezzOS, QuiltOS, Redox, RustOS, Rux, Tefflin et Tock. Il est également utilisé dans les navigateurs comme Mozilla firefox, les jeux.

    En Avril 2021, Microsoft a annoncé Rust preview pour Windows, elle permet la création d'applications Rust pour le célèbre système d’exploitation de Microsoft en utilisant n'importe quelle API Windows. Avec Rust pour Windows, les développeurs peuvent non seulement utiliser Rust sur Windows, mais aussi développer des applications pour Windows en utilisant Rust.

    Faisant référence à un cours publié par Microsoft sur les premiers pas avec Rust, Miguel de Icaza, ingénieur distingué de Microsoft a tweeté : « le "Rustening" a commencé chez Microsoft ». Ce que la plupart des adeptes de Rust sur Twitter voient comme un signe que l'entreprise augmente encore ses faveurs pour son langage de prédilection. Bien sûr, ce n'est pas la première fois que Microsoft se tourne vers Rust pour gérer les 70 % de vulnérabilités de Microsoft qui, selon l'entreprise, proviennent de l'utilisation du langage de programmation C++, peu sûr pour la mémoire, dans ses logiciels.

    Pour certains analystes, le C++ possède des bases plus solides en ce qui concerne la communauté et les informations générales sur ses principes. En outre, par rapport au C++, Rust est un nouveau venu dans le monde de la programmation, et de nombreux développeurs hésitent à s'y intéresser.

    Ce développement ne semble pas être du goût de Linus Torvalds, ingénieur logiciel, créateur principal et développeur du noyau Linux, pour lui, le C++ est un langage horrible, le créateur du noyau Linux n’a d’ailleurs pas hésité à traiter également le C++ de langage de merde. Dans un post publié sur son blog le 14 avril, l’équipe de développement de Google a annoncé qu’elle participe à l'évaluation du langage Rust pour le développement du noyau Linux. Suite à cette déclaration, Linus Torvalds a déclaré lors d’une interview que des discussions sur le sujet seraient beaucoup plus importantes qu'un long post de Google sur le langage. Interrogé sur la suggestion d'un internaute qui a indiqué que, « la solution ici est simple : il suffit d'utiliser C++ au lieu de Rust », Linus Torvalds n'a pas pu se retenir et aurait traité le C++ de « langage de merde ».

    Rappelons pour les détracteurs du C++ que, le langage de programmation compilé permettant la programmation sous de multiples paradigmes (le C++), a dépassé Java le mois dernier dans l'indice mensuel TIOBE de popularité du langage, C++a été déclaré langage de l'année 2022 sur l'indice. Non seulement c’est la première fois dans l'histoire de l'indice TIOBE que le C++ dépasse Java, mais il est intéressant de noter au passage que des langages très souvent soutenus dans des forums comme Java ne figure pas dans le top 3 de l'indice mensuel TIOBE.

    Si le trio de tête n'a pas changé depuis décembre, C++ a revêtu le maillot jaune en termes de popularité sur l'année écoulée : la popularité de C++ a augmenté de 4,62 points de pourcentage d'une année sur l'autre, suffisamment pour remporter le prix du langage de programmation TIOBE de l'année 2022. L'index TIOBE mesure la popularité des langages de programmation en se basant sur le nombre de pages web retournées par les principaux moteurs de recherche lorsqu'on leur soumet le nom du langage de programmation. Il est mis à jour une fois par mois et donne l'historique depuis 2002.

    Le C++ est le langage de programmation de TIOBE de l'année 2022. Il a remporté ce titre parce que le C++ a gagné le plus de popularité (+4,62 %) en 2022. Les seconds sont C (+3,82 %) et Python (+2,78 %). « La raison de la popularité du C++ est son excellente performance tout en étant un langage orienté objet de haut niveau. De ce fait, il est possible de développer des systèmes logiciels rapides et vastes (plus de millions de lignes de code) en C++ sans nécessairement se retrouver dans un cauchemar de maintenance », l'organisation TIOBE.

    La décaration de l'organisation TIOBE au sujet du C++ contraste avec ce que disent les détracteurs du C++.

    Citation Envoyé par Matthew Glazar
    « Des projets comme Google Chromium prennent une heure pour être construits sur du matériel neuf et 6 heures sur du matériel plus ancien. Il existe des tonnes d'ajustements documentés pour accélérer les constructions et des raccourcis sujets aux erreurs pour compiler moins de choses. Même avec des milliers de dollars de puissance de calcul en nuage, les temps de construction de Chromium sont toujours de l'ordre d'une demi-douzaine de minutes. C'est totalement inacceptable pour moi. Comment des gens peuvent-ils travailler comme ça tous les jours ?

    J'ai entendu la même chose à propos de Rust : les temps de construction sont un énorme problème. Mais est-ce vraiment un problème dans Rust, ou est-ce de la propagande anti-Rust ? Comment se compare-t-il au problème de temps de construction du C++ ?

    Je me soucie profondément de la vitesse de construction et des performances d'exécution. Des cycles de construction-test rapides font de moi un programmeur productif et heureux, et je me plie en quatre pour que mes logiciels soient rapides afin que mes clients soient également heureux.
    »

    Pour en avoir le cœur net, Matthew Glazar va :

    • trouver un projet C++ open source ;
    • isoler une partie du projet dans son propre mini-projet ;
    • réécrire le code C++ ligne par ligne en Rust ;
    • optimiser la compilation pour le projet C++ et le projet Rust ;
    • comparer les temps de compilation+test entre les deux projets.

    Voici, ci-dessous, ses hypothèses qui sont selon lui des suppositions éclairées, pas des conclusions :

    1. le portage Rust aura légèrement moins de lignes de code que la version C++ : la plupart des fonctions et méthodes doivent être déclarées deux fois en C++ (une dans l'en-tête et une dans le fichier d'implémentation). Ce n'est pas nécessaire dans Rust, ce qui réduit le nombre de lignes ;
    2. pour les constructions complètes, C++ prendra plus de temps à compiler que Rust : ceci est dû à la fonction #include de C++ et aux templates C++, qui doivent être compilés une fois par fichier .cpp. Cette compilation est effectuée en parallèle, mais le parallélisme est imparfait ;
    3. pour les constructions incrémentales, Rust prendra plus de temps à compiler que C++ : ceci est dû au fait que Rust compile un module à la fois, plutôt qu'un fichier à la fois comme en C++, donc Rust doit regarder plus de code après chaque petit changement.

    Optimiser la compilation de Rust

    Dans le passé, Matthew Glazar aurait réussi à améliorer les temps de construction du C++ en passant au linker Mold. Voyons cela avec son projet Rust :

    Nom : IMG-R1.jpg
Affichages : 6837
Taille : 38,4 Ko
    Linux : les performances des éditeurs de liens sont à peu près les mêmes, c'est mieux plus bas

    « Dommage ; l'amélioration, si elle existe, est à peine perceptible », conclu Matthew Glazar. C'était Linux. macOS a aussi des alternatives à l'éditeur de liens par défaut : lld et zld.

    Nom : IMG-R2.jpg
Affichages : 6815
Taille : 48,4 Ko
    macOS : les performances des éditeurs de liens sont à peu près les mêmes


    Sur macOS, Matthew Glazar ne voit également que peu ou pas d'amélioration en changeant l'éditeur de liens par défaut. « Je pense que les éditeurs de liens par défaut sur Linux et macOS font un travail suffisant pour mon petit projet. Les linkers optimisés (Mold, lld, zld) brillent pour les gros projets », dit-il.

    Agencement des espaces de travail et des tests

    Rust et Cargo ont une certaine flexibilité dans la façon de placer les fichiers sur le disque. Pour ce projet, il y a trois dispositions raisonnables :

    Disposant d'un processeur à 32 threads sur sa machine Linux, et d'un processeur à 10 threads sur sa machine macOS, Matthew Glazar s'attend à ce que le déblocage de la parallélisation réduise les temps de construction. Pour un module donné, il y a aussi plusieurs endroits pour vos tests dans un projet Rust :

    Nom : IMG-R4.jpg
Affichages : 6825
Taille : 62,7 Ko

    Optimisation de la compilation C++

    Comme dans le cas de Rust, Matthew Glazar fait savoir qu’il a de l’expérience sur la compilation de C++. « Lorsque j'ai travaillé sur le projet C++ original, quick-lint-js, j'ai déjà optimisé les temps de compilation en utilisant des techniques courantes, comme l'utilisation de PCH, la désactivation des exceptions et de RTTI, la modification des tags de compilation, la suppression des #includeS inutiles, le transfert du code hors des en-têtes et l'externalisation des instanciations de template. »

    Selon Glazar, GCC est clairement hors norme sur Linux. Clang s'en sort beaucoup mieux. « Mon Clang personnalisé (qui est construit avec PGO et BOLT, comme ma chaîne d'outils Rust personnalisée) améliore vraiment les temps de construction par rapport au Clang d'Ubuntu. libstdc++ se construit légèrement plus vite en moyenne que libc++ », écrit-il.

    Utilisation de Clang personnalisée avec libstdc++ dans la comparaison C++ vs Rust.

    Nom : IMG-R6.jpg
Affichages : 6832
Taille : 69,1 Ko

    C++

    C++ est un langage de programmation compilé permettant la programmation sous de multiples paradigmes, dont la programmation procédurale, la programmation orientée objet et la programmation générique. Ses bonnes performances, et sa compatibilité avec le C en font un des langages de programmation les plus utilisés dans les applications où la performance est critique.

    C'est un langage polyvalent, ce qui signifie qu'il peut être utilisé dans presque tous les cas. Cependant, en raison de ses règles syntaxiques complexes et de son utilisation globalement difficile, il est principalement dominant dans les applications qui nécessitent une grande vitesse, la simultanéité et un examen plus approfondi du fonctionnement du matériel.

    C++ est le langage de programmation qui a permis de créer des systèmes d'exploitation comme Microsoft Windows. En outre, le C++ est utilisé pour produire la majorité des jeux vidéo sur le marché.

    Rust

    Avec Rust, il est possible de développer des pilotes de périphériques, des systèmes embarqués, des systèmes d'exploitation, des jeux, des applications web, et bien d'autres choses encore. Des centaines d'entreprises dans le monde entier utilisent Rust en production pour des solutions multiplateformes et économes en ressources. Des logiciels connus et appréciés, comme Firefox, Dropbox, et Cloudflare, utilisent ce langage. De la startup à la multinationale, du système embarqué au service web à haute disponibilité, Rust est une excellente solution.

    « Mon meilleur compliment envers Rust est qu'il est ennuyeux, et c'est un fantastique compliment », déclare Chris Dickinson, Ingénieur chez npm Inc. Pour Antonio Verardi, Ingénieur infrastructure chez Yelp, les développeurs disposent de tous les outils pour réussir à écrire du code en Rust. La documentation, l’outillage et la communauté sont tous simplement fantastiques.

    Temps de construction C++ vs Rust

    C++ ou Rust ? Lequel des deux compile le plus rapidement ?
    « J'ai porté le projet C++ vers Rust et optimisé les temps de compilation Rust autant que possible », indique Matthew Glazar.

    A l’issue de son expérience, Matthew Glazar constate :

    • Le portage Rust avait plus de lignes que la version C++, pas moins ;
    • Pour les builds complets, comparés à Rust, les builds C++ ont pris à peu près le même temps (17k SLOC) ou ont pris moins de temps (100k+ SLOC), pas plus ;
    • Pour les constructions incrémentales, par rapport à C++, les constructions Rust étaient parfois plus courtes et parfois plus longues (17k SLOC) ou beaucoup plus longues (100k+ SLOC), mais pas toujours plus longues.

    Le SLOC (Source lines of code), également connu sous le nom de lignes de code (LOC), est une métrique logicielle utilisée pour mesurer la taille d'un programme informatique en comptant le nombre de lignes dans le texte du code source du programme. Le SLOC est généralement utilisé pour prévoir l'effort nécessaire au développement d'un programme, ainsi que pour estimer la productivité ou la maintenabilité du programme une fois le logiciel produit.

    « Au cours du processus de portage, j'ai appris à aimer certains aspects de Rust. Par exemple, les proc macros me permettent de remplacer trois générateurs de code différents, ce qui simplifie le pipeline de compilation et facilite la vie des nouveaux contributeurs. Les fichiers d'en-tête ne me manquent pas du tout. Et j'apprécie les outils de Rust (en particulier Cargo, rustup et miri). »

    Les temps de compilation sont-ils un problème avec Rust ? Oui selon Matthew Glazar. « Il existe quelques trucs et astuces pour accélérer les compilations, mais je n'ai pas trouvé les améliorations magiques de l'ordre de grandeur qui me rendraient heureux de développer en Rust », dit-il. Les temps de compilation sont-ils aussi mauvais avec Rust qu'avec C++ ? Oui selon Matthew Glazar. « Pour les projets plus importants, les temps de compilation du développement sont pires avec Rust qu'avec C++, du moins avec mon style de code », précise-t-il.

    Au-delà de l’analyse de Matthew Glazar, beaucoup s’accordent à reconnaître que les deux langages de programmation ont leurs propres avantages et inconvénients. Par exemple, comme dit précédemment, le C++ bénéficie d'un énorme soutien de la part de la communauté et de nombreux cadres de travail pour le développement de logiciels, alors que Rust ne bénéficie pas d'un tel soutien par rapport au C++. D'un autre côté, il se dit que Rust est bien meilleur dans plusieurs aspects, comme la sécurité de la mémoire, la concurrence et il permet de réfléchir plus attentivement à l'utilisation de la mémoire et des pointeurs.

    De nombreux utilisateurs Rust affirment que la programmation dans ce langage est plus facile grâce à une sémantique bien définie et à la prévention des comportements indésirables. En C++, les développeurs auraient plus de problèmes lorsqu'ils essaient d'éviter les comportements non définis. En outre, le C++ est un océan profond comparé à Rust, car le C++ possède tellement de fonctionnalités et de possibilités d'implémentation qu'il peut devenir difficile d'en garder la trace.
    Au final, tout dépend si vous êtes à l'aise avec C++ ou Rust.

    Source : A practical comparison of build by Matthew Glazar

    Et vous ?

    Les conclusions de Matthew Glazar sont-elles pertinentes ?

    Selon vous, quel langage compile le plus rapidement ? C++ ou Rust ?

    Rust remplacera-t-il C++ à l'avenir ?

    Voir aussi :

    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

    C++ est sacré langage de programmation de 2022 sur l'indice TIOBE. En termes de popularité, sur l'année écoulée, il est suivi respectivement par C et Python
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Membre émérite
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    984
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : août 2003
    Messages : 984
    Points : 2 985
    Points
    2 985
    Par défaut
    Article intéressant mais je pense que RUST est un meilleur choix d'avenir :
    - même si le temps de compilation est différent entre C++ et RUST, ça vaut le coût de produire du code sécurisé au détriment de la durée de compilation
    - il manque encore de nombreuses bibliothèques en RUST mais on peut sans problème faire du web, du CLI, de la programmation système, ...
    - la gestion des bibliothèques est plus simple en RUST, j'ai des mauvais souvenir de C++ ou j'avais des erreur pendant la compilation car le fichier xxxxx.h n'était pas trouvé et donc je devais aussi chercher le nom de la bibliothèque manquante en C++, j'ai aussi des mauvais souvenirs avec les versions de bibliothèque à résoudre.

  3. #3
    Nouveau membre du Club
    Homme Profil pro
    Architecte technique
    Inscrit en
    décembre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2012
    Messages : 11
    Points : 37
    Points
    37
    Par défaut
    1°) les modules C++ permettent des gains de x10 pour les compilations
    => mes tests/essaie ont confirmé ces gains, les temps de compilation ne sont plus un problème avec c++ 20

    2°) Je trouve RUST super, mais il n'est pas comparable à C++, RUST c'est plus un DSL qu'un langage
    RUST se limite à certains nombres de designs pour des raisons de sécurité et de simplicité.

    mais ceci, provoquera un jour une impasse évolutive du langage comme pour java qui est actuellement dans l'impasse (cf nullpointer).
    Le C++ n'a pas ce problème mais cela demande plus de compétence

  4. #4
    Membre à l'essai
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    mai 2021
    Messages
    4
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : mai 2021
    Messages : 4
    Points : 18
    Points
    18
    Par défaut
    " 2°) Je trouve RUST super, mais il n'est pas comparable à C++, RUST c'est plus un DSL qu'un langage
    " RUST se limite à certains nombres de designs pour des raisons de sécurité et de simplicité.

    Je ne vois pas en quoi RUST est un DSL...

    Avec, je fais de l'objet, je fais du fonctionnel, j'implémente en multithread, mais aussi en asynchrone (en utilisant tokio). C'est déjà très riche pour un langage "DSL"...
    Mais le mécanisme des variables de type génériques, qui permet d'automatiser des implémentations conditionnelles, et le système de macro procédural sont aussi d'incroyables outils pour construire des librairies.

    Enfin, les contraintes de la programmation safe peuvent se lever sans problème, si on choisit de travailler en mode unsafe. Il faut savoir ce qu'on fait, mais cela ne pose aucun problème.

    En résumé, votre post est incompréhensible. J'ai l'impression que vous n'avez jamais fait de rust...

  5. #5
    Nouveau membre du Club
    Homme Profil pro
    Architecte technique
    Inscrit en
    décembre 2012
    Messages
    11
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2012
    Messages : 11
    Points : 37
    Points
    37
    Par défaut
    Je n ai pas dit que rust n est pas un langage complet, en plus j adore l utiliser.
    Mais son mode de gestion du cycle de vie des objets est bien un dsl dans le sens il contraint le programmeur, il est à l opposé du modèle java qui aujourd’hui se révèle être une impasse évolutionelle

    L avenir nous le dira pour rust. Dans tous cas , il répond très bien au besoin du moment

  6. #6
    Membre chevronné
    Homme Profil pro
    Ingénieur avant-vente
    Inscrit en
    septembre 2020
    Messages
    462
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur avant-vente

    Informations forums :
    Inscription : septembre 2020
    Messages : 462
    Points : 2 028
    Points
    2 028
    Par défaut
    C++ est devenu tout à fait acceptable dans sa version 11 et a fortiori 17.

    Et Rust n'est sécurisé que si tout le code est écrit dans ce langage. Dès lors qu'on utilise les types C et des bibliothèques écrites dans d'autres langages, il faut rajouter des clauses unsafe.

    L'autre fois sur ce site, quelque'un me suggérait le plus sérieusement du monde de développer des API afin d'utiliser des bibliothèques externes tout en gardant le code Rust sécurisé. On va éviter ça je crois. Niveau sécurité, mieux vaut encore vivre avec des clauses unsafe quitte à réécrire une partie du code une fois qu'il existera une alternative Rust de la bibliothèque externe.

  7. #7
    Membre émérite
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    984
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : août 2003
    Messages : 984
    Points : 2 985
    Points
    2 985
    Par défaut
    Citation Envoyé par Jeff_67 Voir le message
    L'autre fois sur ce site, quelque'un me suggérait le plus sérieusement du monde de développer des API afin d'utiliser des bibliothèques externes tout en gardant le code Rust sécurisé. On va éviter ça je crois. Niveau sécurité, mieux vaut encore vivre avec des clauses unsafe quitte à réécrire une partie du code une fois qu'il existera une alternative Rust de la bibliothèque externe.
    Le binding de bibliothèque est ce qui va être utilisé pendant un temps selon moi jusqu'à une implémentation RUST de celle-ci.

  8. #8
    Membre chevronné
    Homme Profil pro
    Ingénieur avant-vente
    Inscrit en
    septembre 2020
    Messages
    462
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur avant-vente

    Informations forums :
    Inscription : septembre 2020
    Messages : 462
    Points : 2 028
    Points
    2 028
    Par défaut
    Citation Envoyé par smarties Voir le message
    Le binding de bibliothèque est ce qui va être utilisé pendant un temps selon moi jusqu'à une implémentation RUST de celle-ci.
    Oui. Niveau sécurité, mieux vaut un binding qu'une API dont le risque de failles de sécurité est beaucoup plus important.

  9. #9
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    avril 2002
    Messages
    4 498
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : avril 2002
    Messages : 4 498
    Points : 14 836
    Points
    14 836
    Par défaut
    Citation Envoyé par Jeff_67 Voir le message
    C++ est devenu tout à fait acceptable dans sa version 11 et a fortiori 17.
    Tout dépends tes critères. En ce qui concerne la sécurité, il est clairement derrière Rust, bien qu'il le supplante sur d'autres points.

    Citation Envoyé par Jeff_67 Voir le message
    Et Rust n'est sécurisé que si tout le code est écrit dans ce langage. Dès lors qu'on utilise les types C et des bibliothèques écrites dans d'autres langages, il faut rajouter des clauses unsafe.
    Certes, à partir du moment où on utilise du unsafe on est plus 100% à l’abri des problèmes de sécurité mémoire, mais le principe du code unsafe et qu'il doit encapsuler les fonctionnalités potentiellement dangereuse dans un bloc qui doit avoir une interface sure.
    La surface de code qui peut introduire des comportements indéterminés se retrouve considérablement réduite et donc bien plus facile à contrôler.

    Citation Envoyé par Jeff_67 Voir le message
    L'autre fois sur ce site, quelqu'un me suggérait le plus sérieusement du monde de développer des API afin d'utiliser des bibliothèques externes tout en gardant le code Rust sécurisé. On va éviter ça je crois. Niveau sécurité, mieux vaut encore vivre avec des clauses unsafe quitte à réécrire une partie du code une fois qu'il existera une alternative Rust de la bibliothèque externe.
    Il va falloir préciser de quoi tu parles en tant que API. Les bibliothèques externes sont une forme d'API.

    Citation Envoyé par boumchalet Voir le message
    Je n ai pas dit que rust n'est pas un langage complet, en plus j adore l utiliser.
    Mais son mode de gestion du cycle de vie des objets est bien un dsl dans le sens il contraint le programmeur, il est à l opposé du modèle java qui aujourd’hui se révèle être une impasse évolutionelle
    Tous les langages contraignent plus ou moins le programmeur, ça n'en fait pas des DSL.
    Un DSL est un langage dont le domaine d’application est limité comme la description de documents(HTML, LaTeX, ...) ou les requêtes de BDD (SQL, ...) ce qui n'est pas le cas de Rust qui peut produire des applications de n'importe quel type.

  10. #10
    Membre extrêmement actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    octobre 2017
    Messages
    1 398
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : octobre 2017
    Messages : 1 398
    Points : 4 693
    Points
    4 693
    Par défaut
    Mouais l'éternelle guerre de religion entre le pro et les contre de tel ou tel langage, de telle ou telle technologie...

    De toute manière quel que soit l'avis de l'expert Duchmol, les avantages véritables de l'un ou l'autre langage, au final c'est le marché qui fait l'arbitre!

    Si tu as besoin d'une équipe importante pour un projet, le choix du langage de programmation dépendra de la disponibilité des ressources sur le marché de l'emploi et pas des qualités propres d'un langage considéré comme supérieur à un autre...

  11. #11
    Membre émérite
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    984
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : août 2003
    Messages : 984
    Points : 2 985
    Points
    2 985
    Par défaut
    Quand on se pose les questions suivantes :
    - combien de bug a eu le programme ?
    - combien de temps passe-t-on a corriger un bug ?
    - quelle est la gravité du bug ?

    Quand j'avais travaillé chez un éditeur de gestion d'entrepôt, il y avait 3 personnes à la maintenance... combien ça coûte pour une entreprise à l'année (salaires, locaux, ...) ?
    Sur ça, RUST permet de s'affranchir de beaucoup de maintenance (même s'il faut assurer un service minimum). Donc, le choix de RUST sur de nouveaux projets est très pertinent. On peut même être moins exigent sur la couverture du code par les TU avec ce langage.

    En tant que développeur, faire de la maintenance n'est pas ce qui me passionne le plus (et je ne pense pas être le seul), je préfère largement réaliser de nouvelles fonctionnalités.

  12. #12
    Membre habitué
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2019
    Messages
    79
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juin 2019
    Messages : 79
    Points : 188
    Points
    188
    Par défaut
    Compiler de C++ a toujours été beaucoup plus lent que compiler par exemple du C (et c'est NORMAL, le langage permettant beaucoup plus de chose).

    Jusqu'à récemment, utiliser la STL faisait exploser la taille des exécutables : heureusement, le linker est devenu plus intelligent et enfin supprime tous ce qui n'est pas utilisé (avant, le simple fait d'utiliser des std::string même sans utiliser les "stream" ajoutait des centaines de ko, ce n'est plus le cas).

    Utilisant de vielles machines, Rust est encore pire niveau temps de compilation ... mais c'est surtout par son utilisation mémoire que c'est problématique : compiler les parties RUST de Firefox demande de couper X et tout autre processus consommateur sur une machine de 4Go et la swap est bien bouffée.

  13. #13
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2019
    Messages
    154
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : septembre 2019
    Messages : 154
    Points : 779
    Points
    779
    Par défaut
    Je ne vois pas en quoi c++ spécifiquement est un langage horrible. Je trouve personnellement que tous les langages sont horribles, car la lecture d'un projet complexe finit toujours par être laborieux, quelque soit le langage utilisé. Ce qui manque, ce sont des outils pour synthétiser l'architecture d'un projet et pour naviguer facilement dans celui-ci. Après, qu'une classe/fonction soit écrite en python, en c++, en pascal, franchement, je ne vois pas beaucoup de différences: ce sont grosso-modo les mêmes structures de données, les mêmes boucles, les mêmes types de données.

  14. #14
    Membre habitué
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2019
    Messages
    79
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juin 2019
    Messages : 79
    Points : 188
    Points
    188
    Par défaut
    Citation Envoyé par d_d_v Voir le message
    Je ne vois pas en quoi c++ spécifiquement est un langage horrible.
    J'aime beaucoup les C/C++ et ceux qui les critiques sont généralement ceux qui ne les maitrisent pas, et en particulier, quand les critiques viennent de gens qui ne programment qu'en Python ou en Java, ca devient vite . Je ne parle pas de Torvalds, lui de toute façon critique ... tout

    Il y a évidemment des trucs à améliorer et la STL a des trucs parfois illogique ... mais c'est malheureusement le cas de tous les langages. L'un dans l'autre, le C++ a quand même bien évolué depuis les années 90 où j'ai commencé a l'utiliser et évolué dans le bon sens.


    Citation Envoyé par d_d_v Voir le message
    Je trouve personnellement que tous les langages sont horribles, car la lecture d'un projet complexe finit toujours par être laborieux, quelque soit le langage utilisé.
    Ca dépend surtout de la manière dont il est documenté, commenté et comment son architecture a été construite. Le problème est souvent le manque de maturité des développeurs qui ont travaillé dessus, surtout lorsqu'il y a des maintenances correctives à faire.

    Citation Envoyé par d_d_v Voir le message
    Ce qui manque, ce sont des outils pour synthétiser l'architecture d'un projet et pour naviguer facilement dans celui-ci.
    Dans les années 90, j'avais écrit un article sur des outils qui généraient des graphs logiques d'architecture directement depuis des sources C. C'était assez rudimentaire et il fallait que le source soit correctement formaté mais ca ne marchait pas si mal que ça.
    J'imagine que depuis le temps, le concept c'est développé, surtout que c'est plus simple avec un code "tout objet", non ?

  15. #15
    Membre du Club
    Homme Profil pro
    Responsable de service informatique
    Inscrit en
    février 2014
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : Responsable de service informatique

    Informations forums :
    Inscription : février 2014
    Messages : 14
    Points : 45
    Points
    45
    Par défaut
    Le temps de compilation pose problème sur les gros projets, à partir de quelle taille ?
    Car les 3 secondes mentionnées au-dessus dans les tests ça va c'est pas grand chose.

    Bien sûr ça n'empêche pas qu'il faille optimiser, mais 1s de plus que le C++ sur le test le plus long de l'article, et combien pour le lire, et combien pour l'écrire ?
    Peut-être que ça me surprend car mes développements sont des outils assez petits.

    Et est-ce que ces langages ont aussi une incidence sur le nombre de compilations ?
    J'ai l'impression de compiler moins souvent en Rust, mais c'est peut-être une impression.

  16. #16
    Membre habitué
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2019
    Messages
    79
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juin 2019
    Messages : 79
    Points : 188
    Points
    188
    Par défaut
    Citation Envoyé par gzii69 Voir le message
    Le temps de compilation pose problème sur les gros projets, à partir de quelle taille ?
    Car les 3 secondes mentionnées au-dessus dans les tests ça va c'est pas grand chose.
    Essais de compiler de grosses applies comme Firefox et tu verras ta douleur. Évidemment, il est énorme, beaucoup de fichiers, mais quand certains fichiers compilent en plusieurs dizaines de secondes, multiplié par le nombre de fichiers, ça devient rédhibitoire.
    Mais mon gros problème reste l'utilisation mémoire lors de la compile. Ceci dit, j'ai le meme problème avec des librairies C++ genre boost mais dans ce cas précis, c'est surtout que les dev ont de grosses bécanes et ne pensent plus aux configs plus restreintes ... comme les SBC.

Discussions similaires

  1. souci avec une comparaison de date
    Par Ludo75 dans le forum SQL Procédural
    Réponses: 6
    Dernier message: 20/02/2006, 16h59
  2. Réponses: 3
    Dernier message: 22/09/2005, 11h34
  3. Réponses: 10
    Dernier message: 30/06/2005, 13h20
  4. [MASM] Utiliser un .IF pour une comparaison de nombre signés
    Par Crisanar dans le forum x86 32-bits / 64-bits
    Réponses: 3
    Dernier message: 24/11/2004, 17h32
  5. une comparaison qui marche pas.
    Par gandf dans le forum C++Builder
    Réponses: 7
    Dernier message: 16/02/2004, 16h59

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo