Avoir une garantie de sûreté d'un code threadé avec Rust est un leurre puissant mais qui, au fond, ne sert pas à grand chose. Parce que personne ne devrait lancer un thread directement, tout le monde devrait utiliser un modèle de programmation parallèle. Par exemple, en Go, il y a un modèle de programmation parallèle, certes vieux, certes plein de limites, mais qui fonctionnent et offre des garanties sans avoir à manipuler le moindre thread. Autre exemple, MapReduce qui est un modèle de programmation parallèle (qui ne résout pas tous les problèmes, mais if non plus ne résout pas tous les problèmes séquentiels) où l'utilisateur final n'a pas à se soucie de l'ordonnancement, ça marche. On pourrait aussi parler des futures, du vol de travail, ou de tout un tas d'autres modèles déjà existants et éprouvés et dont on sait comment ça se programme correctement avec des threads.
Le seul qui doit faire attention, c'est celui qui va implémenter le modèle de programmation parallèle par dessus les threads, mais a priori lui il sait ce qu'il fait, il peut tout vérifier de son côté (soit directement, soit à l'aide d'un outil, soit parce que comme Rust le compilateur va lui dire que c'est bon). Mais ça fait quand même peu de monde qui a une réelle utilité de cet outil de mon point de vue.
[^] # Re: Rust et SIMD
Posté par rewind (Mastodon) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à -4.
Avoir une garantie de sûreté d'un code threadé avec Rust est un leurre puissant mais qui, au fond, ne sert pas à grand chose. Parce que personne ne devrait lancer un thread directement, tout le monde devrait utiliser un modèle de programmation parallèle. Par exemple, en Go, il y a un modèle de programmation parallèle, certes vieux, certes plein de limites, mais qui fonctionnent et offre des garanties sans avoir à manipuler le moindre thread. Autre exemple, MapReduce qui est un modèle de programmation parallèle (qui ne résout pas tous les problèmes, mais if non plus ne résout pas tous les problèmes séquentiels) où l'utilisateur final n'a pas à se soucie de l'ordonnancement, ça marche. On pourrait aussi parler des futures, du vol de travail, ou de tout un tas d'autres modèles déjà existants et éprouvés et dont on sait comment ça se programme correctement avec des threads.
Le seul qui doit faire attention, c'est celui qui va implémenter le modèle de programmation parallèle par dessus les threads, mais a priori lui il sait ce qu'il fait, il peut tout vérifier de son côté (soit directement, soit à l'aide d'un outil, soit parce que comme Rust le compilateur va lui dire que c'est bon). Mais ça fait quand même peu de monde qui a une réelle utilité de cet outil de mon point de vue.