Introduction de 30 minutes au langage Rust. (Un meilleur C)

Est ce qu'il marche avec du Mandarin ton programme au fait ?
http://is.gd/JVUBet

Je viens d'essayer de vérifier si le tien fonctionnait : "Standard input is empty" mouhahahaha !  
nah ! Enfin si ça se trouve c'est le site web qui merdoie mais bon

Chez moi ca fonctionne enfin ca me sort des ????????? car il n'a pas la locale.

Darth Mitch Connor a écrit:Chez moi ca fonctionne enfin ca me sort des ????????? car il n'a pas la locale.

Ce sont des chaînes UTF aussi en C++ ? Bon bon, admettons.

ah mais j'ai copié le input, les outputs c'est "???????" effectivement. C'est suspect que ça s'affiche correctement dans le programme, mais pas en sortie tout de même.

J'ai un peu tourné dans ma tête l'argument -- au demeurant fort classique -- du bug introuvable parmi des millions de lignes en C++, rendant absolument nécessaire l'adoption de langages plus sûrs. Et je me dis:

- qu'il correspond bien à une réalité qui a été constatée en pratique (des failles de sécurité énormes dans des outils puissants et très répandus);

- qu'il est quand même largement fallacieux.

Premièrement, parce qu'il n'est pas si courant que ça de travailler sur des programmes ayant des millions de lignes. Statistiquement, l'analyste-programmeur qui gagne sa croûte est plus souvent occupé à écrire le petit script PHP qui va bien pour alimenter ou exploiter un petit bout d'une base SQL de taille moyenne, voire modeste, qu'à revoir de fond en comble un système d'exploitation ou, plus modestement, un gros logiciel de bureautique. Donc, d'emblée, on pourrait remarquer que la nécessité absolue de ne jamais écrire de bug indétectable au milieu d'un million de lignes est beaucoup plus prégnante pour de très très gros projets que pour ceux qu'en pratique un analyste-programmeur lambda a des chances de rencontrer (et même si l'analyste-programmeur finit par être recruté pour bosser sur un projet pharaonique, ce sera vraisemblablement après s'être fait la main sur des projets sensiblement moins ambitieux).

Deuxièmement, parce qu'en pratique, les très très gros projets sont très majoritairement écrits en C, C++ ou à la rigueur Java, ce qui semble indiquer que ces langages ne mènent pas aussi infailliblement aux plantages dramatiques qu'on le prétend. C'est à leurs fruits qu'on juge les arbres, a dit le Seigneur Jésus (qui ne disait pas que des conneries), or les fruits de C/C++ sont quand même très très abondants et loin d'être aussi radicalement pourris que le prétendent les ennemis de ces langages.

Troisièmement, parce qu'un très très gros projet intègre toujours des tripotées de librairies qui n'ont pas été spécifiquement pensées pour ce très très gros projet-là, et qui en pratique plantent quand même très peu (il y a des exceptions notoires, mais ce sont des exceptions), ce qui n'est sans doute pas sans rapport avec deux considérations: 1) ces librairies ont été écrites par des gens qui avaient du talent (je maintiens que c'est le noeud du problème); 2) ces librairies ont déjà été archi-testées et déboguées au fil des ans, en sorte que leur réputation de fiabilité correspond à une réalité éprouvée dans la pratique, non à de simples promesses enthousiastes.

Un langage très fiable reste en théorie nettement préférable à un langage faillible. Il n'empêche qu'en pratique, on construit de plus grands projets informatiques avec des langages médiocres, mais répandus et employés par des programmeurs géniaux, qu'avec des langages irréprochables mais marginaux, employés par des programmeurs simplement talentueux voire médiocres.

Ou pour le dire autrement: si les mauvais ouvriers ont toujours de mauvais outils, les bons outils ne suffisent pas à faire les bons ouvriers, et les très bons ouvriers arrivent à bosser très bien avec des outils de qualité moyenne mais acceptable. C'est pas le Seigneur Jésus qui l'a dit, mais ça a quand même été maintes fois constaté. Or C/C++ sont des outils de qualité moyenne mais acceptable, et ça fait des dizaines d'années qu'ils le prouvent tous les jours. Ca fait aussi des dizaines d'années que des outils de meilleure qualité, type Ada, ne percent pas.

Certes, l'idéal reste le très bon ouvrier travaillant avec le très bon outil. C'est vrai, mais c'est une affirmation à peu près aussi stupéfiante et constructive que le fait d'énoncer qu'il vaut mieux être riche et bien portant que pauvre et malade.

Petitagore a écrit:
- qu'il est quand même largement fallacieux.

Premièrement, parce qu'il n'est pas si courant que ça de travailler sur des programmes ayant des millions de lignes. Statistiquement, l'analyste-programmeur qui gagne sa croûte est plus souvent occupé à écrire le petit script PHP qui va bien pour alimenter ou exploiter un petit bout d'une base SQL de taille moyenne, voire modeste, qu'à revoir de fond en comble un système d'exploitation ou, plus modestement, un gros logiciel de bureautique. Donc, d'emblée, on pourrait remarquer que la nécessité absolue de ne jamais écrire de bug indétectable au milieu d'un million de lignes est beaucoup plus prégnante pour de très très gros projets que pour ceux qu'en pratique un analyste-programmeur lambda a des chances de rencontrer (et même si l'analyste-programmeur finit par être recruté pour bosser sur un projet pharaonique, ce sera vraisemblablement après s'être fait la main sur des projets sensiblement moins ambitieux).

