Mon mauvais, dans mon souvenir "Is coding in Rust as bad as in C++?" était le sous-titre et "A practical comparison of build and test speed between C++ and Rust." le titre, alors que c'est l'inverse. Et comme l'URL https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ parle des temps de compilation et que d'ordinaire elle est créée d'après le titre, je n'ai pas pensé à vérifier.
Voilà pourquoi hier j'ai abandonné C++ pour Java et pourquoi aujourd'hui je préfère Go à Rust et : je ne veux pas mourir de vieillesse en attendant que ça compile.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Posté par xoddark .
Évalué à 9.
Dernière modification le 09 janvier 2023 à 11:27.
Contexte: Je n'ai pas lu l'article en question, par contre je suis programmeur C++ expérimenté et je me forme actuellement à Rust. Mon expérience Rust se concentre pour l'instant sur des projets assez petit.
De mon point de vue l’inconvénient des temps de compilation en Rust est largement compensé par un nombre d'itération beaucoup moins important.
L'étape qui est longue c'est la génération de code, par contre le checker qui est indépendant et qui s'occupe de détecter et signaler les erreurs de programmation (enfin la validité du code écrit) est utilisable indépendamment et est rapide.
Du coup quand tu passes à l'étape compilation (ou il faut attendre) la qualité du code est bien meilleur, et il reste beaucoup moins de bug qui nécessiteront d'itérer.
En prenant en compte que le temps d'itération n'est pas uniquement lié au temps de compilation, mais aussi au temps pour retrouver l'état du programme adapté pour tester (du temps pour charger des ressources, pour faire une suite de manipulation, etc …
Ça va beaucoup dépendre du type de programme, mais pour ceux qui demandent une mise au point progressive (exemple: ajuster le gameplay d'un jeu, chercher comment améliorer une IHM, régler un algo d'IA…), on fait souvent une boucle modif->compile->test.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
C'est justement ce dont je voulais parler dans mon deuxième point, le temps de compilation n'est qu'une partie du temps d'itération.
Et donc dans ce cas, le mieux est encore de pouvoir itérer sans recompiler et sans relancer. Par exemple en changeant l'état de variable au runtime. Bien sur ce n'est pas toujours possible, mais ça permet de bien diminuer l'impact du temps de compilation.
Enfin la critique n'est pas vraiment contre le langage mais contre la compilation des langages optimisés. Etant les seuls utilisables la ou les ressources sont critiques (embarqué, OS, Jeux performants, et logiciels exigeants) il n'y a pas le choix.
Le temps perdu à la compilation est largement récupéré à l'exécution à condition de l'exécuter plusieurs fois…
On pourrait tout de même imaginer un mode de compilation "just in time" ou pas qui permette de l'exécuter comme un langage interprété en dev et compilé en prod. Il y a eu des tentatives je crois mais pas de réel mise en place à ma connaissances (https://stackoverflow.com/questions/56177318/is-there-a-rust-interpreter : MIRI?).
Le Go est certes un bon compromis sur ce point.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Sous-titre
Posté par cg . Évalué à 8. Dernière modification le 08 janvier 2023 à 17:20.
Le sous-titre de l'article : A practical comparison of build and test speed between C++ and Rust
C'est d'un intérêt très limité en terme de programmation (coding)…
[^] # Re: Sous-titre
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 1.
C'est un ènième exemple de pourquoi il faudrait éviter de récrire les titres des liens partagés.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Sous-titre
Posté par tisaac (Mastodon) . Évalué à 10.
Enfin, pour le coup, je n'ai pas réécrit le titre du lien partagé.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Sous-titre
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
Mon mauvais, dans mon souvenir "Is coding in Rust as bad as in C++?" était le sous-titre et "A practical comparison of build and test speed between C++ and Rust." le titre, alors que c'est l'inverse. Et comme l'URL https://quick-lint-js.com/blog/cpp-vs-rust-build-times/ parle des temps de compilation et que d'ordinaire elle est créée d'après le titre, je n'ai pas pensé à vérifier.
La connaissance libre : https://zestedesavoir.com
# Le go n'est pas lent
Posté par devnewton 🍺 (site web personnel) . Évalué à 3. Dernière modification le 08 janvier 2023 à 20:29.
Voilà pourquoi hier j'ai abandonné C++ pour Java et pourquoi aujourd'hui je préfère Go à Rust et : je ne veux pas mourir de vieillesse en attendant que ça compile.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le go n'est pas lent
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
devnewton attendant que Rust finisse de compiler ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Le go n'est pas lent
Posté par claudex . Évalué à 3.
Tu préfère mourir de vieillesse en copiant-collant du code ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le go n'est pas lent
Posté par xoddark . Évalué à 9. Dernière modification le 09 janvier 2023 à 11:27.
Contexte: Je n'ai pas lu l'article en question, par contre je suis programmeur C++ expérimenté et je me forme actuellement à Rust. Mon expérience Rust se concentre pour l'instant sur des projets assez petit.
De mon point de vue l’inconvénient des temps de compilation en Rust est largement compensé par un nombre d'itération beaucoup moins important.
L'étape qui est longue c'est la génération de code, par contre le checker qui est indépendant et qui s'occupe de détecter et signaler les erreurs de programmation (enfin la validité du code écrit) est utilisable indépendamment et est rapide.
Du coup quand tu passes à l'étape compilation (ou il faut attendre) la qualité du code est bien meilleur, et il reste beaucoup moins de bug qui nécessiteront d'itérer.
En prenant en compte que le temps d'itération n'est pas uniquement lié au temps de compilation, mais aussi au temps pour retrouver l'état du programme adapté pour tester (du temps pour charger des ressources, pour faire une suite de manipulation, etc …
[^] # Re: Le go n'est pas lent
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Ça va beaucoup dépendre du type de programme, mais pour ceux qui demandent une mise au point progressive (exemple: ajuster le gameplay d'un jeu, chercher comment améliorer une IHM, régler un algo d'IA…), on fait souvent une boucle modif->compile->test.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le go n'est pas lent
Posté par xoddark . Évalué à 2.
C'est justement ce dont je voulais parler dans mon deuxième point, le temps de compilation n'est qu'une partie du temps d'itération.
Et donc dans ce cas, le mieux est encore de pouvoir itérer sans recompiler et sans relancer. Par exemple en changeant l'état de variable au runtime. Bien sur ce n'est pas toujours possible, mais ça permet de bien diminuer l'impact du temps de compilation.
[^] # Re: Le go n'est pas lent
Posté par nico4nicolas . Évalué à 2.
Ca ira toujours plus vite à compiler que le Python !
# Compilation VS runtime
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 09 janvier 2023 à 13:35.
Enfin la critique n'est pas vraiment contre le langage mais contre la compilation des langages optimisés. Etant les seuls utilisables la ou les ressources sont critiques (embarqué, OS, Jeux performants, et logiciels exigeants) il n'y a pas le choix.
Le temps perdu à la compilation est largement récupéré à l'exécution à condition de l'exécuter plusieurs fois…
On pourrait tout de même imaginer un mode de compilation "just in time" ou pas qui permette de l'exécuter comme un langage interprété en dev et compilé en prod. Il y a eu des tentatives je crois mais pas de réel mise en place à ma connaissances (https://stackoverflow.com/questions/56177318/is-there-a-rust-interpreter : MIRI?).
Le Go est certes un bon compromis sur ce point.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.