おそらくRustは大規模な高並行ユーザー空間ソフトウェアに適したツールではないかもしれない

• この記事は、大規模な高並行性を持つユーザー空間ソフトウェアにRustを使う際の課題について論じている。
• Rustの非同期モデルは、現代のコンピューティングにおける2つの中核概念である並行性と並列性を扱うように設計されている。
  • 並列性は、複数のCPUでコードを同時に実行することを含む。
  • 並行性は、問題を分離し、独立した部分に分け、順序に依存せず、あるいは部分的な順序で実行することを含む。
• この記事は、高コストなプロセス間通信のために、並行性のために複数プロセスを使うことの限界を強調している。
• 同じメモリを共有するプロセスであるスレッドが代替案として提示されるが、競合状態やデッドロックのような複雑な問題を引き起こす可能性がある。
• Tony Hoareの1978年の論文 "Communicating Sequential Processes" は、スレッド同士がメッセージを送るためにキューまたはチャネルを使うことを提案しており、プロセスのような分離性や容易なデバッグなど、いくつかの利点を提供する。
• Rustの標準ライブラリには、std::sync::mpsc::sync_channel にチャネルが含まれている。
• しかし、数万人のユーザーに接続されたWebサーバーのように、高水準の並行性を必要とする問題では、スレッドだけでは不十分な場合がある。
• Rustはこうした状況に対して、関数が非同期としてマークされるとfutureまたはpromiseを返し、結果を生成するまで待機できる "async/await" モデルを使用する。
• その利点にもかかわらず、非同期Rustには、すべてが問題なく動作することをコンパイラに納得させる必要があるといった課題がある。これは生のスレッドより難しいことがある。
• 解決策として "アトミック参照カウント"、すなわちArcの利用が提案されるが、ガベージコレクタの問題に似た課題を引き起こす可能性があり、万能薬ではない。
• この記事は、Rustは他の分野での強みにもかかわらず、大規模な高並行性を持つユーザー空間ソフトウェアにとって最適なツールではないかもしれないと示唆して締めくくられている。

[GN⁺]

Hacker Newsの意見

• 著者は、リアルタイムで大量のデータを処理する必要がある高性能なメタバースクライアントをRustで開発しています。
• 著者のプロジェクトでは、グラフィックレンダリング、ネットワークイベント処理、アセット読み込みなど、さまざまな作業のために複数のスレッドを使用しています。
• Rustはこのプロジェクトにとって有益であり、著者は通常、他人の「unsafe」なコードが原因で年に一度ほどメモリ関連のクラッシュを経験していたと述べています。
• 著者は、Rustにはレースコンディションはないがデッドロックは防げないと批判し、静的デッドロックアナライザーの必要性を提案しています。
• 著者は、Rustでasyncが広く使われていることを批判し、これが計算集約型の作業には適しておらず、複数の優先度で実行されるスレッドとも両立しないと主張しています。
• 著者は、Rustの単一所有権モデルでは後方参照が一般的に必要になるものの、実装があまりにも難しいと示唆しています。
• 著者は、Rustのゲームエコシステムは本格的なゲーム開発の準備ができていないと考えており、Rustにおける実用的なグラフィックスの不足を挙げています。
• 他のコメントでは、async Rustは難しく、しばしば不要だという点に同意し、Goのようにすべてをsyncにして単一のasyncチャネルにするアプローチのほうが良いかもしれないと提案しています。
• 一部のコメント投稿者は、Rustエコシステムでasyncが広く使われていることを批判し、そのせいでプログラム全体をasync化するか、多くの場面でtokio crateに依存することを強いられると主張しています。
• 一部のコメント投稿者は、Rustのasync機能は今なお開発途上にあり、現時点の状態を批判するのは時期尚早だと示唆しています。
• あるコメント投稿者は、RustのArcは「わからないもの」ではなく、どこでどのように所有しているかによって決まるものであり、著者は以前のメンタルモデルをRustに押し付けようとしているのだと主張しています。
• 一部のコメント投稿者は、一般的にasync/awaitの使用に反対しており、これが言語とエコシステムを二分し、長期的な問題を引き起こすと主張しています。
• あるコメント投稿者は、並行性に対する正しいプリミティブは、Java（JDK17以降のJava Virtual Threads）、Go、Kotlinで実装されているように、green threadsにマッピングされたHoareのCommunicating Sequential Processesだと提案しています。
• あるコメント投稿者は、async-scopedのようなunsafeなcrateを使って、C++で書かれていたなら入り込んでいたであろうバグの大半を捕捉するのは、妥当な妥協だと提案しています。