Guide pour aplanir la courbe d’apprentissage de Rust

• Rust est un langage qui exige une façon de penser entièrement nouvelle, et l’état d’esprit influence fortement la vitesse d’apprentissage
• L’essentiel est de se familiariser avec le compilateur ; il est important non seulement de corriger les messages d’erreur, mais aussi de comprendre pourquoi ils apparaissent
• Au début, il vaut mieux utiliser activement clone() et unwrap, commencer petit et refactoriser progressivement
• Il faut écrire beaucoup de code à la main et construire son intuition ainsi que sa mémoire musculaire à travers les erreurs et les tâtonnements
• Rust repose sur une philosophie de développement centrée sur le système de types ; il faut donc lire attentivement la documentation et s’exercer à modéliser avec les types

---

Flattening Rust's Learning Curve

Rust est connu pour être un langage difficile à apprendre, mais cet article propose, à partir de l’expérience de l’auteur, des conseils concrets sur l’attitude et l’approche à adopter pour l’apprendre plus efficacement

Let Your Guard Down

• Rust demande un modèle mental différent de celui des langages existants
• Il arrive que des débutants progressent plus vite que des experts → l’attitude et l’ouverture d’esprit sont essentielles
• Il faut voir le borrow checker non comme un ennemi, mais comme un co-auteur, et faire l’effort de comprendre les messages d’erreur
• Il est important de chercher à comprendre en profondeur pourquoi le compilateur exige des paramètres de lifetime
• Si le code devient laid et complexe, c’est peut-être le signe d’une mauvaise conception ; il faut s’en servir comme point de départ pour chercher une meilleure approche
• La verbosité de Rust aide pour les applications de grande taille et facilite le refactoring
• Il faut activer et utiliser tous les lint clippy dès le début

Baby Steps

• Au début, on peut utiliser sans hésiter String, clone(), unwrap, puis refactoriser plus tard
• Mieux vaut commencer par des instructions if et match simples plutôt que par des chaînes de méthodes complexes
• Il vaut mieux éviter l’asynchrone (async) pendant la première semaine
• Apprendre en expérimentant de petits morceaux de code dans Rust Playground
• Travailler avec un fichier main.rs par concept, et écrire la plupart du code en partant du principe qu’il sera jeté

Be Accurate

• En Rust, la précision est une condition de survie
• Les fautes de frappe et les petites erreurs provoquent immédiatement des erreurs de compilation, il faut donc être vigilant
• Prendre l’habitude d’ajouter automatiquement &, mut peut aider
• Les vidéos de développeurs en streaming comme Tsoding constituent de bonnes références

Don’t Cheat

• Dépendre des LLM ou de l’auto-complétion ralentit l’apprentissage
• Il faut taper soi-même, et prendre l’habitude de consulter la documentation quand quelque chose n’est pas clair
• Il ne faut pas coder en pilote automatique (auto-pilot)
• Il faut accepter les erreurs et s’en servir pour comprendre le fonctionnement du compilateur
• Il est aussi recommandé de s’entraîner à prédire si le code compilera avant de l’exécuter
• Prendre l’habitude de lire et analyser le code des autres est également important
• Pendant l’apprentissage, il vaut mieux limiter l’usage de crates externes, avec serde et anyhow comme exceptions acceptables

Build Good Intuitions

• Les concepts de lifetime et ownership gagnent à être compris visuellement
• Il est recommandé de prendre l’habitude de dessiner soi-même les flux de données, l’architecture, etc., avec des outils comme excalidraw
• Beaucoup d’excellents ingénieurs et mathématiciens utilisent aussi très bien les outils de visualisation

Build On Top Of What You Already Know

• En Rust, même les concepts familiers fonctionnent différemment (par exemple mut, le déplacement de valeurs, etc.)
• Mais apprendre par comparaison avec les langages existants reste utile

Exemples :

• Trait → ressemble à une interface, sans être identique
• Struct → une sorte de classe sans héritage
• Closure → similaire à une lambda
• Module → espace de noms
• Borrow → pointeur à propriétaire unique
• Option → monade Maybe
• Enum → type de données algébrique

• Rosetta Code est utile pour apprendre en comparant du code entre plusieurs langages
• Il est aussi efficace d’apprendre en portant vers Rust du code écrit dans un langage familier
• Il est bon de réfléchir à la manière d’exprimer en Rust des idiomes propres à un langage, comme la syntaxe intégrée des listes ou certaines boucles

