Derrière mon expression un peu subversive "Ça marche du premier coup", voilà ce que je veux dire :
J'ai une intention de départ. Par exemple l'intégration de la fenêtre de debug ou le remaniement de code "profond" dont je parle. Je démarre les modifications et me laisse guider par les outils de contrôle du code qui accompagne le langage. Le terme "guider" est ici très important. C'est-à-dire que là où avec un langage comme Python (que j'aime beaucoup) je dois découvrir la plupart de mes erreurs à l'exécution, j'ai été guidé par les règles de Rust pour ne pas les faire. Et c'est extrêmement moins couteux.
Je suis interpelé par "(un) dialogue avec le compilateur qui consiste à lui faire comprendre que le code est valide." D'expérience avec Rust, les situations où le code était valide et où le compilateur ne le voyait pas ont été extrêmement rare. À tous les coups, les erreurs venaient de moi.
Au départ, quand j'ai commencé Rust, j'ai pensé qu'en effet, le temps passé au debug (ex. avec Python) était transféré à arranger le code pour être valide pour le compilateur Rust. Mais force et de constater après ces quelques années, que le gain de temps "au final" est énorme. Le temps passé au debug (à fouiner pour comprendre ce qui ne va pas) n'est passé quasiment que sur des problématiques "métier".
L'intérêt de Rust n'est pas son typage strict, ou ses énumérés, etc. C'est l'assemblage de tous ces paradigmes en un seul écosystème. Et du fait que ce soit le standard du langage. Cela tend les logiciels produit à bénéficier des avantages qu'ils induisent (ces paradigmes) même quand le développeur ne le fait pas "exprès". Je te rejoins clairement sur ce point :)
[^] # Re: Au sujet du « Ça marche du premier coup »
Posté par bux (site web personnel, Mastodon) . En réponse au journal Intégration d'une fenêtre de debug live en Rust 🦀. Évalué à 10. Dernière modification le 07 mars 2023 à 08:49.
Derrière mon expression un peu subversive "Ça marche du premier coup", voilà ce que je veux dire :
J'ai une intention de départ. Par exemple l'intégration de la fenêtre de debug ou le remaniement de code "profond" dont je parle. Je démarre les modifications et me laisse guider par les outils de contrôle du code qui accompagne le langage. Le terme "guider" est ici très important. C'est-à-dire que là où avec un langage comme Python (que j'aime beaucoup) je dois découvrir la plupart de mes erreurs à l'exécution, j'ai été guidé par les règles de Rust pour ne pas les faire. Et c'est extrêmement moins couteux.
Je suis interpelé par "(un) dialogue avec le compilateur qui consiste à lui faire comprendre que le code est valide." D'expérience avec Rust, les situations où le code était valide et où le compilateur ne le voyait pas ont été extrêmement rare. À tous les coups, les erreurs venaient de moi.
Au départ, quand j'ai commencé Rust, j'ai pensé qu'en effet, le temps passé au debug (ex. avec Python) était transféré à arranger le code pour être valide pour le compilateur Rust. Mais force et de constater après ces quelques années, que le gain de temps "au final" est énorme. Le temps passé au debug (à fouiner pour comprendre ce qui ne va pas) n'est passé quasiment que sur des problématiques "métier".
L'intérêt de Rust n'est pas son typage strict, ou ses énumérés, etc. C'est l'assemblage de tous ces paradigmes en un seul écosystème. Et du fait que ce soit le standard du langage. Cela tend les logiciels produit à bénéficier des avantages qu'ils induisent (ces paradigmes) même quand le développeur ne le fait pas "exprès". Je te rejoins clairement sur ce point :)
🦀🐍 http://github.com/buxx 🖥 https://algoo.fr 📋 https://tracim.fr