Deuxièmement, parce qu'en pratique, les très très gros projets sont très majoritairement écrits en C, C++ ou à la rigueur Java, ce qui semble indiquer que ces langages ne mènent pas aussi infailliblement aux plantages dramatiques qu'on le prétend. C'est à leurs fruits qu'on juge les arbres, a dit le Seigneur Jésus (qui ne disait pas que des conneries), or les fruits de C/C++ sont quand même très très abondants et loin d'être aussi radicalement pourris que le prétendent les ennemis de ces langages.

Troisièmement, parce qu'un très très gros projet intègre toujours des tripotées de librairies qui n'ont pas été spécifiquement pensées pour ce très très gros projet-là, et qui en pratique plantent quand même très peu (il y a des exceptions notoires, mais ce sont des exceptions), ce qui n'est sans doute pas sans rapport avec deux considérations: 1) ces librairies ont été écrites par des gens qui avaient du talent (je maintiens que c'est le noeud du problème); 2) ces librairies ont déjà été archi-testées et déboguées au fil des ans, en sorte que leur réputation de fiabilité correspond à une réalité éprouvée dans la pratique, non à de simples promesses enthousiastes.

Je ne comprends strictement rien à ce que tu essayes de dire. A moins que le propos ne soit de dire qu'il est possible d'utiliser C++, et que C++ est très utilisé. Oui c'est vrai. Java aussi est très utilisé. Tes propos concernant les bons ouvriers c'est de la politique, ou alors carrément de la théologie, et je ne comprends pas le rapport avec le thème du fil.

Stauk a écrit:Je ne comprends strictement rien à ce que tu essayes de dire. A moins que le propos ne soit de dire qu'il est possible d'utiliser C++, et que C++ est très utilisé. Oui c'est vrai. Java aussi est très utilisé.

Eh bien tu vois que tu comprends! (en revanche, tu ne réponds guère)

Tes propos concernant les bons ouvriers c'est de la politique, ou alors carrément de la théologie, et je ne comprends pas le rapport avec le thème du fil.

C'est de la théologie si tu y tiens, ça ne me vexe pas... Pour ma part, j'aurais juste dit "jus de crâne", mais si tu préfères des mots plus glorieux, ça me va.

Tu sais, il m'arrive couramment de parler pour ne rien dire d'important, c'est même à peu près la seule raison pour laquelle je fréquente ce forum. Mais si tu préfères que je te foute la paix sur ton fil, OK, OK, je me casse, pardon pour le bruit, bonne journée.

Petitagore a écrit: Mais si tu préfères que je te foute la paix sur ton fil, OK, OK, je me casse, pardon pour le bruit, bonne journée.

Disons que je préfère qu'on reste dans le sujet : le langage Rust. A la rigueur le langage C++ 11 (concurrent donc, et bien mieux implanté dans l'industrie)

Je viens lâcher mon petit commentaire, étant pour ma part un fan assumé de Rust.

Je replace un petit contexte sur ma personne : Je suis familier du C++ depuis 7 ans (en autodidacte), et ça inclut le C++11 que j'ai pas mal suivi également.
Je pratique Rust depuis l'été dernier de manière assez intensive, et j'ai également un petit peu participé au compilateur Rust.

Je vais donc me contenter d'exprimer mon point de vue, et pourquoi je préfère (de très loin) Rust à C++.

Rust est un langage qui force à la rigueur. Le compilateur est très chiant sur ce plan, et n'hésitera pas à vous envoyer paître si vous lui demandez de la merde.

En Rust, la memory-safety (je sais pas quel serait le meilleur terme français pour ça) est là par défaut, il faut explicitement demander au compilateur pour passer outre (avec des blocs unsafe). En C++, c'est le contraire, il faut explicitement demander de la memory-safety pour en avoir (avec std::unique_ptr et es copains).

