Non, ce que j'appelle défaut, c'est un bug, une fuite mémoire, un crash, un trou de sécu, etc.
Tu fais une analogie clairement abusive entre gestion manuelle et bug.
Ma condescendance répond au complexe de supériorité des gens qui pensent que les défauts de gestion mémoire sont forcément dus à l'intervention d'un "mauvais programmeur"...
Tu pars dans un délire paranoïaque. Personne n'a dit que la gestion manuelle de mémoire, c'était le paradis et la facilité et que tous les bugs étaient dû à des mauvais programmeur. Le but de ce fil, c'est juste de dire qu'un GC a un coût en terme de performance, de latence et que ce coût est inacceptable dans beaucoup de domaines.
Postuler des turpitudes individuelles comme cause de tous les problèmes empêche de prendre conscience des effets de système.
D'un autre côté, accuser l'effet de système permet d'exonérer certains programmeurs des mauvaises pratiques connues depuis des décennies qui mènent à des catastrophes. Parce que la solution au «problème», ce n'est pas de dire que tout le monde passe à un langage à GC, c'est d'appliquer les bonnes pratiques, de trouver des pattern d'allocation qui rendent cette tâche simple et sûre. Croire qu'un GC est la solution ultime à tous les problèmes de gestion mémoire, c'est se tromper lourdement.
La proportion d'applications où un GC est hors de question est appelée à diminuer. Comme le rappelle un intervenant, un téléphone "intelligent" aujourd'hui est suffisamment puissant pour faire tourner une JVM entière.
Les domaines pour lesquels un GC est inenvisageable à l'heure actuelle ne risque pas de diminuer parce que, pour la plupart, ce sont des domaines où les performances et/ou la latence sont primordiales et donc, on en revient à ce qu'on disait au début.
[^] # Re: Destructeurs
Posté par rewind (Mastodon) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3.
Tu fais une analogie clairement abusive entre gestion manuelle et bug.
Tu pars dans un délire paranoïaque. Personne n'a dit que la gestion manuelle de mémoire, c'était le paradis et la facilité et que tous les bugs étaient dû à des mauvais programmeur. Le but de ce fil, c'est juste de dire qu'un GC a un coût en terme de performance, de latence et que ce coût est inacceptable dans beaucoup de domaines.
D'un autre côté, accuser l'effet de système permet d'exonérer certains programmeurs des mauvaises pratiques connues depuis des décennies qui mènent à des catastrophes. Parce que la solution au «problème», ce n'est pas de dire que tout le monde passe à un langage à GC, c'est d'appliquer les bonnes pratiques, de trouver des pattern d'allocation qui rendent cette tâche simple et sûre. Croire qu'un GC est la solution ultime à tous les problèmes de gestion mémoire, c'est se tromper lourdement.
Les domaines pour lesquels un GC est inenvisageable à l'heure actuelle ne risque pas de diminuer parce que, pour la plupart, ce sont des domaines où les performances et/ou la latence sont primordiales et donc, on en revient à ce qu'on disait au début.