Carnet de notes

Catégorie : Technique

  • Lecture de Steve Yegge : « The Death of the Stub­born Deve­lo­per »

    De  « The Death of the Stub­born Deve­lo­per »

    Here’s the rub: As of about May, LLMs can now execute most of the leaf tasks and even some higher-level inter­ior tasks, even on large soft­ware projects. Which is great. But what’s left over for humans is prima­rily the more diffi­cult plan­ning and coor­di­na­tion nodes. Which are not the kind of task that you typi­cally give junior deve­lo­pers.

    C’est peut être là que je diverge. C’est vrai pour les déve­lop­peurs « code », un peu moins pour les déve­lop­peurs « produit ».

    Howe­ver, some junior engi­neers pick this new stuff up and fly with it, basi­cally uple­ve­ling them­selves. And many senior engi­neers seem to be heading towards being left behind. So what is it, then?

    (…)

    Chat-Orien­ted Program­ming, CHOP for short (or just chop). Chop isn’t just the future, it’s the present. And if you’re not using it, you’re star­ting to fall behind the ones who are.

    Ne croyez pas qu’on a à faire à encore un rêveur qui imagine un futur avec des voitures volantes. On parle du présent.

    They believe these gene­ric auto­no­mous soft­ware agents will solve the problem of chop being too diffi­cult and toil­some. In fact some people claim that agents can take over the task graph enti­rely, perhaps at least for small busi­nesses, allo­wing non-tech­ni­cal CEOs to launch apps them­selves without having to hire any pesky deve­lo­pers.

    I think those people are smoking some serious crack.

  • Lecture de Steve Yegge :  « The Death of the Junior Deve­lo­per »

    De  « The Death of the Junior Deve­lo­per »

    Gene, as an accom­pli­shed and senior author, is deligh­ted with his produc­ti­vity gains with his LLM of choice, Claude Opus. He showed me a big writing project that he’d just fini­shed, in which he had spent easily 45+ minutes craf­ting the prompt, refi­ning it until he had a 7500-word narra­tive that could serve as a star­ting point for rewri­ting, editing, and adjust­ment. (In compa­ri­son, this blog post is about half that size.) And that draft was fantas­tic. I’ve read it and it’s glorious.

    On a good day, Gene can write 1,000 words per day. His esti­mate is that Claude did for him in 90 minutes what would normally have taken him ten days. It solves the « blank-page problem » and gets him to the 20-yard line, where the fun begins.

    Il y a d’autres histoires. Je note un motif que ceux qui répondent « qualité » ne semblent pas voir.

    L’IA est un outil. On ne lui demande pas force­ment de savoir tout faire, ni même de le faire bien. On lui demande de savoir faire assez pour amener le donneur d’ordre plus loin, ou plus vite, et majo­ri­tai­re­ment de lui permettre de se concen­trer sur sa tâche réelle, son vrai métier. C’est vrai même pour celui dont la tâche est l’écri­ture.

    My senior colleagues have recently recoun­ted simi­lar chat scena­rios in which a more junior dev would have been comple­tely taken in, poten­tially losing days to weeks of work going the wrong direc­tion.

    Or worse.

    Chat, it seems, is safer for senior program­mers than it is for junior ones. And a lot of compa­nies are going to inter­pret « safer » to mean « better. »

    (…)

    Brie­fly, what do I mean by « senior » here? Really just two things:

    –  You know what you want before the AI writes it. You already have a vision for how you would write this by hand, or have it narro­wed to a few reaso­nable options.
    –    You can detect when it is giving you bad guidance.

    J’ajou­te­rais : savoir utili­ser l’ou­til. Ça reste un outil. Comprendre ses limites, sa zone d’ef­fi­ca­cité et comment en obte­nir le meilleur peut faire la diffé­rence.

    Rien que : aujourd’­hui les tâches répé­ti­tives finissent toujours par dérailler mais qu’il est parfait pour créer le code qui va faire cette tâche répé­ti­tive (comme un déve­lop­peur en fait).

  • Lecture d’Anne Vella : « Dear Soft­ware Engi­neer: It’s Time to Reclaim Your Role »

    Cita­tions d’Anne Vella :

    I totally agree that soft­ware engi­nee­ring should be a lot more than just writing code. When I studied compu­ter science at univer­sity, they taught us how to elicit requi­re­ments, write user stories, design user inter­faces and apply UX prin­ciples, archi­tect complex systems, create test plans, execute test cases and so much more. The whole shebang.

    De mon temps on appe­lait ça de façon mépri­sante les pisseurs de code. Et pour­tant, à cause de la spécia­li­sa­tion, je vois énor­mé­ment d’in­gé­nieurs tomber dans cette caté­go­rie de « déve­lop­peur expert ».

    J’en ai même vu s’in­di­gner qu’on arbitre trop souvent en faveur du produit et des utili­sa­teurs plutôt qu’en faveur d’une qualité de code interne.

    Rien qu’à dire ça je sais que je vais avoir quelques réac­tions assez fortes.

    Personne n’a raison mais ça devient des métiers diffé­rents.

    Steve Yegge recently wrote a follow-up to his contro­ver­sial article The Death of the Junior Deve­lo­per, refra­ming his posi­tion as The Death of the Stub­born Deve­lo­per. He talks about how if you’re not adop­ting Chat-Orien­ted Program­ming, or CHOP, you’re getting left behind

    Je ne joue­rai pas à qui va devoir chan­ger.

    Je suis convaincu que les déve­lop­peurs « produit » vont devoir chan­ger de façon de travailler. Pour autant, le besoin ne va pas dispa­raître, loin de là. Les juniors vont vite avoir des super-pouvoirs. Les seniors qui se reposent un peu trop sur leur savoir acquis, sur la complexité du code set sur le besoin de renou­vel­le­ment perma­nent de techno vont eux avoir du soucis à se faire parce que leur valeur ajou­tée va deve­nir faible.

    On ne rempla­cera pas les déve­lop­peurs « code » experts. L’IA tant vantée n’est quand même qu’un outil statis­tique et je ne la vois pas de si tôt créer du code profond tel qu’on peut en trou­ver dans les biblio­thèques de code qui forment les briques de base. On aura besoin de personnes qui comprennent le fonc­tion­ne­ment de tout ça pour savoir quoi faire (éven­tuel­le­ment assis­tés par de l’ia s’ils le veulent). Là ce sont les juniors qui vont avoir du mal à trou­ver une place.

    Pour être franc je ne sais pas si tout ça est vrai­ment neuf. L’IA va juste démul­ti­plier un effet déjà exis­tant, mais peut être au point de rendre certains posi­tion­ne­ments très diffi­ciles à tenir.

    So dear soft­ware engi­neer, please take heed. If you’re not a “product engi­neer” and have specia­li­sed in writing code, AI may indeed take your job. But this isn’t just a warning – it’s an oppor­tu­nity. It’s time to reclaim your role and return to what soft­ware engi­nee­ring was always meant to be: a craft that combines tech­ni­cal exper­tise with problem-solving, user empa­thy, and busi­ness acumen. The future belongs to those with curio­sity who can see beyond the code.

    Mes propos semblent peut être trop alar­mistes, ou trop futu­ristes. J’ai l’im­pres­sion qu’on passe des paliers très vite.

    Je ne saurais trop conseiller aux déve­lop­peurs qui veulent prévoir leur avenir de sauter sans filet et de passer au CHOP et BATON décrits dans le billet cité.

    Si ça n’ac­cé­lè­rera pas grand chose aujourd’­hui, savoir comment utili­ser ses outils correc­te­ment demande un chan­ge­ment de para­digme et donnera plusieurs longueurs d’avance d’ici quelques années au plus.

    Si vous avez vu le sex appeal des déve­lop­peurs « no code » (non, il n’y a pas contra­dic­tion), ça va vite de démul­ti­plier.

    C’est une croyance de ma part mais elle est très forte.

    Oui, je sais. Il y a aussi à côté d’énormes enjeux éner­gé­tiques. J’ai­me­rais bien qu’on puisse les igno­rer mais je ne le crois pas. Je ne les mets pas de côté.

    Main­te­nant consi­dé­rant le coût des ingé­nieurs, celui de l’usage de ces outils, la valeur qu’on en tire, le futur sera quand même celui là. On peut refu­ser mais il faudra au mieux se prépa­rer à oublier les périodes fastes du point de vue emploi et salaire, pour ceux qui trou­ve­ront un emploi.

    Je n’ai pas la solu­tion à tout ça. Je me contente d’ob­ser­ver.

  • Prude IA

    Le contrôle des réseaux et de l’in­for­ma­tique par les États-Unis me saute à la figure de plus en plus souvent.

    Il y a peu, je lis que les États-Unis inter­disent TikTok si l’ac­ti­vité n’est pas reven­due à un tiers. L’enjeu c’est est celui de la sécu­rité natio­nale avec le fait que c’est une base chinoise et pas une base améri­caine. En même temps il y a une pres­sion qui commence à se consti­tuer de la part des États-Unis pour que l’Eu­rope ne bride pas les services améri­cains, voire qu’ils consi­dèrent les amendes de régu­la­tion de X ou de Meta comme du protec­tion­nisme au titre des règles de libre échange. Si l’im­pé­ria­lisme numé­rique se faisait par influence, main­te­nant on est dans le rapport de force clair et net.

    Ce n’est pas qu’une ques­tion écono­mique. Les liber­tés et inter­dits font partie de ce qui nous est imposé. C’est vrai autant pour le légal que pour le légal. Il est inté­res­sant de voir que les IA n’ont pas de filtre avan­cée pour gérer la vie privée mais qu’elles sont inca­pables de parler de corps fémi­nin ou de sexe. On importe à la fois leur free speech et leurs tabous.

    Où est-ce que ça nous mène ? Je ne sais pas, mais voyant quelle place est amenée à prendre l’IA, le fait qu’elle se fixe sur des règles du jeu d’un seul pays me met quelque part très mal à l’aise.

  • Outil ou collègue

    Mon conseil pour les rares qui me suivent encore et que j’ai pu moti­ver à deve­nir deve­lop­peur: fuyez! Redui­sez vos dettes. Votre train de vie. […] inves­tis­sez tout et prepa­rez vous pour l’hi­ver.

    Je vous garan­tie que avant la fin de votre carrière (voir de la décen­nie) il faudra se recon­ver­tir. Préfé­ra­ble­ment dans un truc manuel.

    On lit toujours plein de choses alar­mistes sur le futur. Tout avance très vite mais les métiers dispa­raissent rare­ment en moins d’une géné­ra­tion. Jusqu’à présent.

    Et pour­tant, vu d’où je l’ai lu, ça m’a fait cogi­ter.

    J’ai repris un peu mes tâches pénibles habi­tuelles via Cursor. Rien de neuf. Je le fais régu­liè­re­ment. Si je trouve la complé­tion auto­ma­tique magique, pour moi c’est un outil en plus, pas de quoi éteindre le métier.

    Là j’ai suivi les traces de Simon Willi­son. J’ai utilisé l’agent et lui ai tout dicté, refu­sant de toucher à un quel­conque fichier direc­te­ment, de résoudre un quel­conque problème tech­nique moi-même.

    J’ai plein de posi­tif et plein de néga­tif mais… mon dieu je ne conseille­rai pas à mon fils de faire du déve­lop­pe­ment. C’est foutu pour lui. Je ne sais pas s’il aurait pu tout réali­ser sans rien savoir, mais ça n’en était pas loin. Dans 2 ans, 10 ans… oui la moitié des tâches de déve­lop­pe­ment au moins se passe­ront proba­ble­ment d’ex­perts tech.

    Ok, c’est de la boule de cris­tal. Je peux me trom­per. Je me suis déjà trompé par le passé. Oui ça ne remplace pas tout mais on a passé un sacré cap. Il me reste 20 ans au moins, la révo­lu­tion se fera pendant ma vie profes­sion­nelle, et elle sera lour­de­ment impac­tée.

  • [Lecture] How decen­tra­li­zed is Bluesky really?

    Je n’ai pas de cita­tion à mettre en lumière. Le contenu est proba­ble­ment trop long pour le permettre.

    Je recom­mande toute­fois très chau­de­ment la lecture du billet de Chris­tine Lemmer-Webber sur Bluesky, le Fedi­verse, et la décen­tra­li­sa­tion à tous ceux qui s’in­té­ressent au sujet.

    Il y a de la tech­nique donc ça demande un peu de bagage mais pas besoin d’être un ingé­nieur non plus.

    Il y a une réponse d’un ingé­nieur de Bluesky, auquel il y a une réponse à nouveau mais si vous ne devez en lire qu’un, je recom­mande le premier.

    Je note d’ailleurs que l’es­pace de l’in­gé­nieur Bluesky n’a pas de RSS. Pour moi ce n’est pas un élément absent de sens.

  • IA : J’ai déjà l’im­pres­sion d’être un vieux con

    J’ai déjà l’im­pres­sion d’être un vieux con. Il y a des choses impres­sion­nantes sur l’IA mais ce qui risque surtout de boule­ver­ser mon monde à court terme c’est ce que je vois à travers des expé­ri­men­ta­tions de Simon Willi­son.

    Il cherche un prompt pour que Gemini iden­ti­fie l’em­pla­ce­ment d’ani­maux sur une image. Pourquoi pas.

    Là où ça m’in­té­resse c’est qu’il utilise Claude pour visua­li­ser ensuite si les coor­don­nées obte­nues sont bien perti­nentes.

    Mais, surtout, il décide d’en faire un petit outil sur une page web. Pour ça aussi, il passe par Claude qui lui génère tout le code de zéro. Il y a quelques erreurs mais il ne les corrige pas lui-même, il les fait corri­ger par Claude jusqu’à obte­nir le résul­tat attendu.

    Il y a eu quelques ques­tions liées à l’orien­ta­tion des images, et là c’est ChatGPT qui l’aide à débo­guer le tout puis géné­rer le code qui modi­fie l’orien­ta­tion des images.

    Et là… je me sens vieux. J’au­rais proba­ble­ment tout fait à la main, en beau­coup plus de temps, peut-être aban­donné au milieu si c’était un projet perso peu impor­tant. L’ar­ri­vée de l’IA pour tous les petits outils et les petites tâches va vrai­ment chan­ger la donne pour ceux qui savent l’uti­li­ser.

  • Nouveau tour dans les CSS-in-JS

    L’his­toire

    J’ai aban­donné mes premiers amours qu’é­taient les feuilles de style sépa­rées avec des nommages bien séman­tiques. Je travaille par les appli­ca­tions front-end par compo­sants, j’ai besoin que les styles fonc­tionnent de façon simi­laire.

    BEM était une bonne idée mais impra­ti­cable. Le nommage est pénible et il fallait encore garder une synchro­ni­sa­tion entre la feuille de style et les compo­sants. J’ai eu plai­sir à trou­ver CSS Modules mais on conti­nue à jongler sur deux fichiers distincts avec des imports de l’un à l’autre. Il fallait faire mieux.

    J’ai besoin que les styles soient édités au même endroit que les compo­sants, toujours synchro­ni­sés, mis à jour en même temps, limi­tés chacun au compo­sant ciblé.

    Tail­wind a trouvé une solu­tion à tout ça en géné­rant statique­ment la feuille de style à partir des compo­sants eux-mêmes. Je comprends pourquoi ça plaît mais je n’ar­rive pas à consi­dé­rer que redé­fi­nir tout un pseudo-langage paral­lèle puisse être une bonne idée. On finit toujours par devoir apprendre CSS, que ce soit pour expri­mer quelque chose que le pseudo-langage ne permet pas, ou simple­ment pour comprendre pourquoi le rendu n’est pas celui qu’on imagine.

    Je suis parti vers les solu­tions CSS-in-JS quand je code du React. Faire télé­char­ger et exécu­ter toute une biblio­thèque comme Emotion est loin d’être idéal mais ça reste fina­le­ment assez négli­geable sur une appli­ca­tion front-end moderne.

    Entre temps j’ai quand même décou­vert Goober, qui implé­mente le prin­ci­pal en tout juste 1 ko. L’éli­mi­na­tion des styles morts contre­ba­lance proba­ble­ment large­ment ce 1 ko de Javas­cript. On aurait pu en rester là.

    La mise à jour

    Je suis quand même gêné de devoir embarquer une biblio­thèque Javas­cript. J’ai fouillé voir si rien de mieux que Goober et Emotion n’avait pointé le bout de son nez depuis la dernière fois que j’ai tout remis en cause. Il se trouve que le paysage a sacré­ment évolué en cinq ans.

    D’autres que moi ont eu envie d’al­ler vers du plus simple. On parle de zero-runtime. Les styles de chaque compo­sant sont extraits à la compi­la­tion pour créer une feuille de style dédiée. Les parties dyna­miques sont faites soit avec des variantes prédé­fi­nies, soit avec des variables CSS qui sont ensuite mani­pu­lée par Javas­cript via les attri­buts `style`.

    Le véné­rable c’est Vanilla-extract mais on a juste une version plus complexe et entiè­re­ment Javas­cript des CSS-Modules. C’est d’ailleurs le même auteur, et le même problème fonda­men­tal : deux fichiers distincts à mani­pu­ler et à synchro­ni­ser.

    Vient ensuite Lina­ria qui semble une vraie merveille. Il a l’es­sen­tiel de ce que proposent les CSS-in-JS avec de l’ex­trac­tion statique avec tout ce qu’on attend au niveau de l’ou­tillage : types­cript, source maps, prépro­ces­seur et véri­fi­ca­tion de syntaxe, ainsi que l’in­té­gra­tion avec tous les cadres de travail clas­siques.

    Lina­ria c’est aussi WyW-in-JS, qui opère toute la partie extrac­tion et trans­for­ma­tion, au point de permettre à qui veut de créer son propre outil concur­rent à Lina­ria. Je trouve même cette réali­sa­tion bien plus signi­fi­ca­tive que Lina­ria lui-même.

    L’équipe de MUI en a d’ailleurs profité pour faire Pigment-CSS et conver­tir tout MUI. Pigment reprend tout le prin­cipe de Lina­ria avec la gestion des thèmes, la gestion des variantes, et quelques raccour­cis syntaxiques pour ceux qui aiment l’ap­proche de Tail­wind. En échange, ces fonc­tion­na­li­tés ne sont possibles qu’en écri­vant les CSS sous forme d’objets Javas­cript plutôt que sous forme de texte CSS direc­te­ment. La biblio­thèque est aussi plus jeune et la compa­ti­bi­lité avec tous les cadres de travail ne semble pas assu­rée.

    J’ai aussi traversé Panda-CSS mais sans être convaincu. Panda génère tout en statique mais il génère tout une série d’uti­li­taires et de variables par défaut, et injecte beau­coup d’uti­li­taires dans le Javas­cript qui sera exécuté avec l’ap­pli­ca­tion. C’est un croi­se­ment entre Emotion, Tail­wind et Lina­ria, mais qui du coup me semble un peu Fran­ken­stein. À vouloir tout à la fois, on finit par ne rien avoir de franc.

    Si c’est pour utili­ser avec MUI, le choix se fait tout seul. Dans le cas contraire, au moins pour quelques mois le temps que Pigment-CSS se déve­loppe un peu plus, Lina­ria me semble un choix plus sage. S’il y a quoi que ce soit qui coince, Goober reste une solu­tion prag­ma­tique et tout à fait accep­table.

  • Arrê­tons avec les frame­works agiles

    Jetez moi SCRUM, Shape-up et les autres, et encore plus leurs versions dites « at-scale » type SAFe.

    Je ne comprends même pas comment on en est arrivé là alors que le mani­feste agile met en avant «  Les indi­vi­dus et leurs inter­ac­tions, de préfé­rence aux proces­sus et aux outils ».

    Prétendre cadrer les indi­vi­dus et les inter­ac­tions via des proces­sus et des outils métho­do­lo­giques est un contre-sens total de ce qu’on a appris depuis le mani­feste.

    Quand on me demande ma méthode de prédi­lec­tion je parle de Kanban, parce que l’im­plé­men­ta­tion dans le logi­ciel revient juste à limi­ter le flux et donner une prio­rité à ce qui est déjà en cours, avec une grande liberté d’im­plé­men­ta­tion. S’il s’agis­sait de cher­cher une implé­men­ta­tion « comme dans la litté­ra­ture », je raye­rais d’un trait et range­rai Kanban avec les autres.

    Appliquer des outils et des proces­sus tout faits ça rassure quand on n’a pas confiance dans les indi­vi­dus et leurs inter­ac­tions.

    Le fond c’est la défiance, souvent du top mana­ge­ment, même si parfois elle se diffuse jusqu’aux équipes elles-mêmes à force de leur poser des exigences contra­dic­toires.

    L’idée c’est souvent que si les résul­tats ne sont pas ceux espé­rés c’est que les équipes travaillent mal, alors on va leur expliquer comment il faut travailler en impo­sant une recette sans cher­cher à appro­fon­dir les problèmes eux-mêmes.

    Rien que le présup­posé me semble toxique.

    Ne vous mépre­nez pas. Je trouve formi­dable que Base­camp forma­lise la façon dont ils fonc­tionnent. Ce n’est pas une critique de leur fonc­tion­ne­ment. Il y a plein de choses à penser dans la lecture de Shape-up.

    Le trans­po­ser tel quel avec des rituels, par contre, c’est proba­ble­ment une mauvaise idée. Trans­po­ser quoi que ce soit tel quel est proba­ble­ment une mauvaise idée d’ailleurs. Le cargo-cult est bien trop présent dans l’uni­vers logi­ciel, et encore plus dans l’uni­vers star­tup.

    Chaque équipe a ses besoins, des aspi­ra­tions, ses contraintes, ses indi­vi­dus. Croire que ce qui fonc­tionne à côté fonc­tion­nera chez nous en le reco­piant c’est se trom­per de prio­rité entre les indi­vi­dus et les proces­sus. C’est d’au­tant plus vrai qu’en géné­ral on en applique les arte­facts visibles mais pas la philo­so­phie sous-jacente.

    Je ne suis même pas convaincu que ce soit un bon point de départ pour ensuite itérer. Les rituels ont tendance à ne pas bouger, voire à s’ac­cu­mu­ler, surtout qu’ils appar­tiennent à « la méthode ». S’il faut commen­cer c’est proba­ble­ment par SLAP.

    Tout n’est pas à jeter. Il y a plein d’idées inté­res­santes à reprendre à droite et à gauche. Mon problème c’est la reprise d’un cadre complet comme si ça allait résoudre les problèmes.

    Dans mes boites à outils, en fonc­tion des besoins, j’au­rais tendance à conseiller les points suivants :

    • Des rétros­pec­tives régu­lières, à date fixe
    • Des itéra­tions de durée rela­ti­ve­ment fixe
    • Des points de synchro internes fréquents voire quoti­diens
    • Des démos aux utili­sa­teurs et parties prenantes
    • Une notion d’ap­pé­tit pour les sujets qu’on veut livrer
    • Une esti­ma­tion d’ordre de gran­deur de l’ef­fort pour la prio­ri­sa­tion

    Bref, un kanban avec des cycles qui permettent de régu­liè­re­ment sortir la tête du guidon, prendre du recul, voir ce qu’on veut chan­ger dans notre fonc­tion­ne­ment, déci­der quelle direc­tion on veut prendre pour la suite, et de vrais échanges amonts pour expli­ci­ter la complexité et l’ap­pé­tit pour les diffé­rents items.

    Le reste s’ajoute avec grande prudence. Sauf besoin spéci­fique j’au­rais tendance à décon­seiller les items suivant :

    • Les enga­ge­ments de livrai­son, hors besoin absolu (on ne déca­lera pas Noël)
    • Les esti­ma­tions autres que des ordres de gran­deur
    • Les back­logs (oui oui, vous avez bien lu)
    • Avoir plus d’un objec­tif par itéra­tion
    • Avoir déjà étudié la solu­tion avant de commen­cer
    • Tenter d’ap­pliquer ce que d’autres équipes font dans d’autres contextes au sein d’autres cultures

  • Rust, première jour­née

    Je suis le circuit de Compre­hen­sive Rust.

    Le jour 1 ce sont les struc­tures de contrôle et les types. Rien d’ex­tra­or­di­naire mais je me tiens à ma réso­lu­tion d’al­ler lente­ment sans griller des étapes.

    J’avais déjà tenté de me mettre à Rust il y a quelques années mais je me suis retrouvé un peu noyé. Je crois que j’ai voulu aller trop vite, tout lire sans mani­pu­ler jusqu’à me retrou­ver bloqué par manque de réflexes. Là je vais prendre l’op­tion oppo­sée.

    J’ai beau­coup aimé le retour impli­cite de Ruby. La dernière instruc­tion de chaque bloc est sa valeur de retour. Rust a choisi un méca­nisme un peu plus expli­cite, proba­ble­ment pour simpli­fier la gestion des types de retour : Il s’agit d’une valeur de retour si la dernière instruc­tion n’est pas suivie d’un point virgule.

    Je trouve ce choix trop discret, et cassant l’au­to­ma­tisme du point virgule systé­ma­tique. J’ai bien conscience que le compi­la­teur va m’évi­ter l’es­sen­tiel des erreurs mais quitte à ne pas avoir un retour impli­cite systé­ma­tique j’au­rais proba­ble­ment préféré avoir un retour plus expli­cite avec un symbole ou un mot clef en début de ligne, quitte à faire un return complet.

    Et, juste­ment, les points virgules en fin de ligne me sortent par les yeux. C’est quelque chose dont j’ai réussi à me débar­ras­ser en JS et en Ruby, que je ne retrouve pas en Python non plus. Je suis dans l’in­com­pré­hen­sion qu’un langage conçu rela­ti­ve­ment récem­ment ait fait le choix de les rendre obli­ga­toires.

    Tout le monde m’avait loué le compi­la­teur. Je n’ai pas fait d’er­reur assez forte pour vrai­ment juger des messages mais j’ai l’im­pres­sion de reve­nir plusieurs années en arrière telle­ment c’est lent. C’est pour moi un vrai point noir dans l’uti­li­sa­tion alors que je n’en suis qu’à des équi­va­lents « hello world ». Comment les déve­lop­peurs Rust font-ils pour accep­ter des attentes de ce type à chaque compi­la­tion ?

    Pas que du néga­tif. En fait à part ces trois points de détails, je retrouve mes petits assez faci­le­ment et ça semble assez fluide sur les méca­nismes de base.