Rust intègre naturellement des éléments de programmation fonctionnelle. De même sa programmation orientée objet est très différente du C++ (il n'y a pas d'héritage, uniquement des traits, que l'on pourrait assimiler aux interfaces de Java). Ça le rend un peu déconcertant au début, mais dans l'ensemble beaucoup plus élégant que C++.

Et oui, les principes de RAII et de traits de Rust forcent à concevoir les programmes très différemment de C++, mais je trouve que ça leur donne une structure plus claire, plus explicite.

Et maintenant que je regarde C++14 et C++17, avec les nouveautés qu'ils apportent, je trouve que C++ ressemble de plus en plus à de la magie noire.

Donc pour résumer, ce qui me fait aimer Rust, c'est que je trouve le langage très confortable. Quand on veut refactorer un morceau du programme par exemple, souvent il suffit de faire la modification là où on veut la faire puis suivre les erreurs du compilateur jusqu'à ce que ça compile à nouveau.

Le fameux troll « ça compile donc ça marche » du C/C++ se révèle souvent vrai avec Rust. Et quand ça compile mais que ça ne marche pas, c'est très souvent que la logique sous-jacente est fausse. Je n'ai pas encore rencontré de situations sournoise comme les « use after free » du C/C++ dans Rust.

Rust est un langage qui force à la rigueur. Le compilateur est très chiant sur ce plan, et n'hésitera pas à vous envoyer paître si vous lui demandez de la merde.

C++ le permet tout autant suffit d'ajouter une analyse statique a sa toolchain et ca fera le meme chose, j'ai juste pas envie de me taper une analyse statique sans arret, surtout que l'analyse statique que peut faire le compilateur peut empecher de faire des choses legales car il n'est pas parfait.
Avec C++ j'ai donc le choix et plus de flexibilite.

En Rust, la memory-safety (je sais pas quel serait le meilleur terme français pour ça) est là par défaut, il faut explicitement demander au compilateur pour passer outre (avec des blocs unsafe).

Y a rien de pire pour un programmeur systeme que de ne pas pouvoir gerer sa memoire comme il le veut, par exemple quand je veux optimiser mes allocations je vais faire de l'allocation in place dans un gros block poubelle, en rust je peux pas le faire je perds en performance car le compilateur est chiant.

Ça le rend un peu déconcertant au début, mais dans l'ensemble beaucoup plus élégant que C++.

L'elegance c'est subjectif, je trouve les interfaces et les traits ignobles.

Je n'ai pas encore rencontré de situations sournoise
comme les « use after free » du C/C++ dans Rust.

Moi non plus mais je ne l'ai jamais rencontre en C++ non plus car je sais programmer.

Du coup on en revient a ce que je disais, le Rust est concu pour lutter contre l'incompetence de certains, mais pour moi les incompetents ont pas leur place dans la programmation systeme je ne comprends donc pas cette recherche de garde fou.

Samplet a écrit:je suis presque sûr que les apports n'ont rien de révolutionaires. Juste une époque voire une lubie.

Ben non, et ils n'ont jamais prétendu l'être. Rust se veut être une alternative moderne au C et au C++, qui sont de très vieux langages dont l'évolution est contrainte par des choix ayant été faits il y a 20 ans. L'informatique a beaucoup évolué depuis.

C est un langage tout à fait pertinent si on cherche de la performance pure, mais ce n'est plus le seul objectif aujourd'hui, on note une demande croissante en terme de sécurité. Et si on regarde rapidement, la plupart des failles de sécurité sont dues à des buffer-overflows, des use-after-free, des data-races ou des non-zeroed-memory. Ce sont en effet des erreurs de programmeur, en général des oublis, ou un design mal conçu.

Mais Rust lui fait ça tout seul, plutôt que de laisser le programmeur se démerder avec. Et c'est ça son cheval de bataille : laissons le langage s'occuper des erreurs courantes et parfois vicieuses à détecter, pour laisser le programmeur s'occuper du véritable problème.

Et là clairement, oui, la productivité du programmeur dépend du langage qu'il utilise. Certains langages sont plus adaptés que d'autres à certaines tâches, il faudrait être stupide pour ne jurer que par un seul langage. Et en l'occurence, C/C++ et Rust n'ont pas les mêmes objectifs de design. Et même si dans ses moutures récentes, C++ essaie tant bien que mal d'intégrer certains designs récents, le langage est surtout très vieux, et ça donne une ignoble soupe de templates incompréhensibles.

Edit: pour Mitch : ton argumentation se résume à « Il suffit de savoir programmer. », mais dans ce cas, pourquoi ne fais-tu pas tout en assembleur ?

Mon argumentation se resume a "quand on travaille sur des choses complexes qui demandent de la programmation systeme il faut savoir ce qu'on fait".

Je fais beaucoup d'assembleur, mais uniquement quand je sais que je suis meilleur que le compilateur (par exemple pour tout ce qui est extension du processeur SIMD et autres), le compilateur C++ est tres performant et je peux faire tout ce que je pourrais faire en assembleur en C++ donc je ne vois pas pourquoi perdre du temps a le faire en assembleur.

Le rust m’empêcherai de faire des choses que je peux faire en C++ et en assembleur et je doute fort qu'il soit capable de battre les performances du C++ avec un memory model dit safe.

Levans a écrit:Edit: pour Mitch : ton argumentation se résume à « Il suffit de savoir programmer. », mais dans ce cas, pourquoi ne fais-tu pas tout en assembleur ?

C'est vraiment un argument très très polémique. Tu sais parfaitement que "pour la portabilité", qui est la réponse originelle des tout tout débuts du langage C, il y a plus de quarante ans, reste totalement pertinente. Il y en a plein d'autres et plein de meilleurs, mais celui-là reste absolument valide, tandis que l'argument du "fais donc ça en assembleur", c'est vraiment le point Godwin de la discussion informatique. Un peu de sérieux.

Petitagore a écrit:

Levans a écrit:Edit: pour Mitch : ton argumentation se résume à « Il suffit de savoir programmer. », mais dans ce cas, pourquoi ne fais-tu pas tout en assembleur ?

C'est vraiment un argument très très polémique.

Oui, c'est ce qu'on appelle un troll. À son argument pourri « Il suffit de savoir programmer. », je lui réponds par un encore pire « Tu n'as tout faire en assembleur. ».

Darth Mitch Connor a écrit:le compilateur C++ est tres performant et je peux faire tout ce que je pourrais faire en assembleur en C++ donc je ne vois pas pourquoi perdre du temps a le faire en assembleur.

Le compilateur Rust est très performant et je peux faire tout ce que je voudrais faire en C++ en Rust, donc je ne vois pas pourquoi perdre du temps à le faire en C++.

Ah oui, et au passage:

Darth Mitch Connor a écrit:je doute fort qu'il soit capable de battre les performances du C++ avec un memory model dit safe.

Levans a écrit:C est un langage tout à fait pertinent si on cherche de la performance pure, mais ce n'est plus le seul objectif aujourd'hui, on note une demande croissante en terme de sécurité.

Oui, Rust ne permet pas d'abuser des monstrueuses optimisations que l'on pourrait faire en C/C++. Et alors ?
Dans beaucoup de situations aujourd'hui, les projets sont prêts à sacrifier une partie de leurs performances inutiles pour gagner en sécurité et en lisibilité de code, afin que ce dernier puisse facilement être repris par les successeurs.

Avec tes argument Mitch, au vu des bugs qui ont été découvert ces dernières années, on en conclurait que ceux qui ont programmé OpenSSL, le noyau Linux, et de nombreux autres projets sont des incompétents, puisque ce sont des bugs qui auraient été attrapés par le compilateur d'un langage comme Rust.

@Stauk : Attaque gratuite ... Attaque gratuite ...   Attaque gratuite  ... Attaque gratuite ...

Levans a écrit:Oui, Rust ne permet pas d'abuser des monstrueuses optimisations que l'on pourrait faire en C/C++. Et alors ?
Dans beaucoup de situations aujourd'hui, les projets sont prêts à sacrifier une partie de leurs performances inutiles pour gagner en sécurité et en lisibilité de code, afin que ce dernier puisse facilement être repris par les successeurs.

Ne peut-on pas dire rigoureusement la même chose pour défendre Java? Je sais que le bytecode Java étant interprété, la dégradation des performances que cela entraîne est plus que notable (quoique pas forcément insupportable), mais il est désormais possible de compiler du Java directement en langage machine, avec GCJ. Est-ce que le compilateur Rust bat GCJ à plate couture?

C'est une vraie question. Si la réponse est oui, ça me donnera envie de m'intéresser à Rust (je déteste Java). Si la réponse est non, en revanche... l'abondance des librairies disponibles en Java risquerait de me faire préférer Java (et j'en serais bien triste car je déteste Java, bis).

