Et au-delà de la sécurité, c'est un problème plus général de qualité logicielle qui se pose.
La qualité logiciel n'a rien à voir avec le langage ni le memory management. Un mauvais programmeur fera un mauvais programme, quel que soit le langage.
Rust est tellement jeune (et, pour l'instant, peu utilisé) que l'on n'a pas de recul sur les problèmes des applications écrites en Rust.
La gestion mémoire de Rust n'a rien de jeune. Elle vient des techniques de RAII de C++, Ada our Vala qui ont plus de 10 ans.
La seule "nouveauté" de Rust, est de les rendre obligatoire par défaut.
Les problèmes du C ne se limitent certes pas à la gestion manuelle de la mémoire. Mais la gestion manuelle de la mémoire fait cependant partie de ses problèmes, et la complexité de la tâche (sur des applications non-triviales) fait que c'est un facteur important de défauts.
Encore une fois, c'est un problème associé au design du langage, et pas à l'absence de GC. Le C pure rend trés difficile, voir impossible la mise en place de technique de RAII car il ne gère pas la notion de "scope", contrairement à C++, Rust, Ada, Objective-C, Swift, etc....
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 3. Dernière modification le 11 mai 2016 à 10:44.
La qualité logiciel n'a rien à voir avec le langage ni le memory management. Un mauvais programmeur fera un mauvais programme, quel que soit le langage.
La gestion mémoire de Rust n'a rien de jeune. Elle vient des techniques de RAII de C++, Ada our Vala qui ont plus de 10 ans.
La seule "nouveauté" de Rust, est de les rendre obligatoire par défaut.
Encore une fois, c'est un problème associé au design du langage, et pas à l'absence de GC. Le C pure rend trés difficile, voir impossible la mise en place de technique de RAII car il ne gère pas la notion de "scope", contrairement à C++, Rust, Ada, Objective-C, Swift, etc....