Quizá Rust no sea la herramienta adecuada para software de espacio de usuario con concurrencia a gran escala

• Este artículo analiza los desafíos de usar Rust en software de espacio de usuario con concurrencia a gran escala.
• El modelo asíncrono de Rust está diseñado para manejar dos conceptos clave de la computación moderna: concurrencia y paralelismo.
  • El paralelismo implica ejecutar código al mismo tiempo en varios CPU.
  • La concurrencia implica separar un problema, dividirlo en partes independientes y ejecutarlas sin importar el orden o con un orden parcial.
• El artículo destaca las limitaciones de usar varios procesos para concurrencia debido al costoso costo de la comunicación entre procesos.
• Los hilos, que son procesos que comparten la misma memoria, se presentan como una alternativa, pero pueden provocar problemas complejos como condiciones de carrera y bloqueos mutuos.
• El artículo de 1978 de Tony Hoare, "Communicating Sequential Processes", propuso usar colas o canales para que los hilos se envíen mensajes entre sí, ofreciendo varias ventajas como aislamiento similar al de los procesos y depuración más sencilla.
• La biblioteca estándar de Rust incluye canales en std::sync::mpsc::sync_channel.
• Sin embargo, para problemas que requieren un alto nivel de concurrencia, como un servidor web conectado a decenas de miles de usuarios, los hilos podrían no ser suficientes.
• Para estas situaciones, Rust usa el modelo "async/await", en el que cuando una función se marca como asíncrona devuelve un futuro o promesa sobre el que se puede esperar para producir un resultado.
• A pesar de sus ventajas, Rust asíncrono presenta desafíos, como la necesidad de convencer al compilador de que todo estará bien, algo que puede ser difícil con hilos sin procesar.
• Se propone el uso de "conteo de referencias atómico", o Arc, como solución, pero no es una panacea porque puede generar problemas similares a los de un recolector de basura.
• El artículo concluye sugiriendo que, a pesar de las fortalezas de Rust en otras áreas, quizá no sea la herramienta óptima para software de espacio de usuario con concurrencia a gran escala.

[GN⁺]

Opinión en Hacker News

• El autor está desarrollando en Rust un cliente de metaverso de alto rendimiento que debe procesar grandes volúmenes de datos en tiempo real.
• El proyecto del autor usa múltiples hilos para distintas tareas, como renderizado gráfico, procesamiento de eventos de red y carga de recursos.
• Rust ha sido beneficioso para este proyecto, y el autor normalmente experimentaba un fallo relacionado con memoria una vez al año debido al código "unsafe" de otras personas.
• El autor critica que Rust no tenga condiciones de carrera, pero no esté libre de interbloqueos, y propone la necesidad de un analizador estático de deadlocks.
• El autor critica el uso extendido de async en Rust, y afirma que no es adecuado para tareas ligadas al cómputo ni compatible con hilos que se ejecutan con múltiples prioridades.
• El autor sugiere que la propiedad única de Rust, aunque es una necesidad común junto con las referencias hacia atrás, es demasiado difícil de implementar.
• El autor cree que el ecosistema de juegos de Rust no está listo para el desarrollo de juegos serio, citando la falta de gráficos no triviales en Rust.
• Otros comentarios coinciden en que async Rust es desafiante y a menudo innecesario, y sugieren que el enfoque de Go de hacer todo sync y usar un solo canal async podría ser mejor.
• Algunos comentaristas critican el uso generalizado de async en el ecosistema de Rust, afirmando que obliga a que el programa completo sea async o a depender del crate tokio para muchas cosas.
• Algunos comentaristas sugieren que la funcionalidad async de Rust todavía está en desarrollo, y que es prematuro criticar su estado actual.
• Un comentarista sostiene que Arc de Rust no es algo desconocido, sino que depende de dónde y cómo lo mantienes, y sugiere que el autor está intentando forzar su modelo mental previo sobre Rust.
• Algunos comentaristas se oponen al uso de async/await en general, argumentando que divide al lenguaje y al ecosistema en dos y causará problemas a largo plazo.
• Un comentarista sugiere que la primitiva correcta para la concurrencia es Communicating Sequential Processes de Hoare, mapeada a green threads, como se ha implementado en Java (desde JDK17 - Java Virtual Threads), Go y Kotlin.
• Un comentarista sugiere que usar un crate unsafe como async-scoped para atrapar la mayoría de los bugs que habrían sido escritos en C++ es un compromiso razonable.