Je suis d'accord qu'il faudrait utiliser des langages plus sûrs (je l'ai déjà dit : je considère par exemple que MISRA C est le parfait exemple que le C n'est pas un bon langage pour faire de l'embarqué critique), mais :

Lionel Debroux (./1380) :
Rust et Go ne pourront avoir aucune chance avec un logiciel de pensée obsolète "mais il ne faut pas que ça bouge pendant des mois" alors qu'il y a une nouvelle release majeure toutes les quelques semaines

Ce n'est pas un modèle de pensée obsolète, c'est une réalité. Quand tu développes un projet sérieux, la phase de réflexion et de planification peut être longue. Tu ne peux pas t'amuser à tout remettre en chantier à chaque fois qu'une dépendance évolue, sinon ton projet ne sortira jamais.

Tu m'objecteras probablement le "release early, release often" et autres "move fast and break things", mais les projets qui utilisent ce genre de philosophies peuvent se permettre de sortir des MVP et d'avoir des régressions en production. C'est un critère éliminatoire pour tout projet qui a un minimum de criticité. Si je voulais être mauvaise langue, j'ajouterais que les résultats sont souvent médiocres, aussi bien en matière de qualité logicielle qu'en terme de qualité pour l'utilisateur.

Si Rust et Go veulent percer dans ces milieux, il faudra qu'ils arrivent à être matures et stables, il n'y a pas d'autres solutions. Ça ne veut pas dire qu'il ne doit pas y avoir de correction des bugs liés à la sécurité bien sûr, mais qu'il n'est pas question de changer des trucs fondamentaux d'une release à l'autre.

Trop souvent, "on veut garder la liberté de faire des évolutions majeures n'importe quand pour améliorer" est une excuse pour ne pas avouer "on n'a pas réfléchi à la conception, on navigue à vue et on verra ce que ça donne".