Don’t Guess

• Rust est un langage où les suppositions ne fonctionnent pas
• Il faut se demander pourquoi on doit écrire un code comme "hello".to_string()
• Les messages d’erreur sont extrêmement instructifs, il ne faut jamais ignorer les indices qu’ils contiennent
• En particulier, les erreurs liées au borrow checker doivent être analysées en suivant manuellement le flux des données

Lean on Type-Driven Development

• Rust est un langage centré sur le système de types
• On peut tirer beaucoup d’informations des signatures de fonctions et des définitions de types
• Il faut lire souvent la documentation et le code source de la bibliothèque standard
• En concevant d’abord les types, puis en écrivant le code qui s’y conforme, on peut obtenir des structures plus précises et réutilisables
• Si l’on exprime les invariants dans les types, le code incorrect ne compile tout simplement plus

Invest Time In Finding Good Learning Resources

• Les ressources d’apprentissage de Rust ne sont pas encore si nombreuses, mais trouver tôt celles qui vous conviennent permet de gagner du temps
• Les outils d’apprentissage comme Rustlings divisent selon les préférences
• Des ressources orientées résolution de problèmes comme Advent of Code ou Project Euler peuvent être plus adaptées
• Les vidéos YouTube doivent être utilisées davantage pour le divertissement que pour leur valeur informationnelle
• La méthode la plus efficace consiste à acheter un livre, le lire hors ligne et écrire soi-même le code
• Si possible, suivre une formation ou un coaching par un expert peut aussi faire gagner beaucoup de temps sur le long terme

Find A Coding Buddy

• Observer pas à pas le code d’un collègue compétent, comme son ombre, peut aussi être très utile
• Demander des revues de code, ou en faire soi-même, sur le forum Rust, Mastodon, etc., permet aussi de progresser

Explain Rust Code To Non-Rust Developers

• Expliquer Rust à quelqu’un qui ne le connaît pas est aussi très bénéfique pour l’apprentissage
• Il est aussi recommandé de contribuer à du code non maintenu dans des projets open source
• Il peut être utile de rédiger un glossaire qui associe la terminologie Rust au langage de votre domaine métier

Believe In The Long-Term Benefit

• Rust est un langage pensé pour la qualité à long terme plutôt que pour la productivité à court terme
• Il est difficile d’en devenir expert du jour au lendemain, mais un mois d’effort concentré peut déjà apporter beaucoup
• Rust est un « Day 2 language » : le premier jour est difficile, mais sa valeur augmente avec un usage continu
• Pour réussir, il ne suffit pas de l’apprendre pour le CV ; il faut aimer la programmation elle-même

[aer0700]

Il m’est déjà arrivé, autrefois dans un but d’apprentissage, de réécrire en Rust du code que j’avais auparavant écrit en C, et je me souviens que l’expérience de manipulation des pointeurs avait été vraiment pénible... Je n’arrivais pas non plus à bien mettre de l’ordre dans ma tête sur le fonctionnement de Rc ou de RefCell, entre autres...

[q8840]

Après avoir lu une seule fois la documentation de base puis le Nomicon dans l’ordre, je n’ai jamais été bloqué avec Rust, donc je me demande si sa courbe d’apprentissage est vraiment si élevée.

[freedomzero]

Oh là là, si on prend l’habitude de unwrap et de clone, plus tard on va vraiment souffrir à cause de la propriété, ouin

[GN⁺]

Commentaire Hacker News

