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

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

Darth Mitch Connor a écrit:
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

A la base j'ai écrit le bidule avec un IDE, gcc et tout le bazar (cygwin sous windows). Ideone est plus informatif que les options standard de mon IDE ! (Netbeans)

Pour ce qui est d’empêcher les boucles infinis, ce n'est pas vraiment le propos ... ce qu'il y a, c'est qu'il n'y a pas de boucle infini dans le code que j'ai fourni ! (enfin y en a peut être une, mais alors elle est bien cachée ...). Disons que quitte à apprendre un nouveau langage pour faire des tests, des sand box, résoudre des petits défis entre potes, autant prendre un langage qui signale un peu quand il y a un truc vraiment louche.

Si je comprends bien, avec c++, il faut installer des outils d'analyse statique en fait ...  j'ai déjà eu du mal à trouver (et installer !) un compilateur (gratuit) sous Windows.  

Darth Mitch Connor a écrit: Et quelques remarques : L'indentation c'est important. Les variables on leur donne des noms explicites. On attrape les exceptions.

Merci, faudra que j'essaye de comprendre d'où vient la boucle infinie magique, quand j'aurais envie d'y consacrer un peu de temps.

Prend Visual Studio Community : https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx

C'est l'IDE le plus puissant qui existe.

La boucle infini n'existe pas, tu accédais a une case d'un vector au dela de sa capacite du coup ca soulevait une exception, et comme elle était jamais attrape ça quittait juste le programme.