Moi je remarque surtout que des langages massivement plus lents que ça sont lourdement utilisés en production (Javascript, Ruby, PHP, Python, etc.), et que les programmes sans gestion automatique de la mémoire sont truffés de faille de sécurité béantes qui nous poussent être mettre à jour nos systèmes à la va-vite chaque semaine. (Oui, on peut faire du code plus sûr en C++ ou Rust (ou même en C macroté) en utilisant du refcounting, mais ça a aussi un coût en performance pas forcément négligeable.)
Il paraît qu'il reste des domaines applicatifs où les temps de pause des GCs incrémentaux sont inacceptables (enfin bon Azul a montré qu'avec assez d'argent investi dans le problème on peut aller très loin), et tant pis pour eux. Mais sinon tirer en permanence la sonnette d'alarme sur les performances du GC c'est un peu dangereux à mon avis, quand ça pousse les gens à faire des choix techniques qui leurs coûtent au final beaucoup plus cher, en terme de débug ou de failles de sécurité.
(On va dire que Rust avec ses lifetime c'est magnifique etc. Je pense qu'on n'a pas encore l'expérience pour voir si le code Rust est en pratique plutôt sûr, ou aussi un nid à failles comme C. Le langage fait des bons choix dans la direction de la sûreté, mais une communauté trop portée sur le "unsafe" pourrait faire pencher la balance de l'autre côté, et dans une certaine mesure c'est en train d'arriver. C'est lié aussi au fait que garder statiquement des garanties fortes sur l'ownership c'est en fait assez difficile en dehors des cas simples, quand il y a du partage plus riche, ce qui pousse les gens à faire soit du reference counting (mais les performances, etc.) soit du unsafe.)
[^] # Re: Destructeurs
Posté par gasche . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 10.
Moi je remarque surtout que des langages massivement plus lents que ça sont lourdement utilisés en production (Javascript, Ruby, PHP, Python, etc.), et que les programmes sans gestion automatique de la mémoire sont truffés de faille de sécurité béantes qui nous poussent être mettre à jour nos systèmes à la va-vite chaque semaine. (Oui, on peut faire du code plus sûr en C++ ou Rust (ou même en C macroté) en utilisant du refcounting, mais ça a aussi un coût en performance pas forcément négligeable.)
Il paraît qu'il reste des domaines applicatifs où les temps de pause des GCs incrémentaux sont inacceptables (enfin bon Azul a montré qu'avec assez d'argent investi dans le problème on peut aller très loin), et tant pis pour eux. Mais sinon tirer en permanence la sonnette d'alarme sur les performances du GC c'est un peu dangereux à mon avis, quand ça pousse les gens à faire des choix techniques qui leurs coûtent au final beaucoup plus cher, en terme de débug ou de failles de sécurité.
(On va dire que Rust avec ses lifetime c'est magnifique etc. Je pense qu'on n'a pas encore l'expérience pour voir si le code Rust est en pratique plutôt sûr, ou aussi un nid à failles comme C. Le langage fait des bons choix dans la direction de la sûreté, mais une communauté trop portée sur le "unsafe" pourrait faire pencher la balance de l'autre côté, et dans une certaine mesure c'est en train d'arriver. C'est lié aussi au fait que garder statiquement des garanties fortes sur l'ownership c'est en fait assez difficile en dehors des cas simples, quand il y a du partage plus riche, ce qui pousse les gens à faire soit du reference counting (mais les performances, etc.) soit du unsafe.)