プログラミング
Rust言語の問題点
Problems with the Rust Language (oxetene.net)
要約
この記事は、Rust言語の採用ペースの速さ、Rust Foundationへの大企業の影響力、ライセンス変更を目的としたプロジェクトのRustへの書き換えトレンド、そしてコンパイラのブートストラッププロセスに関するセキュリティ懸念について論じています。著者は、採用を遅らせ、Rust自体の改善に注力し、GCC Front-End for Rustのような代替コンパイラを支援することを提案しています。
全文翻訳
Rust言語の問題点
メモリ安全性は素晴らしい考えだと思います。私は主にC言語プログラマーであり、メモリ関連の問題のデバッグの「楽しさ」には精通しています。しかし、Rustが採用されているペースは、以下の理由で危険だと考えています。
RustはRust Foundationによって管理されています。Rust Foundationは自身を「Rustプログラミング言語によって支えられる、安全でセキュアで持続可能な未来にコミットする独立した非営利団体」と定義しています。それは結構ですが、Rust Foundationの所有者は誰でしょうか? その設立メンバーはAmazon、Google、Huawei、Microsoft、Mozillaです。「独立」と「非営利」という言葉の意味については一日中議論できますが、5つの企業が自らの利益になると信じずにプロジェクトを管理するために集まると考えるのはナイーブだと思います。Rustは、最初から企業の利益によって成長してきた言語です。Rust Foundationの理事会の議席は、年間わずか32万5千ドルで購入できます。
Rustの普及には、ある種の「社会的勢い」があります。取り残されることへの恐れ、古いものを新しいものに置き換える文化、トレンドです。Rustは、他の新しい技術と同様に、疑いの目を持って見るべきだと私は信じています。Rustは、ある種のプログラマーにとって、自分自身を識別するためのラベルのようになっています。Rustを使用するだけで、スマートで進歩的で安全だと見なされることがあります。それは、トレードオフを批判的に考えずに使用すべきであり、唯一の進むべき道であると一部のプログラマーを納得させてきました。
Rustコミュニティの主な娯楽の一つ、もはやミームですが、既存のプロジェクトをRustに書き換えることです。これは、私の意見では、セキュリティを向上させるための最悪の方法です。Rustの使用量を増やすだけで、そのメリットを何も受け取れない最良の方法かもしれません。Rustは魔法ではなく、論理的なエラーを修正することはできません。Rustプログラマーは依然として優れたプログラマーである必要があります。しかし、車輪の再発明を命じられた場合、優れたプログラマーの力でさえ限界があります。長年にわたるバグ修正を受けてきた信頼できるテスト済みのソフトウェアを、完全に新しい書き換えで置き換えることが望ましいとされるのはいつからでしょうか? それがどのように安全だと言えるのでしょうか?
私は、この書き換え文化は(再び)企業に利益をもたらすと信じています。現在、Rustで書き換えられるプロジェクトは、通常GPLライセンスで始まり、MITライセンスで終わります。企業は、何らかの形で貢献することなく、GPLプロジェクトのコードを使用することはできません。Rustへの書き換えによってライセンスがMITに変更されると、そのプロジェクトは企業が最も利益を得られる目的に自由に利用できるようになります。例としては、ロックダウンされたLinuxディストリビューションの作成、デジタル刑務所の作成が挙げられます。要するに、Rustプログラマーは、「安全性」と「効率性」という名目で、製品にGPLコードを埋め込むことへの報復を恐れる企業のために、無料の労働を提供しているのです。彼らは、自分たちのために刑務所を作り出すように騙されているのです。
この議論はJody Bruchon氏に負うところがあります。
Rustのコンパイラにバックドアが含まれている可能性は完全にあります。そして誰もそれを知らないかもしれません。この最後の点は非常に推測的で陰謀論的ですが、これに懸念を抱いているのは私だけではありません。Rustコンパイラをコンパイルする唯一の方法は、Rust Foundationがリリースした前バージョンのバイナリパッケージを使用することです。理論的には、このバイナリリリースには、ブートストラップ中にコンパイラの以降のバージョンにコピーされるバックドアが含まれている可能性があります。バイナリリリースが完全に問題ない可能性も完全にあります。それが問題なのです。
Rustコンパイラの唯一の完全に機能する、使用可能な実装しか存在しないため、Rust Foundationを信頼する必要があります。その歴史、所有者、そして管理上の問題の記録を考慮すると、それを信頼するのは難しいです。
これらの問題についてのすべてのくだらない話は、解決策を提示せずに不完全です。私の提案は、スローダウンすることです。まず、コミュニティは、他のプロジェクトを書き換えることによって「改善」しようとするのではなく、Rust言語自体を改善することに焦点を当てるべきです。私は、そのエネルギーを、バックドアの存在の可能性に関する懸念を軽減する代替コンパイラであるGCC Front-End for Rustプロジェクトを支援するために使うことを提案します。現在、開発の初期段階にあります。
これらの問題のどれも、Rust言語自体、つまりRustの書き方を定義する実際の形式文法に関する問題ではないと言えるかもしれません。これは真実です。個人的には、Rustは純粋に技術的な基盤においてC++よりも間違いなく改善されていると信じています。しかし、テクノロジーは人々に依存します。そして、Rustに関連する人々は、しばしば最善の意図を持っていないように見えたり、自分で考えずにトレンドに従っているだけだったりします。Rustの言語設計に関する問題について学ぶには、Nimfsoftのブログ記事を読むことをお勧めします。
https://rustfoundation.org/get-involved ↩︎
https://bentsukun.ch/posts/netbsd-rust-kernel ↩︎
https://jodybruchon.com ↩︎
https://internals.rust-lang.org/t/trusting-rust/2008 ↩︎
https://www.sophiajt.com/why-i-left-rust ↩︎
https://rust-gcc.github.io ↩︎
https://nimfsoft.art/blog/2025/06/26/analysis-of-rust-language-design-flaws ↩︎