Samplet a écrit:@Levans : je vois que tu n'es gros débutant naïf... Tu n'y connais rien en système d'exploitation pour sortir des âneries pareilles ! L'os t'empêche de faire n'importe quoi depuis 10 ans au moins.

• buffer overflow
  
• use after free
  
• data race
  
• use of non zeroed memory
  

Ces 4 erreurs sont à la source de la majorité des failles de sécurité qui ont été découvertes ces dernières années (coucou openSSL ). Fait intéressant : elles tombent toutes sous le coup de l'« undefined behavior » du C et du C++.

Par ces 4 erreurs, je serais curieux de savoir lesquelles sont empêchées par le système d'exploitation.

Petitagore a écrit:Ne peut-on pas dire rigoureusement la même chose pour défendre Java?

Bien sûr que si, et ce serait pertinent. Le reproche que je fais à Java, personnellement n'est pas d'être semi-interprété, mais d'être un langage à garbage-collector où tout est implicitement passé par référence.

Samplet a écrit:Nan et puis SSL, je te rappelle que cela reste encore le meilleur protocole utilisé pour les chiffrages sur la toile http.

On parle bien de ce protocole obsolète et dépassé que tout le monde est en train d'abandonner au profit de TLS ?



Et sinon mon cher Simplet, à part brasser du vent, tu pourrais apporter des trucs constructifs à la discussion ?

Nan parce que ok, dans les cas très particuliers que du as cité, Rust n'est peut-être pas pertinent, mais il n'a jamais prétendu l'être.

Vous êtes bien gentil les gens, à attaquer Rust sur ce qu'il n'a jamais prétendu faire et être, mais c'est un peu comme si vous reprochiez à une scie de ne pas être pratique pour enfoncer un clou. Ben non, ça n'a pas été fait pour ça.

Alors peut-être que vous, vos ordinateurs personnels et le serveur sur lequel vous hébergez vos mails et votre blog sont en RISC (ce qui d'ailleurs, est à opposer à X86 et non à Linux ou Windows, si je ne m'abuse), mais ce n'est pas mon cas, ni celui de beaucoup de gens.

Samplet a écrit:Oui mais y'a que les gros ignorant qui ne savent que linux c'est forcément non risc.

https://github.com/riscv/riscv-linux

Samplet a écrit:Désactive sur ton navigateur les SSL et tu feras moins le malin, même si tu n'achètes rien... Donc il est pas dépassé et c'est toi qui repasseras avec tes preuves.

