Ce que tu oublies dans cette belle histoire c'est que les GCs peuvent parfois être justifiés pour des raisons de performance. Concrètement entre un système à GC et un système à reference counting, les GCs (bien codés) sont plus performants en général pour les workflows où tu alloues pas mal, car les incrémentations/décrémentations du refcounting coûtent beaucoup. Donc une des raisons d'utiliser un GC plutôt que du refcounting (automatisé ou manuel) est d'avoir un meilleur throughput.
Alors oui, quand tu veux un GC sans pauses (ou une solution de gestion de mémoire sans pauses), tu utilises des algorithmes différents, qui font des compromis différents, et qui rendent les applications moins performantes globalement (qu'un GC qui s'autorise des pauses dans certains cas). Il faut choisir ce qu'on veut optimiser, et je comprends très bien que dans certains domaines applicatifs ce soit un meilleur compromis; typiquement tout ce qui est interface utilisateur, où la réactivité importe plus que la rapidité dans l'absolu.
Mais là tu veux le beurre et l'argent du beurre. Tu me dis "on ne peut pas avoir de pauses donc on fait du refcounting", et ensuite "on est vachement limité sur le temps de calcul donc on ne peut pas se permettre un GC". C'est beau d'être en symbiose avec une couche technologique comme tu l'es, mais il ne faut pas que ça te masque la réalité : tous les choix ont leurs avantages et inconvénients, et si de nombreux langages choisissent d'utiliser un GC plutôt que du refcounting, c'est parce que c'est une meilleure approche dans de nombreux cas; ARC n'est pas une technologie magique qui résoud tous les problèmes.
[^] # Re: pour moi
Posté par gasche . En réponse au journal Votre langage idéal ?. Évalué à 2.
Ce que tu oublies dans cette belle histoire c'est que les GCs peuvent parfois être justifiés pour des raisons de performance. Concrètement entre un système à GC et un système à reference counting, les GCs (bien codés) sont plus performants en général pour les workflows où tu alloues pas mal, car les incrémentations/décrémentations du refcounting coûtent beaucoup. Donc une des raisons d'utiliser un GC plutôt que du refcounting (automatisé ou manuel) est d'avoir un meilleur throughput.
Alors oui, quand tu veux un GC sans pauses (ou une solution de gestion de mémoire sans pauses), tu utilises des algorithmes différents, qui font des compromis différents, et qui rendent les applications moins performantes globalement (qu'un GC qui s'autorise des pauses dans certains cas). Il faut choisir ce qu'on veut optimiser, et je comprends très bien que dans certains domaines applicatifs ce soit un meilleur compromis; typiquement tout ce qui est interface utilisateur, où la réactivité importe plus que la rapidité dans l'absolu.
Mais là tu veux le beurre et l'argent du beurre. Tu me dis "on ne peut pas avoir de pauses donc on fait du refcounting", et ensuite "on est vachement limité sur le temps de calcul donc on ne peut pas se permettre un GC". C'est beau d'être en symbiose avec une couche technologique comme tu l'es, mais il ne faut pas que ça te masque la réalité : tous les choix ont leurs avantages et inconvénients, et si de nombreux langages choisissent d'utiliser un GC plutôt que du refcounting, c'est parce que c'est une meilleure approche dans de nombreux cas; ARC n'est pas une technologie magique qui résoud tous les problèmes.