• J’ai l’impression de lire « A Discipline of Programming » ; si Dijkstra expliquait les choses d’une manière aussi morale, c’est qu’à l’époque les gens ne comprenaient pas vraiment les concepts mêmes de la programmation. Les explications de la propriété en Rust sont en général bien trop verbeuses ; l’essentiel y est souvent, mais caché sous les exemples. En Rust, chaque objet de données a exactement un propriétaire. Cette propriété peut être transférée, mais il ne doit toujours y avoir qu’un seul propriétaire. S’il faut plusieurs propriétaires, alors le véritable propriétaire doit être une cellule à comptage de références. Cette cellule peut être clonée. Quand le propriétaire disparaît, ce qu’il possède disparaît aussi. On peut emprunter temporairement l’accès à un objet de données avec une référence (ref). Propriété et référence sont clairement différentes. Les références peuvent être transmises et stockées, mais elles ne peuvent pas survivre plus longtemps que l’objet visé ; sinon on obtient une erreur de « pointeur pendant ». Ces règles sont strictement imposées à la compilation par le borrow checker. Voilà le modèle de propriété de Rust : une fois compris, les détails finissent tous par se ramener à ces règles.

  • Je ne sais pas si je suis le seul, mais j’ai du mal à suivre ce genre d’explication conceptuelle. J’avais le même problème avec l’encapsulation : on me disait juste que ça « cache de l’information », sans creuser concrètement le comment ni le pourquoi. Par exemple, en Rust, je ne comprends pas exactement qui est le propriétaire. Est-ce la stack frame ? Vu la structure LIFO, je me demande pourquoi la propriété est transmise à la fonction appelée ; comme sa pile disparaît d’abord, ça ne devrait-il pas être sans danger ? Si c’est pour l’optimisation, est-ce que cela permet simplement de libérer l’objet plus tôt ? Et si le propriétaire n’est pas la stack frame, alors qui est-ce ? Je ne comprends pas non plus pourquoi on ne peut donner qu’une seule référence mutable. En environnement mono-thread, aucune autre fonction ne démarre avant que la précédente ne se termine, donc on pourrait croire qu’il n’y a pas de problème à ce que deux fonctions reçoivent toutes les deux une référence mutable. Si le problème n’existe qu’en multithread, ne pourrait-on pas simplement signaler l’erreur à ce moment-là ? C’est à cause de ce genre de questions que je commence à apprendre Rust puis que j’abandonne sans cesse.

  • Ce n’est pas une explication de la propriété, c’est une explication de motivation. Le plus dur, et le plus central, c’est de savoir lire les signatures de fonctions quand les lifetimes s’emmêlent, puis de comprendre, corriger et résoudre les erreurs du compilateur lors de l’appel de ces fonctions.

  • Produire un résumé correct et parfait qui paraît évident aux gens qui connaissent déjà ces concepts est bien plus facile que de les expliquer à quelqu’un qui les découvre. Si on explique les choses comme ça, est-ce qu’une personne qui n’a connu que le call-by-sharing comprendra immédiatement ? J’en doute.

  • Quelqu’un qui ne connaît pas Rust ne saura rien de Rust après avoir lu uniquement ce résumé. Il repartira surtout avec l’idée que « ce langage a l’air d’avoir de la magie noire dans le compilateur ».

  • Les concepts de propriété et d’emprunt eux-mêmes sont faciles à comprendre. La vraie raison pour laquelle Rust est difficile à apprendre, c’est que les signatures de fonctions et le code réel doivent prouver mutuellement que les références ne survivent pas plus longtemps que les objets. Au passage, ne pas stocker d’objets référencés dans les types est souvent un meilleur choix, car cela simplifie la preuve.

  • Je cherche depuis longtemps des textes sur la manière dont les gens des années 1960 manipulaient l’état des systèmes et des applications au niveau assembleur. On m’a dit que l’article de Sutherland sur Sketchpad entrait beaucoup dans le détail des structures de données, mais je n’en ai lu que les chapitres 2 et 3.

  • Cette explication ne me parle pas vraiment. Elle ne définit pas clairement ce que sont la propriété et l’emprunt. Ces deux mots donnent l’impression d’être des métaphores tirées de la gestion d’actifs financiers. Je ne connais pas très bien Rust, mais ce choix de vocabulaire me semble rendre le concept plus difficile à comprendre. Les métaphores sont souvent à double tranchant. Une explication avec des termes plus directement liés à la mémoire serait sans doute plus utile.

  • L’explication du modèle omet complètement une distinction essentielle entre emprunt exclusif/partagé (ou mutable/immuable). Rust a fait beaucoup de choix sur la manière d’autoriser ces emprunts, et ils ne sont pas intuitifs. Par exemple, la règle de no aliasing ne vient pas de l’intuition, mais d’objectifs d’optimisation des fonctions. La partie la plus compliquée des emprunts, c’est que les règles d’élision des lifetimes font parfois pointer les messages d’erreur du compilateur vers un endroit qui n’a rien à voir avec la vraie cause. Ces règles d’élision ne sont pas intuitives ; ce sont des choix introduits pour simplifier.

  • La version révisée du Rust Book par Brown University explique vraiment très bien le borrow checker.

  • L’explication me semble incomplète ; par exemple, elle ne dit pas ce qui se passe quand l’emprunteur disparaît.

  • Quand il dit « le véritable propriétaire doit être une cellule à comptage de références », on a l’impression que c’est expliqué uniquement pour des gens qui savent déjà ce que c’est.

  • C’est seulement après avoir implémenté mon propre borrow checker que j’ai fini par comprendre le borrow checker.

  • Le deuxième point de la deuxième section est une grosse exagération. Il existe en réalité de nombreux cas où l’on peut écrire du code sûr que Rust ne compile pas. Toute cette complexité vient de la nécessité de rendre claires les limites de ce que le compilateur peut prouver.