Firefox a désactivé le support de SSLv3 à partir de la version 34.0 (https://www.mozilla.org/en-US/firefox/34.0/releasenotes/). J'utilise cette version ou une plus récente depuis sa sortie, donc depuis décembre 2014. Ma navigation se fait donc en TLS uniquement depuis, sans aucun problème.

Ah oui, et pour suivre ton edit, que tu as si joliment ajouté après coup, si TLS = SSL 3.1, alors que sont TLS 1.1, et TLS 1.2 et TLS 1.3 ?
C'est si joli de déformer la réalité pour la faire coller à ses propos... Si le nom a été changé, il y a peut-être une raison, tu ne crois pas ?


Permets donc moi de ne pas prendre pour parole d'évangile ce que tu affirmes sans aucune justification.

À son argument pourri « Il suffit de savoir programmer. », je lui réponds par un encore pire « Tu n'as tout faire en assembleur. ».

Pour ma part je trouve toutes les conferences sur Rust pathetique, ca va passer des heures a vendre des concepts qui existent depuis super longtemps. Je trouve l'argument du "ca va empecher les gens qui font n'importe quoi de faire n'importe quoi" encore plus ridicule, les mauvais programmeurs ont rien a faire sur des projets de prog systeme c'est tout, si dans mon equipe y a un mec qui fait des erreurs aussi stupide qu'un double free, je le vire tout simplement.

Le Rust a aussi comme désavantage d’être illisible je trouve.

Si tu n'as pas besoin des optimisations que le C++ t'offre tu n'as pas besoin d'un langage de programmation système, va faire du python ou du java. Si tu utilises un langage de programmation système c'est que tu veux absolument TOUT contrôler, je peux pas taper dans un block de mémoire et allouer in place ? Et bah ca degage, pas besoin de compilateur nazi, je veux vérifier que ca passe une analyse statique, je lance une analyse statique, c'est pas complique.

Pour moi oui si il y a des erreurs aussi simple qu'une analyse statique peut soulever alors on est face a quelqu'un qui ne devrait pas faire ca. Le fait que les gens soient pas bons et ne sachent pas utiliser les outils qu'on leur donne ne fait pas d'un langage un mauvais langage.

Un compilateur a comme travail de compiler pas de faire attention a ce que fais le programmeur, c'est de l'analyse statique et ca n'a rien a faire dans un compilateur.

Donc on résume :
Tu choisis un langage de programmation parce qu'il inclue de l'analyse statique dans sa compilation au détriment des performances, des libertés d’implémentation et d'une des plus grandes communauté parce que tu ne savais pas que l'analyse statique existe (si tu l'avais su tu te serais rendu compte a quel point l'argument de la securite est idiot).

Soon : Les perceuses qui empêchent de percer tant qu'un ingenieur n'est pas venu verifier qu'on peut percer.

Darth Mitch Connor a écrit:Le Rust a aussi comme désavantage d’être illisible je trouve.

Le C++ a aussi comme désavantage d'être illisible je trouve.

On tourne en rond, tu ne crois pas ?

On a bien compris que tu voues une haine viscérale à tout ce qui n'est pas C++, et que tout ce qui n'est pas le domaine dans lequel tu travailles n'est pas de la vraie programmation, mais un travail d'incompétents.

Comme je l'ai dit précédemment, je ne choisis pas Rust pour son analyse statique, mais pour son modèle mémoire pertinent (il fait de la vraie RAII contrairement à C++), son système de traits et de génériques à la fois élégant et puissant (et qui est je trouve beaucoup propre que les templates et l'héritage du C++), pour son intégration d'éléments de la programmation fonctionnelle de manière naturelle et agréable à utiliser, ainsi que son support immédiat de l'ABI C, qui efface de nombreux soucis de compatibilité.

Maintenant, si pour toi ce ne sont pas de bons critères pour choisir un langage, et bien je suis fier d'être un abruti incompétent à tes yeux.

Darth Mitch Connor a écrit:
Je trouve l'argument du "ca va empecher les gens qui font n'importe quoi de faire n'importe quoi" encore plus ridicule, les mauvais programmeurs ont rien a faire sur des projets de prog systeme c'est tout

