Je ne l'avais pas posté puisque cet article consensuel n'a suscité aucune réaction dans la communauté Go
La communauté Go abrite moins de curieux et passionnés des langages que la communauté Rust, donc ce genre d'articles reçoit moins d'intérêt, surtout vu leur caractère répétitif.
L'article est peut-être consensuel, mais globalement résume l'essentiel. En d'autres termes, bien que parfois les deux peuvent s'appliquer, il n'y a pas de compétition significative entre Rust et Go en pratique. Les articles non consensuels sur le sujet ont souvent tendance à se démener à propos de détails sortis de contexte sans en évaluer l'impact réel en pratique.
Pour ce qui est de la généricité, pas mal de monde est d'accord qu'il existe un certain pourcentage d'applications (peut-être autour de 10% ou 20% ?) qui en bénéficieraient suffisamment pour que ça vaille la peine. Ça concerne suffisamment de monde pour que les développeurs aient décidé d'ajouter ça d'ici une ou deux versions, mais pas assez de monde pour qu'ils l'aient fait dès le départ ni pour qu'ils ajoutent une généricité aussi puissante et complexe que dans d'autres langages.
Dans la plupart des applications, les mécanismes déjà présents de réutilisation (interfaces), suffisent. Pas étonnant qu'un certain nombre de programmeurs Go ne soit pas très excité et n'y voit pas de quoi en faire un fromage. Pour ce type de programmeur Go, qu'on lui dise que son langage est pas bien, car il est pas assez générique (ou autre), ça va le surprendre, il va pas savoir quoi dire. Ça doit se ressentir un peu comme si on te reproche de ne pas automatiser complètement l'installation de ta distrib sur tes machines chez toi; tu répondras que ça va, tu fais pas ça souvent, donc t'as pas envie de te casser la tête et tu le fais deux fois (je parie que même des sysadmins ne prennent pas toujours la peine d'automatiser chez eux ce genre de choses).
Comme pour toute fonctionnalité, chacun a tendance à en évaluer l'intérêt du point de vue des choses qu'il fait, puis attacher des émotions par dessus ça, puis se sentir obligé de les justifier dans l'abstrait. Ça a beau être très consensuel et banal comme explication, je trouve honnêtement que c'est surtout ça qui génère tous ces articles Go vs Rust.
[^] # Re: Ouaiche
Posté par anaseto . En réponse au lien "Rust vs. Go: Why They’re Better Together". Évalué à 4.
La communauté Go abrite moins de curieux et passionnés des langages que la communauté Rust, donc ce genre d'articles reçoit moins d'intérêt, surtout vu leur caractère répétitif.
L'article est peut-être consensuel, mais globalement résume l'essentiel. En d'autres termes, bien que parfois les deux peuvent s'appliquer, il n'y a pas de compétition significative entre Rust et Go en pratique. Les articles non consensuels sur le sujet ont souvent tendance à se démener à propos de détails sortis de contexte sans en évaluer l'impact réel en pratique.
Pour ce qui est de la généricité, pas mal de monde est d'accord qu'il existe un certain pourcentage d'applications (peut-être autour de 10% ou 20% ?) qui en bénéficieraient suffisamment pour que ça vaille la peine. Ça concerne suffisamment de monde pour que les développeurs aient décidé d'ajouter ça d'ici une ou deux versions, mais pas assez de monde pour qu'ils l'aient fait dès le départ ni pour qu'ils ajoutent une généricité aussi puissante et complexe que dans d'autres langages.
Dans la plupart des applications, les mécanismes déjà présents de réutilisation (interfaces), suffisent. Pas étonnant qu'un certain nombre de programmeurs Go ne soit pas très excité et n'y voit pas de quoi en faire un fromage. Pour ce type de programmeur Go, qu'on lui dise que son langage est pas bien, car il est pas assez générique (ou autre), ça va le surprendre, il va pas savoir quoi dire. Ça doit se ressentir un peu comme si on te reproche de ne pas automatiser complètement l'installation de ta distrib sur tes machines chez toi; tu répondras que ça va, tu fais pas ça souvent, donc t'as pas envie de te casser la tête et tu le fais deux fois (je parie que même des sysadmins ne prennent pas toujours la peine d'automatiser chez eux ce genre de choses).
Comme pour toute fonctionnalité, chacun a tendance à en évaluer l'intérêt du point de vue des choses qu'il fait, puis attacher des émotions par dessus ça, puis se sentir obligé de les justifier dans l'abstrait. Ça a beau être très consensuel et banal comme explication, je trouve honnêtement que c'est surtout ça qui génère tous ces articles Go vs Rust.