• Le modèle de propriété de Rust, les lifetimes, les enum et le pattern matching m’ont semblé extrêmement lourds à la première approche. Lors de ma première tentative, j’ai été submergé bien trop vite ; à la deuxième, j’ai essayé de lire chaque ligne du livre et j’ai fini à court de patience. Entre-temps, j’ai compris que Rust est un langage qui donne une compréhension plus profonde de la programmation et de la conception logicielle. Ce n’est qu’à la troisième tentative que j’ai enfin commencé à apprendre en réécrivant, dans le style Rust, de petits programmes et scripts que j’avais déjà écrits auparavant. Au fil du processus, j’ai aussi assimilé la gestion d’erreurs à la Rust, la représentation des données en tirant fortement parti des types, le pattern matching, etc. Après cette expérience, je suis convaincu qu’apprendre Rust a été l’une des meilleures décisions de ma vie de programmeur. Définir à l’avance les types, structures et enum, puis écrire des fonctions à partir de données immuables et du pattern matching, c’est devenu naturel pour moi, même dans d’autres langages.

  • J’ai eu une expérience similaire. C’est à la troisième fois que Rust a vraiment commencé à me parler, et que j’ai pu écrire quelques programmes efficacement. Même avec une longue expérience en programmation, il arrive qu’un apprentissage demande plusieurs passages. À l’époque, j’avais aussi eu besoin d’exactement trois tentatives pour comprendre Dagger, le framework d’injection de dépendances de la JVM. C’est peut-être simplement un schéma récurrent chez moi quand j’apprends quelque chose de complexe.

  • C’est un phénomène fréquent chez les développeurs C++ qui découvrent Rust : en raisonnant avec des réflexes C++, on se retrouve à se battre en permanence contre le « borrow checker ». Une fois les conventions Rust bien assimilées, on peut même les réinjecter en C++ pour écrire du code plus robuste, même sans borrow checker.

• Le conseil du genre « relis soigneusement tout le code et corrige les fautes de frappe avant de compiler » me paraît étrange. Le compilateur de Rust est célèbre pour ses messages d’erreur très utiles ; je ne vois pas pourquoi je devrais rester bloqué sur mon code à chercher des typos. Je préfère que l’ordinateur les trouve pour moi.

  • cargo fix peut corriger automatiquement certains problèmes, mais pas tous.

• Il y a des conseils comme « ne résistez pas », « pour apprendre, il faut abandonner son arrogance », « il faut déclarer forfait », « résister ne sert à rien, plus vite vous l’acceptez, moins longtemps vous souffrirez », « oubliez ce que vous savez ». En lisant ça, j’ai l’impression que l’OS du télécran d’Orwell a dû être écrit en Rust.

  • Je suis d’accord avec ça. La plus grosse erreur qui m’a frustré quand j’apprenais Rust, c’était d’essayer de le forcer dans un paradigme orienté objet. Dès que j’ai accepté d’essayer simplement de faire comme Rust le veut, tout s’est mis à mieux fonctionner.

• Rust a une barrière d’entrée assez élevée pour les débutants. Il est très différent des autres langages — volontairement, mais c’est aussi ce qui en fait une barrière. La syntaxe est complexe et très condensée, au point de donner parfois l’impression qu’on a tapé sur le clavier avec les coudes. Un seul caractère peut changer totalement le sens, et l’imbrication est forte. Beaucoup de fonctionnalités sont difficiles à comprendre sans bagage théorique, ce qui accentue encore la complexité ; le système de types et le mécanisme d’emprunt en sont les exemples typiques. Pour un utilisateur classique de Python ou JavaScript, c’est presque extraterrestre. Comme on vit à une époque où la majorité des programmeurs n’a pas un bagage de master en informatique, Rust ne me semble pas très approprié. Et les macros compliquent encore davantage les choses. Si on ne sait pas ce qu’elles développent, il est difficile de comprendre le sens du code. Dernièrement, j’ai bon espoir que les LLM puissent abaisser cette barrière. Je ne ressens pas encore le besoin d’apprendre Rust, mais grâce aux LLM, je serais prêt à réessayer un jour. Rust reste un langage particulièrement difficile à apprendre.

  • Le point qui m’a le plus gêné en apprenant Rust, c’était justement les macros. Les ressources que j’ai utilisées les introduisaient très tôt, sans explication, ce qui a créé beaucoup de confusion.

