Merci mais je ne vois pas ce que les GC viennent faire ici. Le but d'un GC, c'est principalement d'apporter de la simplicité, pas forcément de la memory-safety.
Vu qu'on se sert principalement de langages à GC pour faire des services Web par exemple (Java/Python/PHP/Go...) et que la sécurité y est un élément important je dirai qu'on embrasse les différentes qualités qu'apporte un GC en général (même si les développeurs ne s'en rendent pas compte car ce sont des problèmes bas niveau). En fait la simplicité vient justement en partie du fait que des problèmes de memory safety n'existent pas. Donc la simplicité ce n'est pas seulement qu'on n'a pas besoin d'appeler free().
ça ne vaccine pas des refontes pour corriger des problèmes mémoires
Reste que ce n'est pas parce que ce n'est pas une solution miracle qui garantit qu'il n'y aura jamais besoin de "refontes pour corriger des problèmes mémoires" que ça ne veut pas dire que ça ne fait pas mieux que les autres langages (par exemple en faisant que ce genre de refonte est rare—rappelons que l'on parle d'un noyau qui est plus complexe qu'un programme lambda—nul miracle certes, mais un progrès quand même).
Comme je l'ai dit précédemment tu as des avantages des langages à GC (sécurité mémoire + on ne se préoccupe que rarement de libérer la mémoire à la main) mais sans le coup à l'exécution d'un GC (comme dans les langages à gestion manuelle de la mémoire). Oui c'est moins sympa que l'image "ça corrige tous les problèmes mémoire" (ce qu'aucun langage même lent et haut niveau ne peut faire), mais c'est déjà pas mal.
[^] # Re: Des fuites mémoires en Rust ?
Posté par GuieA_7 (site web personnel) . En réponse au journal Sortie de Redox OS 0.6.0. Évalué à 5.
Vu qu'on se sert principalement de langages à GC pour faire des services Web par exemple (Java/Python/PHP/Go...) et que la sécurité y est un élément important je dirai qu'on embrasse les différentes qualités qu'apporte un GC en général (même si les développeurs ne s'en rendent pas compte car ce sont des problèmes bas niveau). En fait la simplicité vient justement en partie du fait que des problèmes de memory safety n'existent pas. Donc la simplicité ce n'est pas seulement qu'on n'a pas besoin d'appeler
free().En ce qui me concerne j'ai déjà corrigé ici-même des gens qui disaient que Rust empêchaient toutes sortes de fuite mémoire. Ici par exemple, dans une dépêche Rust: https://linuxfr.org/news/rust-a-5-ans-retrospective#comment-1823413
Reste que ce n'est pas parce que ce n'est pas une solution miracle qui garantit qu'il n'y aura jamais besoin de "refontes pour corriger des problèmes mémoires" que ça ne veut pas dire que ça ne fait pas mieux que les autres langages (par exemple en faisant que ce genre de refonte est rare—rappelons que l'on parle d'un noyau qui est plus complexe qu'un programme lambda—nul miracle certes, mais un progrès quand même).
Comme je l'ai dit précédemment tu as des avantages des langages à GC (sécurité mémoire + on ne se préoccupe que rarement de libérer la mémoire à la main) mais sans le coup à l'exécution d'un GC (comme dans les langages à gestion manuelle de la mémoire). Oui c'est moins sympa que l'image "ça corrige tous les problèmes mémoire" (ce qu'aucun langage même lent et haut niveau ne peut faire), mais c'est déjà pas mal.