C'est vrai que ça peut paraître plus facile dans d'autre langages, mais cette facilité à un coût :
- La prédictibilité des performances pour les langages full GC comme Java, Go, ...
Tu as tout à fait raison.
Juste pour que ce soit dit, souvent quand le GC fait chier en Java, on l'évite tout simplement en sortant de la heap pour les structures de données ou ca fait un sens. C'est dégueux mais ca fait la moitié du job (l'autre moitié étant le garbage à courte vie créé un peu partout qui reste en young generation et qui rend les perfs en low latency dégueux même en faisant gaffe...).
L'approche de Rust est meilleure il n'y a pas photo. Si tu peux garder la facilité d'un GC et son adéquation avec des programmes parallèles, tout en réduisant de quelques centaines de MB/s ce que tu balances inutillement dans la face du GC c'est top.
[^] # Re: Et go ?
Posté par ckyl . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 4.
Tu as tout à fait raison.
Juste pour que ce soit dit, souvent quand le GC fait chier en Java, on l'évite tout simplement en sortant de la heap pour les structures de données ou ca fait un sens. C'est dégueux mais ca fait la moitié du job (l'autre moitié étant le garbage à courte vie créé un peu partout qui reste en young generation et qui rend les perfs en low latency dégueux même en faisant gaffe...).
L'approche de Rust est meilleure il n'y a pas photo. Si tu peux garder la facilité d'un GC et son adéquation avec des programmes parallèles, tout en réduisant de quelques centaines de MB/s ce que tu balances inutillement dans la face du GC c'est top.