• J’ai l’impression qu’il y a toujours une meilleure option que Rust, quelle que soit la situation. Cela dit, je garde l’esprit ouvert. Le jour où Rust sera suffisamment répandu, cela pourra prendre du sens.

  • Si l’objectif d’origine de Rust, lorsqu’il a été conçu il y a presque 20 ans, était bien de reconstruire un navigateur from scratch, alors c’est un langage parfait pour ça. Aujourd’hui, Rust domine déjà ce domaine. Et le « unix » du créateur du langage n’a jamais conquis le monde, ni été remplacé par une création quelconque comme Ladybird.

• Quand un langage a besoin d’articles qui essaient de convaincre les gens qu’il vaut la peine d’être appris malgré l’effort, je me demande s’il n’y a pas un problème dans la conception même du langage. (Je n’ai pas appris Rust, donc ne prenez pas ça trop au sérieux.)

  • Je ne peux lire ton commentaire que comme « ce qui est difficile ne vaut pas la peine d’être fait ». Tout a des avantages et des inconvénients ; est-ce que la simple existence d’inconvénients veut dire que ça ne mérite même pas d’être tenté ? Si quelqu’un écrivait un texte passionné pour dire que la harpe est difficile à apprendre, est-ce que ça ferait de la harpe un mauvais loisir ?

  • Quand on devient développeur senior, il arrive qu’on ait effleuré du regard les leçons que Rust met en avant, sans jamais les avoir vraiment ressenties. Beaucoup de gens pensent : « J’utilise déjà un langage avec ramasse-miettes, qu’est-ce que Rust pourrait bien m’apprendre ? » En pratique, dès qu’on mêle mutabilité et références partagées, un chaos énorme apparaît, ce qui pousse à introduire beaucoup d’objets immuables. Une fois qu’on a des objets immuables, on se remet à chercher un moyen commode de les transformer, et ils peuvent finir par être moins pratiques à utiliser que des objets mutables. Quand on essaie d’exprimer l’idée que « cet objet a une phase où il peut être modifié et une phase où il est immuable », on en vient finalement au besoin d’un borrow checker. Et une fois qu’on a un borrow checker, il reste la question : « alors pourquoi a-t-on encore besoin d’un ramasse-miettes ? » On utilise souvent le ramasse-miettes simplement parce qu’on n’a pas envie de comprendre clairement le lifetime des objets. Rust force à vivre directement ce type de questionnements fondamentaux.

  • Les choix de conception de Rust sont souvent difficiles à comprendre. Mojo a lui aussi un borrow checker, mais il est bien plus facile à apprendre que Rust à cause de quelques choix. D’abord, il y a la sémantique par valeur. En Rust, on dit souvent aux débutants d’utiliser clone(), alors que dans la plupart des langages statiques (C, C++, Go, etc.), la sémantique par valeur est le comportement habituel. Ensuite, dans Mojo, les lifetimes ne servent pas à déterminer si une valeur peut encore être utilisée selon la portée, mais à fixer le moment de sa destruction. S’il reste des références, le lifetime est prolongé ; dès que l’usage se termine, l’objet est détruit. Du coup, dans Mojo, on n’a pas besoin de voir des erreurs du type « la valeur ne vit pas assez longtemps ». Ces deux choix de conception suffisent déjà à réduire fortement la charge mentale.

  • Pour un débutant, n’importe quel langage est difficile à apprendre, donc Rust n’a rien de spécialement unique sur ce point. La programmation a de toute façon une courbe d’apprentissage.

  • Je pense que l’existence d’un tel article en dit plus sur son auteur que sur le langage lui-même. Ce n’est pas une critique de l’auteur ; je trouve au contraire formidable qu’il partage sa passion de cette manière.

  • Cet article semble surtout parler de la courbe d’apprentissage de Rust, plus que des problèmes que Rust résout. Il faudrait présenter les deux de manière équilibrée pour pouvoir conclure si cela vaut réellement la peine de s’y attaquer.

  • On peut débattre sans fin des choix de conception de Rust, mais le simple fait qu’un article comme celui-ci soit nécessaire ne permet pas vraiment d’évaluer le langage lui-même. J’aurais plutôt tendance à penser que Python est un langage qui aurait encore plus besoin de ce genre d’article. Avec l’augmentation du nombre de programmeurs sans formation d’ingénierie, Python est paradoxalement devenu un langage que tout le monde peut utiliser, alors que Rust n’est pas à la portée de tout le monde. Pour certaines personnes, Rust est bien plus facile à apprendre que C ou Zig. J’aime aussi Python, mais j’ai conscience que c’est fondamentalement un langage affreux. Même à l’ère des LLM, peu de gens savent qu’il faut écrire du Python optimisé. Nos amis IA aussi continueront à produire du Python inefficace si on ne leur dit rien.

  • À la question « n’est-ce pas un problème de conception du langage ? », j’ai surtout envie de répondre : « pourquoi ? »

  • En tant que personne ayant appris Rust, je peux dire que même si j’utilise principalement Python, je n’ai jamais eu l’impression que Rust souffrait de défauts de langage. Au contraire, c’est un langage extrêmement strict ; plus on essaie de l’écrire d’une façon qui n’est pas rustienne, plus on se complique la vie. Quand on suit le style Rust, il devient au contraire de plus en plus utile à mesure que la complexité augmente. Dans d’autres langages, les erreurs apparaissent au fil de l’exécution ; en Rust, presque tout est attrapé à la compilation. Bien sûr, cela n’empêche pas les erreurs logiques, mais la forte intégration des tests permet d’y répondre. Rust a des inconvénients, mais il vaut vraiment la peine d’être appris au moins une fois. La manière dont Rust cherche à réduire les erreurs peut aussi se réutiliser comme bonne pratique de développement dans d’autres langages.

  • Il est vrai que Rust est si complexe qu’un LLM a du mal à produire du code Rust correct du premier coup. Malgré cela, je préfère largement ça aux nombreux problèmes de JavaScript ou d’autres langages faiblement typés et dynamiques.

  • J’ai appris Rust et je partage ton ressenti. Rust est vraiment complexe, c’est un langage qui sent la « conception par comité ». L’outillage est excellent, et c’est tout de même moins complexe que C++, mais ce n’est certainement pas un langage facile à apprendre.

  • Le problème de ce genre d’article, c’est qu’il n’atteint pas le fond du sujet. Il existe des programmes qu’en Rust on n’a tout simplement pas le droit d’écrire. Il y a de bonnes raisons à cela, mais c’est une différence fondamentale avec presque tous les langages que la plupart des gens ont utilisés. Il faut accepter qu’il y a des programmes qu’on ne peut pas écrire en Rust ; sinon, Rust n’est probablement pas fait pour soi.

