Rust n’est peut-être pas l’outil adapté aux logiciels en espace utilisateur à très grande concurrence

• Cet article examine les défis liés à l’utilisation de Rust pour des logiciels en espace utilisateur avec une très forte concurrence.
• Le modèle asynchrone de Rust est conçu pour gérer deux concepts clés de l’informatique moderne : la concurrence et le parallélisme.
  • Le parallélisme consiste à exécuter du code simultanément sur plusieurs CPU.
  • La concurrence consiste à décomposer un problème en parties indépendantes pouvant s’exécuter sans ordre précis, ou avec un ordre partiel.
• L’article souligne les limites de l’utilisation de plusieurs processus pour la concurrence, en raison du coût élevé de la communication inter-processus.
• Les threads, qui sont des processus partageant la même mémoire, sont présentés comme une alternative, mais ils peuvent introduire des problèmes complexes comme les conditions de course et les interblocages.
• L’article de Tony Hoare publié en 1978, "Communicating Sequential Processes", proposait d’utiliser des files d’attente ou des canaux pour que les threads s’envoient des messages, offrant plusieurs avantages comme une isolation de type processus et un débogage plus simple.
• La bibliothèque standard de Rust inclut des canaux sous std::sync::mpsc::sync_channel.
• Cependant, pour des problèmes exigeant un très haut niveau de concurrence, comme un serveur web connecté à des dizaines de milliers d’utilisateurs, les threads peuvent ne pas suffire.
• Pour ce type de situation, Rust utilise le modèle async/await : lorsqu’une fonction est marquée asynchrone, elle renvoie un future ou une promesse, sur lequel on peut attendre afin de produire un résultat.
• Malgré ses avantages, le Rust asynchrone présente des défis, notamment la nécessité de convaincre le compilateur que tout se passera bien, ce qui peut être plus difficile qu’avec des threads bruts.
• L’usage du "comptage de références atomique", ou Arc, est proposé comme solution, mais ce n’est pas une panacée car cela peut entraîner des problèmes similaires à ceux des ramasse-miettes.
• L’article conclut qu’en dépit des points forts de Rust dans d’autres domaines, ce n’est peut-être pas l’outil optimal pour les logiciels en espace utilisateur à très grande concurrence.

[GN⁺]

Discussion sur Hacker News

• L’auteur développe en Rust un client de métavers haute performance qui doit traiter en temps réel de très grands volumes de données.
• Son projet utilise plusieurs threads pour diverses tâches, notamment le rendu graphique, le traitement des événements réseau et le chargement des ressources.
• Rust s’est révélé bénéfique pour ce projet, et l’auteur explique qu’il subissait généralement une fois par an un crash lié à la mémoire à cause du code « unsafe » d’autres personnes.
• L’auteur critique Rust en disant qu’il n’élimine pas les conditions de concurrence mais pas les interblocages, et suggère la nécessité d’un analyseur statique de deadlocks.
• L’auteur critique l’usage généralisé de l’async en Rust, affirmant que cela n’est pas adapté aux tâches liées au calcul et n’est pas compatible avec des threads s’exécutant à plusieurs niveaux de priorité.
• L’auteur avance que la propriété unique de Rust correspond à un besoin courant lorsqu’il existe des références arrière, mais qu’elle est trop difficile à mettre en œuvre.
• L’auteur estime que l’écosystème jeu vidéo de Rust n’est pas prêt pour le développement de jeux sérieux, citant le manque de graphismes non jouets en Rust.
• D’autres commentaires conviennent que l’async Rust est difficile et souvent inutile, et suggèrent que l’approche de Go, qui consiste à tout rendre synchrone avec un seul canal async, pourrait être meilleure.
• Certains commentateurs critiquent l’usage très répandu de l’async dans l’écosystème Rust, affirmant que cela force à rendre tout le programme async ou à dépendre du crate tokio pour beaucoup de choses.
• Certains commentateurs suggèrent que les fonctionnalités async de Rust sont encore en cours de développement et qu’il est trop tôt pour critiquer leur état actuel.
• Un commentateur soutient que Arc en Rust n’est pas inconnu par nature, mais dépend de l’endroit et de la manière dont on le détient, et suggère que l’auteur essaie d’imposer à Rust son ancien modèle mental.
• Certains commentateurs s’opposent plus généralement à l’usage de async/await, estimant que cela divise le langage et l’écosystème en deux et crée des problèmes à long terme.
• Un commentateur suggère que la bonne primitive pour la concurrence est généralement le Communicating Sequential Processes de Hoare, mappé à des green threads comme cela a été implémenté en Java (depuis JDK17 - Java Virtual Threads), Go et Kotlin.
• Un commentateur propose qu’utiliser un crate unsafe comme async-scoped pour attraper la plupart des bugs qui auraient été écrits en C++ constitue un compromis raisonnable.