Pour la phase douloureuse, je suis ENTIÈREMENT (d'accord et) conscient de la courbe d'apprentissage (moi aussi seul, il m'a fallu 2 bons mois plusieurs heures par jour, pour arriver à un résultat vraiment correct et en écrire sans regarder la doc).
Tout ce que je peux te dire, c'est de t'essayer à OCAML et Haskell avant de continuer, si ce n'est pas le cas. Ce sont tous deux des langages fonctionnels puissants, très puissants et certaines pratiques du développement fonctionnel comme une partie de la gestion des types, sont intégrés à Rust. En testant les deux (dans l'ordre indiqué), j'ai trouvé Rust étonnament beaucoup plus facile, notamment Haskell qui est un langage aux fonctions pures, ce qui est déroutant.
Finalement c'est logique : Rust c'est "rouillé", voire les autres langages, c'est voir les bonnes pratiques qui en ont été extraites.
Autre piège que j'ai personnellement rencontré : le C et l'impératif plus généralement...
1. Trop souvent on peut lire que Rust c'est un C "évolué" - ou alternativement "limité". Personnellement je trouve ça dingue (et faux). Rust a un garbage collector statique, ce qui élimine 99% des "bugs" (oubli, maladresse, etc.) dans la gestion de la mémoire. Juste pour cela, la comparaison ne tient pas. Je ne parle même pas d'une gestion moderne des chaînes de caractères ! De plus il y a considérablement plus d'aspects à prendre en compte avant même d'écrire la première ligne, comme les durées de vie et la gestion des emprunts, ce qui oblige à réfléchir vraiment.
2. Il y a comme tous les langages, souvent plusieurs moyens d'arriver au même résultat mais tous, tant qu'ils compilent, sont bons. La gestion par trait, la composition, renforcent la qualité globale sans qu'on s'en rende compte. Rust est un excellent moyen d'écrire du code à plusieurs. C'est un signe si Microsoft et d'autres, dont l'orientation est à l'opposé de Mozilla, s'intéresse de plus en plus à ce bijou.
A ce sujet, certains commentaires de cet article, me laissent à penser que ces points ont négligés notamment sur la question de la performance et de la robustesse qui sont procurés justement par les qualités intrinsèques du langage. Bref.
Pour la question des durées de vie qui semble empoisonner le langage (au début), n'oublie pas que c'est un prix à payer pour avoir un résultat d'une qualité "minimale" déjà importante. Et c'est une question d'habitude. Tu peux contourner la plupart des explicitations nécessaires en passant par des structures et des énumérations (abuse-en. Si si, encore). Lorsque tu ne peux pas faire autrement, raisonne en terme de "séquences" de traitement (puis en faire une fonction ?) : cela t'évite certains des problèmes de partage mutable et non-mutable, en définissant une clôture ou un bloc, ou simplement repenser ton organisation.
"Dialogue" avec le compilateur. D'ailleurs les bouquins sur le sujet rust-lang pousse à cela. J'ai pas de scruJ'utilise énormément https://play.rust-lang.org/ pour tester des portions, des organisations d'un code plus vaste. C'est rapide et facile. D'ailleurs pas besoin de cargo ou du site : rustc et c'est parti ! Mon environnement de dév. pour des bouts de code, c'est la commande suivante (sans honte) :
Enfin et j'arrête là mon lirisme : pour moi, un développeur contemporain, c'est - au moins - Python + Rust + Common LISP.
* Python par sa grande popularité, sa présence quasi par défaut dans les environnement Linux, sa souplesse et sa rapidité à concevoir des traitements, la clarté du code et sa puissance / richesse dans le traitement moderne des données (via Jupyter ou autre) ;
* Rust car il produit un code compilé ainsi que les qualités évoquées plus haut ;
* Common LISP (je pense notamment à l'implémentation SBCL), parce que c'est LISP, parce que c'est normalisé, parce que tu prends un claque quand tu comprends le vrai sens de "macro", parce que c'est la puissance grammaticale, la facilité de résolution des AST et la beauté des lambdas. Bref CL lorsque tu dois aller vers des aspects de programmation que les deux autres langages ne supportent pas ou mal. Et d'ailleurs que parfois, seul CL supporte (plus de possibilités que Scheme, même si le débat est ouvert à ce propos).
Bref je pourrais passer des heures, j'adore ça et si je peux aider, ce sera avec plaisir :)
[^] # Re: Formatage automatique
Posté par JulienG . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 3.
Pour la phase douloureuse, je suis ENTIÈREMENT (d'accord et) conscient de la courbe d'apprentissage (moi aussi seul, il m'a fallu 2 bons mois plusieurs heures par jour, pour arriver à un résultat vraiment correct et en écrire sans regarder la doc).
Tout ce que je peux te dire, c'est de t'essayer à OCAML et Haskell avant de continuer, si ce n'est pas le cas. Ce sont tous deux des langages fonctionnels puissants, très puissants et certaines pratiques du développement fonctionnel comme une partie de la gestion des types, sont intégrés à Rust. En testant les deux (dans l'ordre indiqué), j'ai trouvé Rust étonnament beaucoup plus facile, notamment Haskell qui est un langage aux fonctions pures, ce qui est déroutant.
Finalement c'est logique : Rust c'est "rouillé", voire les autres langages, c'est voir les bonnes pratiques qui en ont été extraites.
Autre piège que j'ai personnellement rencontré : le C et l'impératif plus généralement...
1. Trop souvent on peut lire que Rust c'est un C "évolué" - ou alternativement "limité". Personnellement je trouve ça dingue (et faux). Rust a un garbage collector statique, ce qui élimine 99% des "bugs" (oubli, maladresse, etc.) dans la gestion de la mémoire. Juste pour cela, la comparaison ne tient pas. Je ne parle même pas d'une gestion moderne des chaînes de caractères ! De plus il y a considérablement plus d'aspects à prendre en compte avant même d'écrire la première ligne, comme les durées de vie et la gestion des emprunts, ce qui oblige à réfléchir vraiment.
2. Il y a comme tous les langages, souvent plusieurs moyens d'arriver au même résultat mais tous, tant qu'ils compilent, sont bons. La gestion par trait, la composition, renforcent la qualité globale sans qu'on s'en rende compte. Rust est un excellent moyen d'écrire du code à plusieurs. C'est un signe si Microsoft et d'autres, dont l'orientation est à l'opposé de Mozilla, s'intéresse de plus en plus à ce bijou.
A ce sujet, certains commentaires de cet article, me laissent à penser que ces points ont négligés notamment sur la question de la performance et de la robustesse qui sont procurés justement par les qualités intrinsèques du langage. Bref.
Pour la question des durées de vie qui semble empoisonner le langage (au début), n'oublie pas que c'est un prix à payer pour avoir un résultat d'une qualité "minimale" déjà importante. Et c'est une question d'habitude. Tu peux contourner la plupart des explicitations nécessaires en passant par des structures et des énumérations (abuse-en. Si si, encore). Lorsque tu ne peux pas faire autrement, raisonne en terme de "séquences" de traitement (puis en faire une fonction ?) : cela t'évite certains des problèmes de partage mutable et non-mutable, en définissant une clôture ou un bloc, ou simplement repenser ton organisation.
"Dialogue" avec le compilateur. D'ailleurs les bouquins sur le sujet rust-lang pousse à cela. J'ai pas de scruJ'utilise énormément https://play.rust-lang.org/ pour tester des portions, des organisations d'un code plus vaste. C'est rapide et facile. D'ailleurs pas besoin de
cargoou du site :rustcet c'est parti ! Mon environnement de dév. pour des bouts de code, c'est la commande suivante (sans honte) :Enfin et j'arrête là mon lirisme : pour moi, un développeur contemporain, c'est - au moins - Python + Rust + Common LISP.
* Python par sa grande popularité, sa présence quasi par défaut dans les environnement Linux, sa souplesse et sa rapidité à concevoir des traitements, la clarté du code et sa puissance / richesse dans le traitement moderne des données (via Jupyter ou autre) ;
* Rust car il produit un code compilé ainsi que les qualités évoquées plus haut ;
* Common LISP (je pense notamment à l'implémentation SBCL), parce que c'est LISP, parce que c'est normalisé, parce que tu prends un claque quand tu comprends le vrai sens de "macro", parce que c'est la puissance grammaticale, la facilité de résolution des AST et la beauté des lambdas. Bref CL lorsque tu dois aller vers des aspects de programmation que les deux autres langages ne supportent pas ou mal. Et d'ailleurs que parfois, seul CL supporte (plus de possibilités que Scheme, même si le débat est ouvert à ce propos).
Bref je pourrais passer des heures, j'adore ça et si je peux aider, ce sera avec plaisir :)