• Une approche qu’on voit rarement quand on apprend Rust consiste à commencer par n’en apprendre qu’un sous-ensemble. Par exemple, dans mon livre d’introduction à Rust, on n’enseigne pas du tout les lifetimes. On peut écrire beaucoup de programmes tout à fait fonctionnels uniquement avec des fonctions qui n’en ont pas. C’est pareil pour les macros : ce n’est pas simple, mais il faut de toute façon apprendre un sous-ensemble au début. Et plutôt que de s’appuyer dès le départ uniquement sur copy() ou clone(), je pense qu’il vaut mieux apprendre d’abord l’idée d’emprunt. L’emprunt est au cœur du langage.

• La seule façon de me faire apprendre Rust, c’est qu’il y ait beaucoup d’emplois à plus de 300 000 dollars par an. Je pense que Rust a aussi le potentiel de remplacer C++ dans la finance quantitative. Mais il y a déjà OCaml, et si je dois apprendre un langage extrêmement difficile et complexe, il faut d’abord que l’argent soit visible. Jusqu’ici, les emplois les mieux payés que j’ai vus utilisaient Python.

• En lisant ces commentaires, j’ai réalisé une attitude qu’on retrouve souvent chez les vieux programmeurs quand on leur fait une remarque. Plus on travaille longtemps, plus on peut devenir têtu. Chacun devrait peut-être se demander pourquoi il en est venu à refuser les suggestions du compilateur. Il faut examiner par soi-même ce qu’on veut faire différemment et ce qui nous en empêche.