Rustはそれだけの価値があったのか？

• 著者のJarrod Oversonが、主にWebAssemblyのためにRustを3年間使った経験を共有。
• 彼はRustを使って、WebAssemblyを中核モジュールシステムとして使用するアプリケーションフレームワーク兼ランタイムであるWickを構築。
• Rustのテスト駆動開発のやり方は、より少ない労力で多くの保守を可能にし、大規模なテストの必要性を減らす。
• 著者は、Rustでプログラミングすると他の言語でのコーディング能力も向上することを発見。
• RustのリンターであるClippyは、性能、可読性、不必要な間接性を改善する幅広いルールを取り入れている。
• しかし著者は、Rustのライブラリやツールには特定のユースケースをしばしば扱えていない部分があると指摘。
• 彼は、特定の制限のためにcrates.ioというRustのパッケージレジストリへパッケージを公開しづらい点を批判。
• 著者はまた、Rustのasync-inessも批判しており、これは後付けのようなもので、しばしば解決が難しいエラーにつながると述べている。
• Rustの豊かな型システムのため、リファクタリングは難しくなりうる。
• 欠点はあるものの、著者はRustの多様性と堅牢性を称賛。
• 著者は、素早い反復が必要なプロジェクトにはRustは適さないかもしれないが、範囲が明確なプロジェクトや、より多くの初期コストを受け入れられるプロジェクトでは検討する価値があると結論づける。

[GN⁺]

Hacker Newsの意見

• Rustは生産性が低く制約が多いと感じ、Zigのような他の言語を好んで、よりコーディングそのものに集中できると考えるユーザーもいます。
• crates.io に名前空間がないことは批判の対象であり、その結果、誰でもグローバルなパッケージ名を主張できてしまい、問題が生じる可能性があります。
• Rustの幅広いライブラリ群と優れたドキュメント体系を高く評価するユーザーもいます。
• プロジェクトに対するグローバルな lint 設定がないことへの懸念はありますが、.cargo/config.toml ファイルを使う解決策が提案されています。
• 重要な低レベルクレートの一部が 0.x バージョンのまま止まっている状況に不満を示すユーザーもいます。
• バックリファレンスに関する言語レベルの問題が強調されており、静的解析ソリューションへの要望があります。
• Rustコンパイラを有用に活用しており、そのエラーメッセージを称賛するユーザーもいます。
• Rustにおけるテストの必要性をめぐる議論があり、コンパイルできればおそらく正しいと主張する人もいれば、ビジネスロジックは依然としてテストされるべきだと主張する人もいます。
• Rustの使用を不便だと感じつつも、仕事上の理由でRustを学んでいるユーザーもいます。
• プログラマーはコンパイラが行うことをすべて完全に制御し、完全に認識していなければならないという考えを打ち破る点で、Rustを高く評価するユーザーもいます。
• Rustにおける async の使用をめぐる議論があり、不満の原因だと見るユーザーもいれば、あらゆるものに使うべきだと考えるユーザーもいます。