Talvez Rust não seja a ferramenta ideal para software em espaço de usuário com concorrência em grande escala

• Este artigo discute os desafios de usar Rust em software em espaço de usuário com concorrência em grande escala.
• O modelo assíncrono do Rust foi projetado para lidar com dois conceitos centrais da computação moderna: concorrência e paralelismo.
  • Paralelismo envolve executar código simultaneamente em várias CPUs.
  • Concorrência envolve separar um problema, dividi-lo em partes independentes e executá-las sem considerar a ordem ou com uma ordem parcial.
• O artigo destaca as limitações de usar vários processos para concorrência devido ao alto custo da comunicação entre processos.
• Threads, que são processos que compartilham a mesma memória, são apresentadas como alternativa, mas podem introduzir problemas complexos como condições de corrida e deadlocks.
• O artigo de 1978 de Tony Hoare, "Communicating Sequential Processes", propôs o uso de filas ou canais para que threads enviem mensagens umas às outras, oferecendo várias vantagens, como isolamento semelhante ao de processos e depuração mais fácil.
• A biblioteca padrão do Rust inclui canais em std::sync::mpsc::sync_channel.
• No entanto, para problemas que exigem alto nível de concorrência, como um servidor web conectado a dezenas de milhares de usuários, threads podem não ser suficientes.
• Para essas situações, Rust usa o modelo "async/await", no qual funções marcadas como assíncronas retornam um future ou promise sobre o qual se pode aguardar para produzir um resultado.
• Apesar de suas vantagens, Rust assíncrono traz desafios, como a necessidade de convencer o compilador de que tudo ficará bem, algo que pode ser difícil com threads brutas.
• O uso de "contagem atômica de referências", ou Arc, é sugerido como solução, mas não é uma panaceia, pois pode causar problemas semelhantes aos de um garbage collector.
• O artigo conclui sugerindo que, apesar das forças do Rust em outras áreas, ele pode não ser a ferramenta ideal para software em espaço de usuário com concorrência em grande escala.

[GN⁺]

Opiniões no Hacker News

• O autor está desenvolvendo em Rust um cliente de metaverso de alto desempenho que precisa processar grandes volumes de dados em tempo real.
• O projeto do autor usa várias threads para diversas tarefas, como renderização gráfica, processamento de eventos de rede e carregamento de assets.
• Rust foi benéfico para esse projeto, e o autor normalmente sofria um crash relacionado à memória uma vez por ano por causa de código "unsafe" de outras pessoas.
• O autor critica o fato de Rust não ter race conditions, mas ainda permitir deadlocks, e sugere a necessidade de um analisador estático de deadlocks.
• O autor critica o uso disseminado de async em Rust, argumentando que isso não é adequado para tarefas bound por computação e não é compatível com threads executadas em múltiplas prioridades.
• O autor sugere que a propriedade única de Rust é uma necessidade comum junto com referências retroativas, mas difícil demais de implementar.
• O autor acredita que o ecossistema de jogos em Rust não está pronto para desenvolvimento sério de jogos, citando a falta de gráficos não triviais em Rust.
• Outros comentários concordam que async Rust é desafiador e frequentemente desnecessário, e sugerem que a abordagem do Go de tornar tudo sync e usar um único canal async pode ser melhor.
• Alguns comentaristas criticam o uso disseminado de async no ecossistema Rust, alegando que isso força os programas a serem async de ponta a ponta ou a depender do crate tokio para muitas coisas.
• Alguns comentaristas sugerem que os recursos async de Rust ainda estão em desenvolvimento e que é cedo demais para criticar seu estado atual.
• Um comentarista afirma que o Arc de Rust não é algo desconhecido, mas é determinado por onde e como você o mantém, e sugere que o autor está tentando impor ao Rust seu modelo mental anterior.
• Alguns comentaristas se opõem ao uso de async/await em geral, argumentando que isso divide a linguagem e o ecossistema ao meio e causa problemas de longo prazo.
• Um comentarista sugere que o primitivo correto para concorrência é o Communicating Sequential Processes de Hoare, mapeado para green threads, como implementado em Java (JDK17 em diante - Java Virtual Threads), Go e Kotlin.
• Um comentarista sugere que usar crates unsafe como async-scoped para capturar a maioria dos bugs que teriam existido em C++ é um compromisso razoável.