Là c'est comme si le constat de départ dans les années 50 étaient les programmeurs ne comprennent rien à l'informatique :-)
Le constat de départ c'est que le parallélisme c'est un sujet compliqué sujet à de nombreuses erreurs.
S'assurer qu'on a de bonnes perfs en parallélisant des tâches ou actions tout en ayant aucun effet de bord c'est une gymnastique intellectuelle difficile surtout quand tu ne connais pas le logiciel dans son intégralité car il est trop gros. Un effet de bord est vite arrivé.
Il faut être très rigoureux, tu as vite oublié la protection mémoire quelque part qui va bien et du coup tu as un conflit d'accès à la donnée, ou utilisé la protection mémoire au mauvais endroit et du coup tu as un interblocage.
Même quand tu es formé à la question ces erreurs arrivent car on ne peut pas penser à tout tout le temps. Comme la gestion de la mémoire d'ailleurs, s'assurer que tout est alloué une fois au bon endroit à la bonne taille et la mémoire libérée une fois au bon endroit de manière systématique c'est aussi difficile. Même des développeurs expérimentés et formés t'introduisent des failles de sécurité car la mémoire est mal gérée ou des crashs car mince la libération de la mémoire n'a pas été faite au bon endroit (ou un accès a été fait là où il ne fallait pas).
Et en plus manque de bol avec le parallélisme, le débogage est difficile quand un problème survient. Bogues difficiles à identifier, à reproduire, lire le code pour identifier le problème est rarement suffisant, etc. Donc quand ça arrive tu perds un temps fou dessus.
Bref, si un langage avec un compilateur permet de dire "ici ça pue, bogues potentiels à venir, corrige ou marque ce bout de code comme "je sais ce que je fais"" cela simplifie grandement la tâche, en particulier pour les gens formés qui pourront se concentrer sur l'architecture plutôt que de reproduire des bogues compliqués.
[^] # Re: La source
Posté par Renault (site web personnel) . En réponse au lien Linus au sommet de la Fondation Linux « Rust fait sens d’un point de vue technique ». Évalué à 10.
Le constat de départ c'est que le parallélisme c'est un sujet compliqué sujet à de nombreuses erreurs.
S'assurer qu'on a de bonnes perfs en parallélisant des tâches ou actions tout en ayant aucun effet de bord c'est une gymnastique intellectuelle difficile surtout quand tu ne connais pas le logiciel dans son intégralité car il est trop gros. Un effet de bord est vite arrivé.
Il faut être très rigoureux, tu as vite oublié la protection mémoire quelque part qui va bien et du coup tu as un conflit d'accès à la donnée, ou utilisé la protection mémoire au mauvais endroit et du coup tu as un interblocage.
Même quand tu es formé à la question ces erreurs arrivent car on ne peut pas penser à tout tout le temps. Comme la gestion de la mémoire d'ailleurs, s'assurer que tout est alloué une fois au bon endroit à la bonne taille et la mémoire libérée une fois au bon endroit de manière systématique c'est aussi difficile. Même des développeurs expérimentés et formés t'introduisent des failles de sécurité car la mémoire est mal gérée ou des crashs car mince la libération de la mémoire n'a pas été faite au bon endroit (ou un accès a été fait là où il ne fallait pas).
Et en plus manque de bol avec le parallélisme, le débogage est difficile quand un problème survient. Bogues difficiles à identifier, à reproduire, lire le code pour identifier le problème est rarement suffisant, etc. Donc quand ça arrive tu perds un temps fou dessus.
Bref, si un langage avec un compilateur permet de dire "ici ça pue, bogues potentiels à venir, corrige ou marque ce bout de code comme "je sais ce que je fais"" cela simplifie grandement la tâche, en particulier pour les gens formés qui pourront se concentrer sur l'architecture plutôt que de reproduire des bogues compliqués.