Petitagore a écrit:
1) ces librairies ont été écrites par des gens qui avaient du talent (je maintiens que c'est le noeud du problème);
[...]

Si je comprend bien, au vue de ces seuls arguments, cela veut dire que ce qui justifie le non abandon d'un outils complexe c'est le fait que des gens doués l'utilisent sans faire d'erreurs et que donc, il vaut mieux ne rien changer parce que l'on est de ce fait sûr que la méritocratie en place ne sera pas dérangée et que le mec un peu moins doué n'arrivera pas à décrocher des résultats équivalent au mec super doué ? Ca sonne un petit peu comme lorsque l'on propose une modernisation des outils de travail en usine, que l'employé pour lequel la qualification n'est plus utile vient crier parce qu'on lui vole son job, non ?

Petitagore a écrit:
Il n'empêche qu'en pratique, on construit de plus grands projets informatiques avec des langages médiocres, mais répandus et employés par des programmeurs géniaux, qu'avec des langages irréprochables mais marginaux, employés par des programmeurs simplement talentueux voire médiocres.

L'historicité n'est pas un argument.
En pratique, on doit se lever pour aller gagner de l'argent le matin, donc c'est ce qu'il faut faire.

Petitagore a écrit:
Certes, l'idéal reste le très bon ouvrier travaillant avec le très bon outil. C'est vrai, mais c'est une affirmation à peu près aussi stupéfiante et constructive que le fait d'énoncer qu'il vaut mieux être riche et bien portant que pauvre et malade.

Parce qu'un argument est évident il est mauvais ?

Bibo a écrit:Si je comprend bien, au vue de ces seuls arguments, cela veut dire que ce qui justifie le non abandon d'un outils complexe c'est le fait que des gens doués l'utilisent sans faire d'erreurs et que donc, il vaut mieux ne rien changer parce que l'on est de ce fait sûr que la méritocratie en place ne sera pas dérangée et que le mec un peu moins doué n'arrivera pas à décrocher des résultats équivalent au mec super doué ?

En ce qui me concerne, ce n'est absolument pas le seul argument que j'ai cité, je ne sais pas si ta précaution oratoire visait à l'admettre ou à me faire un reproche -- en l'occurrence injustifié.

Il ne s'agit pas de méritocratie, mais d'abondance de librairies disponibles (notamment sous licence libre), la richesse d'un socle sur lequel on peut s'appuyer pour construire autre chose. Ce socle est plus abondant avec un vieux langage très répandu qu'avec un nouveau qui se lance, ce n'est pas stupéfiant mais ce n'est pas pour ça que l'argument ne vaut rien. Je mentionnais aussi -- et ça me paraît une raison aussi classique que légitime de se méfier d'un nouveau langage -- le risque de dépenser de l'énergie sur un truc qui peut tomber dans l'oubli comme avant lui pas mal d'autres langages, que j'ai cités, les exemples ne manquent pas. A part ça, j'affirmais la nécessité du talent dans tous les langages, les nouveaux comme les anciens -- je veux bien qu'on m'accuse en l'espèce de faire de l'enfoncement de portes ouvertes, mais ce n'est pas une raison pour faire comme si on le talent algorithmique était un truc secondaire pour faire une carrière de développeur. Il faudra aussi du talent en Rust, non?

Petitagore a écrit:
En ce qui me concerne, ce n'est absolument pas le seul argument que j'ai cité, je ne sais pas si ta précaution oratoire visait à l'admettre ou à me faire un reproche -- en l'occurrence injustifié.

Le caractère gras me sert à coller avec ce que tu dis de cet argument, tu le définis comme étant le noeud du problème évoqué plusieurs fois dans la conversation. Si c'est le noeud du problème et si je met en évidence que ce noeud n'a pas lieu d'être  alors il n'y a pas de problème.

Petitagore a écrit:
Il ne s'agit pas de méritocratie, mais d'abondance de librairies disponibles (notamment sous licence libre), la richesse d'un socle sur lequel on peut s'appuyer pour construire autre chose.

Pardon, mais tu évoquais la notion de talent, considérant que le manque de talent est le noeud du problème. C'est la seule chose à laquelle j'ai répondu.

Petitagore a écrit:
Je mentionnais aussi -- et ça me paraît une raison aussi classique que légitime de se méfier d'un nouveau langage -- le risque de dépenser de l'énergie sur un truc qui peut tomber dans l'oubli comme avant lui pas mal d'autres langages, que j'ai cités, les exemples ne manquent pas.

N'est-ce pas une problématique liée à toute tentative d'innovation ?
Tout ce qui est nouveau necessite un temps d'adaptation , la problématique ne se pose donc pas en des termes nouveaux-ancien, mais plutot en un rapport cout/bénéfice ou bénéfice/risque. De la même manière, énoncer que tous les nouveaux langages n'ont pas aboutit ne définit en aucun cas une loi du type : tout nouveau langage aura tendance à ne pas aboutir.

Petitagore a écrit:
A part ça, j'affirmais la nécessité du talent dans tous les langages,

Tu en as parlé comme un argument assez banal pour ne pas être évoqué, or c'est exactement ce qui remet en cause ton premier argument, le noeud du problème.

Si il faut du talent partout alors le talent n'est pas un argument a envisager.

Darth Mitch Connor a écrit:
Si tu n'as pas besoin des optimisations que le C++ t'offre tu n'as pas besoin d'un langage de programmation système, va faire du python ou du java. Si tu utilises un langage de programmation système c'est que tu veux absolument TOUT contrôler, je peux pas taper dans un block de mémoire et allouer in place ? Et bah ca degage, pas besoin de compilateur nazi, je veux vérifier que ca passe une analyse statique, je lance une analyse statique, c'est pas complique.

Sur ce point je suis d'accord : si rust n'offre pas un niveau de performance comparable à C++, alors c'est que le langage ne tient pas ses promesses.  Pour ma part, j'en attendrais qu'à élégance équivalente, Rust offre un meilleur niveau de performance : c'est un langage qui n'a pas à s’encombrer d'un historique de rétrocompatibilité en forme de spaghettis.

Mais à part comparer sur des problèmes pratiques, la question reste un peu rhétorique pour le moment.

Il y a un meet up rust le 20 avril, au fait. Si y a des gens intéressés.

Toujours coincé à Stockholm pour ma part, même si j'aurais bien voulu y aller. Ils en organisent un tous les mois, il me semble.

Par contre je suis présent sur le canal IRC #rust-fr (avec certains des organisateurs de ces meetups) sur les serveurs de mozilla (cf https://wiki.mozilla.org/IRC pour ceux qui veulent y passer).

mais pour son modèle mémoire pertinent (il fait de la vraie RAII contrairement à C++)

Sauf qu'il est tout sauf pertinent pour de la programmation systeme, ce serait un langage qui vise le meme marche que python je dirais que c'est pertinent.

Merci de bien vouloir definir RAII, si make_unique et make_shared ne sont pas du RAII pour toi, va relire la definition.

Wikipedia a écrit:Resource Acquisition Is Initialization (RAII)[1] is a programming idiom used in several object-oriented languages, most prominently C++, where it originated, but also D, Ada, Vala, and Rust.

C++ inventeur du RAII ne ferait donc pas de vrai RAII, j'ai pas assez de mains pour facepalm assez.

son système de traits et de génériques à la fois élégant et puissant

Subjectif sans interet donc.

programmation fonctionnelle de manière naturelle et agréable à utiliser

Haskell est la pour cette niche.

cela veut dire que ce qui justifie le non abandon d'un outils complexe c'est le fait que des gens doués l'utilisent sans faire d'erreurs et que donc

C'est si dur que ca de lire les messages ? Je demonte juste l'argumentation stupide pro-Rust (qui est a chaque fois securite securite) alors que la meme chose existe en C++.

Darth Mitch Connor a écrit:

cela veut dire que ce qui justifie le non abandon d'un outils complexe c'est le fait que des gens doués l'utilisent sans faire d'erreurs et que donc

C'est si dur que ca de lire les messages ? Je demonte juste l'argumentation stupide pro-Rust (qui est a chaque fois securite securite) alors que la meme chose existe en C++.

Il n'y a pas de loi qui dit qu'une argumentation stupide doit être démontée avec une argumentation stupide. Si tu veux dire autre chose que ce que tu écris, modifies ce que tu écris.

Sans vouloir vous commander, je vais vous prier de ne pas vous battre sur les broutilles. Concentrez vous sur les qualités et défauts des langages évoqués (principalement c++11 et successeurs, et Rust).  Chacun à le droit d'avoir son opinion, et éventuellement de répondre à une critique tant que ça concerne directement les langages.  Les querelles de personnes, et de formes ne font pas tellement avancer le fil.

Merci d'avance.

Moi a écrit:C++ le permet tout autant suffit d'ajouter une analyse statique a sa toolchain et ca fera le meme chose, j'ai juste pas envie de me taper une analyse statique sans arret, surtout que l'analyse statique que peut faire le compilateur peut empecher de faire des choses legales car il n'est pas parfait.
Avec C++ j'ai donc le choix et plus de flexibilite.

Moi a écrit:Le fait que les gens soient pas bons et ne sachent pas utiliser les outils qu'on leur donne ne fait pas d'un langage un mauvais langage.

Toi a écrit:Si tu veux dire autre chose que ce que tu écris, modifies ce que tu écris.

Ou alors lis ce qui est écris non ? C'est plus simple je trouve.

@Mitch

Oui tu as raison, Rust ne répond pas à un besoin impératif qu'il fallait absolument combler.

C'est bon tu es content ? Parce que bon, après tout, personne n'a jamais affirmé ça hein.

Comme tout langage de programmation, des gens choisissent d'utiliser Rust parce qu'ils le trouvent confortable. Et même si tu n'est pas d'accord avec eux sur la notion de « confortable », ça ne rend pas ledit langage moins pertinent.

Maintenant oui, je le dis et le maintient : dans le contexte d'un projet à plusieurs participants, je trouve Rust beaucoup plus confortable à utiliser, notamment car il contient beaucoup moins d'implicites que C++ et force chacun à expliciter de manière rigoureuse ce qu'il veut faire.

En un sens, on pourrait dire que Rust est un langage beaucoup plus mathématisé que C++. Ça tombe bien, j'aime les maths.

Car c'est con, mais il est beaucoup plus facile de faire un code illisible en C++ qu'en Rust.

Maintenant, en effet, les vrais programmeurs (alléluia !) ne font jamais cette erreur, et n'ont donc pas besoin d'outils pour leur simplifier la tâche.

Mais que veux-tu, je ne suis pas un vrai programmeur moi, je ne suis qu'un humain. Du genre à qui il arrive de faire des erreurs parfois stupides. Et dans ces cas là, je suis bien content que le compilateur de Rust me signale mes erreurs, plutôt que de voir mon programme se lancer dans une boucle infinie ou un comportement absurde que je mettrais 1h à débugguer.

Non mais ce que je trouve comme mauvais argument c'est le fait que tu sembles oublier tous les outils qui existent qui te permettent d'avoir le même niveau de rigueur et de sécurité que Rust.

Si tu le trouves plus beau/élégant c'est autre chose on est sur de la subjectivité mais objectivement le Rust n'a pas d'avantage sur le C++ sur le point toujours mis en avant "la securite"...

Samplet a écrit:Flot d'insultes ban de 48h

ENFIN

Stauk a écrit:Sans vouloir vous commander, je vais vous prier de ne pas vous battre sur les broutilles.

Ca n'aide pas à faire le tri entre ce qui tient de la critique constructive et de l'égo ?

Darth Mitch Connor a écrit:

Moi a écrit:;]Le fait que les gens soient pas bons et ne sachent pas utiliser les outils qu'on leur donne ne fait pas d'un langage un mauvais langage.

