Arrêtez moi si je dis une connerie mais je crois bien que Rust est intrinsèquement conçu depuis le début pour, entre autres, intégrer de la sûreté poussée dans son type system relativement au multithreading. Bien meilleure que le C++, ça va sans dire (le C++ même le plus moderne ne propose jamais de sûreté garantie ou au pire d'identifier explicitement de manière obligatoire les sections de code potentiellement dangereuses, la moindre "mauvaise" utilisation de tout truc ressemblant conceptuellement à une référence engendrera potentiellement un UB, la plupart du temps sans aucune détection statique, et ça inclut par ex les string_view tout neufs)
Et en pratique, dès que vous avez 2 threads (pour de la concurrence) dans un programme non trivial qui ne propose pas de garantie sur ce point, vous avez des tonnes de data races (sauf théoriquement s'il a été écrit intégralement par des experts de ce domaine, mais cette théorie ne se réalise pas en vrai, de plus ce type de raisonnement permettrait de conclure qu'on peut concevoir n'importe quoi parfaitement avec n'importe quel langage de merde et sans aucune analyse statique automatique, donc étant donné qu'on n'est plus en 1950 je considère que cette approche n'est plus pertinente)
[^] # Re: Rust et SIMD
Posté par Guillaume Knispel . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 8.
Arrêtez moi si je dis une connerie mais je crois bien que Rust est intrinsèquement conçu depuis le début pour, entre autres, intégrer de la sûreté poussée dans son type system relativement au multithreading. Bien meilleure que le C++, ça va sans dire (le C++ même le plus moderne ne propose jamais de sûreté garantie ou au pire d'identifier explicitement de manière obligatoire les sections de code potentiellement dangereuses, la moindre "mauvaise" utilisation de tout truc ressemblant conceptuellement à une référence engendrera potentiellement un UB, la plupart du temps sans aucune détection statique, et ça inclut par ex les string_view tout neufs)
Et en pratique, dès que vous avez 2 threads (pour de la concurrence) dans un programme non trivial qui ne propose pas de garantie sur ce point, vous avez des tonnes de data races (sauf théoriquement s'il a été écrit intégralement par des experts de ce domaine, mais cette théorie ne se réalise pas en vrai, de plus ce type de raisonnement permettrait de conclure qu'on peut concevoir n'importe quoi parfaitement avec n'importe quel langage de merde et sans aucune analyse statique automatique, donc étant donné qu'on n'est plus en 1950 je considère que cette approche n'est plus pertinente)