Toi a écrit:Si tu veux dire autre chose que ce que tu écris, modifies ce que tu écris.

Ou alors lis ce qui est écris non ? C'est plus simple je trouve.

Mon intervention concernait ceci : le talent n'est pas un argument.
Ici, tu confonds : évoquer le fait qu'un langage a des avantages et évoquer le fait que l'autre a des inconvénients. Là tu te cites disant un truc que personne ne débat.

Encore une fois, on revient à ce que je disais : pour avoir de la rigueur et de la sécurité en C++, il faut vraiment le vouloir et beaucoup de gens qui ne diraient pas non à ça n'ont juste pas la motivation de se les mettre en place (et j'en fais partie).

Rust au contraire impose tout ça d'office, donc c'est tout bénef.

Et si comme tu dis, C++ n'a rien à envier à Rust, le contraire est vrai également, Rust n'a rien à envier à C++.

Rust a la flexibilité a envier au C++ et le lot de performance qui vient avec ^^.

Pour moi Rust c'est un sous ensemble du C++ avec des garde fou pre-installe...

Pour ce qui est de la motivation de mettre en place :

ou
sudo apt-get install cppcheck

Difficulte > 9000

Darth Mitch Connor a écrit:Rust a la flexibilité a envier au C++ et le lot de performance qui vient avec ^^.

Ça, ce sont deux affirmations gratuites qui demandent à être justifiées avant d'être raisonnablement considérées.

Qui de mieux que les createurs respectifs des langages pour en discuter :

Désolé Mitch, mais j'ai clairement autre chose à faire que me taper une vidéo d'une heure pour essayer de deviner ce que tu essaies de dire.

Si tu veux dire quelque chose, fais-le clairement s'il te plait.

J'ai deja donner des exemples, libre a toi de ne pas les lire.

Si le debat C++/Rust et autres la conference merite d'etre vu. Je me suis bien renseigne avant de trancher en faveur du C++ et ce en ecoutant les different experts en débattre, tu devrais faire de meme.

Darth Mitch Connor a écrit:Je me suis bien renseigne avant de trancher en faveur du C++ et ce en ecoutant les different experts en débattre, tu devrais faire de meme.

Moi j'ai essayé les deux langages, plutôt que de laisser un « expert » me dire ce que je devais en penser. Puisque de toute façon il est toujours possible de trouver un « expert » pour t'explique que tel langage est infiniment mieux que tel autre.

Chacun son approche, je suppose.

Je l'ai fait aussi, je préfére juste avoir plusieurs sources, histoire de pas juger sur une experience totalement subjective.

Chacun son approche, je suppose.

Oki, j'ai fait (une) implementation en Rust du problème d'einstein

Enoncé :
On a 5 maisons alignées de couleurs différentes.
Dans chaque maison vit une personne de nationalité différente.
Chaque personne boit une boisson différente.
Chaque personne fume un type de cigarette différent.
Chaque personne élève un animal différent.
QUI ELEVE DES POISSONS ROUGES ?

Indices :
1. L'Anglais vit dans la maison rouge.
2. Le Suédois élève des chiens.
3. Le Danois boit du thé.
4. La maison verte est juste à gauche de la maison blanche.
5. Le propriétaire de la maison verte boit du café.
6. Le fumeur de Pall Mall élève des oiseaux.
7. Le propriétaire de la maison jaune fume des Dunhills.
8. L'homme qui vit dans la maison du centre boit du lait.
9. Le Norvégien vit dans la première maison.
10. L'homme qui fume des Blends vit à côté de celui qui élève des chats.
11. L'homme qui élève des chevaux vit à côté du fumeur de Dunhills.
12. L'homme qui fume des Blue Masters boit de la bière.
13. L'Allemand fume des Prince.
14. Le Norvégien vit à côté de la maison bleue.
15. L'homme qui fume des Blends a un voisin qui boit de l'eau.

implementation https://ideone.com/o2NNyE

Un module de test, pour Rust
https://github.com/BurntSushi/quickcheck

(faudra que je jette un œil au truc tantôt).

Bon j'ai tenté d'implémenter un truc en C++ ... c'est la misère. Mon compilateur C++11 ne signale rien, et pourtant une boucle for toute bête ne termine jamais ..... (le ideo en C++14 refuse de compiler en prime ...)

http://ideone.com/g0LeiC

Je vais tenter de passer par des choses plus basiques, mais c'est pas très commode votre c++ hein !

Ce programme écrit à l'ancienne fonctionne lui:
https://ideone.com/8RH0Yr

Mais ça donne pas envie d'utiliser le C++ tout ça ....

Bah il te dit que ca compile pas quoi :

prog.cpp:25:6: error: ISO C++ forbids declaration of 'H' with no type [-fpermissive]
   H(){

Tu as tente de faire un constructeur, mais le constructeur doit avoir le meme nom que la classe/structure.
De plus tu n'as pas besoin du code que tu mets dans ton constructeur, le constructeur par defaut du vector sera appelle seul.

Apres ideone c'est juste un site pour tester des snippets, si tu veux de l'analyse statique il te faudra l'installer chez toi et le jour ou un compilateur empeche les boucles infini on pourra plus jamais faire de jeux videos xD

Et quelques remarques :
L'indentation c'est important.
Les variables on leur donne des noms explicites.
On attrape les exceptions.

J'ai rendu ton code un peu plus jolie :
http://ideone.com/t98LRs