Rustで新しいコードを書くことは皆にとっての勝利！Greg K-Hが語るその理由とは？

印象として、彼のキャラクターの核心にはいつもこれがあったと思う。ただ、それを文章にするのを学んだのかな。対照的に、状況に応じて模範的なキャラクターを演じる人たちもいるけど、実際には裏では復讐心に満ちて毒々しい場合がある。

LinusはRustがあまり好きじゃないか、少なくともPro-Rustではないと思ってたけど、実際には彼の近くのスタッフがかなりRust推しだから、内核でもRust実験が始まった感じ。最近の反応を見てると、Rusted Linuxは避けられない流れだね。彼はPro-Rustだ。

最初からそう思う必要はなかったはず。実験が始まったのは、彼が試してみたいと思っていて、ある程度の支持があったから。彼の動機についてはかなり喋ってるしね。

彼はC++を排除するのに困ってなかったよね。

CとRustの利点を比較したら、CとC++の比較よりもずっと影響が大きいと思う。

Linux Foundationの企業スポンサーからRustを進める相当な圧力がかかってると思うよ。Google、Microsoft、AWSなんかも含まれてる。

圧力はあちこちから常にかかってる。何かがOSの置き換えをするリスクがあるからね。C++の普及に関しては、Linusはその流れが限られてるのを見極めて、リスクがほとんどないと判断したんだと思う。
ただ、Rustに関してはそうはならない。

少なくともGoogleはAndroidでRustベースのLinuxコードを実際に使用して展開してる。大きなLinux Foundationのメンバーは公には知られていない影響力を持ってると思うよ。

Rusted Linuxは「避けられない」理由があって、なぜならRustは客観的に良い言語だから。Cに比べても設計が多くの言語の欠点を修正してるし。

本当の理由は昔の5時間かかるカーネルコンパイルへの思いなんじゃないかな。

なんでそういうの？古いシステムにはRustツールチェインがないかもしれないし、将来出てくるアーキテクチャはどうなるの？

＞古いシステムにはRustツールチェインがないかもしれないし、
Linuxは常に進化についていけないと捨てられるというスタンスだよね。安定したドライバAPIがないのもその一環。
＞将来出てくるアーキテクチャはどうなるの？
そのアーキテクチャにRustコンパイラが無いなんて誰が言ってるの？Cコンパイラがある保証もないし。

今のところRustツールチェインがないLinuxのレガシーシステムってどれなの？進歩を止めて200人がAmigaでm68kを動かすために99.9%のユーザーを犠牲にするの？Apple Siliconのユーザーはm68kの何倍もいると思うよ。

確かRustはllvmを使ってるから、バックエンドを変更すれば大丈夫じゃない？

Linuxがサポートしているプラットフォームの中には、LLVMが対応していないものもあるよ。それに、古いシステムにはメンテナが少ないから、良いLLVMバックエンドを作るのは難しいかも。

なんで彼はこのメールを3週間前に送らなかったのか理解できない。

正直、Linuxからのこういう返答を待ってた。Hellwigをひとまず黙らせた感じ。
＞問題のプルリクエストはDMAレイヤーには全く影響を与えないもので、全く別のサブディレクトリのユーザーの話だった。
全くあなたのコードに影響を与えないわけだから、こんな無茶な反論を持ち出すのは残念だよ。
早かったら、才能ある貢献者をカーネルから失わずに済んだかもしれない。

＞早かったら、才能ある貢献者をカーネルから失わずに済んだかもしれない。
R4Lのリード開発者が辞めたのは、Hellwigを完全な負け犬に感じさせないための妥協だと思ってる。それはひどいけど。

誰が辞めたの？

色々な議論を見て感じたのは、Rustを受け入れることで得られる利益が、その苦労に見合わないと考えてる人がいるってこと。提案されてる利点の大部分は、Rustなしでも他の方法で実現できるかもしれないし、clangを必須のコンパイラにして、甚至限界チェックを導入するだけで大きな効果が得られるんじゃないかな。あと、Rustコードの可読性や美しさについての不満も多いみたいだね。

Cの開発者は間違いを犯さないと思ってるから、Rustの価値を見出せないんだろうな。FreeBSDの開発者ともそんな議論をしたことあるけど、同じような態度で、俺のアプリをクラッシュさせるバグを指摘したら、逆にRustのラッパーが悪いって責められたのは驚いたよ。

確かに、そんな風にプライドでやったことはあるな。誰かを謙虚にするための努力をしてしまうことがある。でも、自分も同じように謙虚にされる必要があると思ってる。時には自分を本当に見つめ直すことも大事だね。

人はなんで自分の頭の中で多くのシンボルを使いこなすことを見せびらかしたがるのか理解できん。結局、コンピュータは指示されたことをやるだけなんだし、人間がそれを完全に支配するなんて無理だよ。言語が問題解決を考える上で影響があるのは確かだけど、進歩をもたらすのはツールや抽象化だと思うんだ。

＞”色々な議論を見て感じたのは、Rustを受け入れることで得られる利益がその苦労に見合わないと考えてる人がいるってこと。”そのメールを読んでみて。Greg KHは確かにその利点に価値があると考えてるよ。あと、今のタイミングでCコードを改善できるチャンスでもある。確かにシンプルな解決策があるかもしれないって考えたくなるのもわかるけど、実際にそういうものは見たことがないからな。

＞”そのメールを読んでみて。Greg KHは確かにその利点に価値があると考えてるよ。”誰もがGreg KHがそう思ってるなんて考えてないだろ。彼はここで言われてる「人々」とは違う存在なんだ。

CVEリストを見ると、Cのメモリバグの70-80％は範囲外読み書きに関係してるんだ。Rustと同様に、bounds-safetyも冗長なチェックを排除できる。カーネルに実装するのは可能性が高いと思うけど、フォーマル化はリファクタリングを難しくする可能性があるから、そこに対する恐れがあるかも。Cやカーネルの利点は、新しいハードウェアや要件に対する柔軟性なんだから。

＞”カーネルに導入するのはどのくらい可能性があるのか？”私の予想では難しい。fbounds-safetyは、範囲外の読み書きが発生した際にプログラムを中断する仕組みだから、カーネルを中断させるのは全然良い選択肢とは言えない。ドライバにバグがあったら、PCが突然オフになるなんて誰もが受け入れられないから。

そうだね、カーネルでのパニックはよろしくない。R4Lに関してはずっとフォローしてきたけど、fboundsにはプログラムを中断せずにテレメトリイベントとして記録するオプションがあるみたい。それを使えば、カーネルが生き残る可能性があるから良さそうだね。

ああ、ありがとう。それがWARN_ON_ONCE(…)と同じように処理できて、遅延があまりなければ良いシステムだね。そんなら、すごく良さそうだ。自分も読み込む必要がある。

Linusの考えについて、プログラムを壊さないようにするセキュリティ強化の努力は絶対に必要だよという意見があるみたい。＞”https://lkml.org/lkml/2017/11/21/356”

GCCのために、コンパイラがトラップを挿入したときに警告を出す10行くらいのパッチを持ってるよ。サニタイザーを使って、警告をエラーに変えて、サインオーバーフローとかの問題を防げるよ。

そのパッチ、役立ちそうだね。なんでアップストリームに行かなかったの？

サニタイザーはプロダクションには出荷されないよ。

データ損失やセキュリティの脆弱性を引き起こすのが、カーネルがクラッシュするよりいいなんて、俺には理解できない。

どちらかはサーバーやアプリケーション、データを失わせるかもしれないけど、もう一つは確実に壊れるよ。

多くのケースでは、静かに間違ったことをするより、はっきりと爆発する方が好ましいよ。特に敵対的な行動をする奴らの前ではね。

一方は攻撃者に本来アクセスできないデータにアクセスさせたり、勝手にコードを実行させたりするかもしれない。もう一方はそれをしないように保障されている。

Rustはプログラミングエコシステムから他の安全な選択肢を追いやってると思う。Adaみたいな他の安全なメモリの言語もあるのに、理由がわからない。Rustだけがメモリ安全を達成する唯一の選択肢でなくてもいいよね。

LinusはAdaがあまり好きでないみたいで、才能のあるプログラマも少なくて年齢層も高いからね。Rustが他の言語よりも優れている理由は、成功したからで、若手が触れることができたのも一因だよ。それに、Rustが唯一の選択肢であるべきじゃないという意見から、待てたはずだという意見に変わるのはおかしいと思う。

そうだね！Rustは色んなことをうまくやってるけど、プロトコルとprocマクロはひどいし、RAIIもダメだよ。

あなたの意見だね。でもprocマクロがひどいのには同意するよ。「プロトコル」ってRustの何のことかわからないけど。RAIIについては意見が分かれることもあるけど、私はそれに感謝してる。結局、Linus Torvaldsが隠れているアカウントじゃない限り、私たちの意見は関係ないみたいだね。

＞研究が遅れているのは、潜在的な利点が少なくて、研究のコストが高いから。
その通り。今のところ、Rustの他に達成できている安全な選択肢はないし、現状で改善するのを止める理由にはならないよ。

＞Rustが唯一の方法である理由は、それが唯一うまく機能しているからだ。
その通りだけど、大変だからみんな挑戦しなくてRustに落ち着くんだよ。6ヶ月で進展が得られるかもしれないのに、何でRustのコストを払わなきゃいけないの？

先週のAdaスレッドの後、AdacoreのサイトでPDFを見たけど、意外なことが多かったよ。論理演算子が短絡評価しないとか、サブプロシージャと関数があって前者は値を返さないとか、Adaのswitch相当はフォールスルーしないとかね。

＞論理演算子が短絡評価しないって言ってるけど、二つの構文があって、短絡しないのはandで、短絡するのはand thenだよ。

＞理由を拒否する前に、少なくともその理由を知るべきだよ！

Rustの戦略が唯一の方法でなければならない理由って何なの？RAIIだと思う人もいるけど、明確なキーワードを使って解放ステップを作ればいいんじゃない？

良い会話は「Rustの戦略が唯一の方法かどうか」を議論するところから始まると難しいと思う。他にも方法はあるよ。Javaの戦略も有効だけど、システムプログラミングには不向きだし、Rustのアプローチは強力だよ。

私の言う「戦略」は理論じゃなく実装の話。ライフタイピングをコンパイラにお願いする必要ある？静的チェックツールの一部にしても良いだろ。RAIIなしでアフィン型も使えるし、Rustのやり方に代わるオプションはたくさんある。

まず、君の指摘は”Rustのメモリ安全性戦略”とは関係ないことを言っているよね。マクロや他の使いやすさは戦略には含まれていないし、確かにそれらはRustの核となる価値を変えずに異なることができる。静的解析に関するポイントに集中した方が良いと思うけど、型システムは静的解析ツールの一種だし、他のツールに置き換えられる可能性もある。例えばPythonのMyPyがあるけど、そんなツールは開発の日常から外れることができない。プログラムの正しさをチェックする以上、コードが正しいかどうかを確認し続けなきゃいけない。皆が静的解析ツールをまったく使わないとしたら、それは問題を生む。Rustが他の言語と違うのは、親密に統合されたアフィン型を持ち、適度に使いやすい環境が整っているところだね。

テストや開発ビルドの時だけValgrindやASANを使っている成功事例もあるよ。>どうやってコミットごとにコードの信頼性を確認するの？今は簡単に全コミットでフルチェックできるし、プルリクエストもテストに失敗したら拒否できるようになってる。失敗を避けるためにGitの履歴を修正するのも面倒だけどできる方法だ。

静的解析は無視される可能性が高いという大きな欠点があるよ。

それでいいさ。例えば、自分だけが使うプログラムでは静的解析をしなくても問題ないし、物理シミュレーションのように一度だけ400,000コアで走らせるHPCのワークロードでも、テストでクラッシュしなければ多分スケールでも大丈夫だろう。OSを作るならもちろんチェックはするべきで、実際、RustのエコシステムもMIRIを使うことを推奨しているよ。

じゃあ、Cで「速いプログラム」を書くのは？それがカーネル開発の比較になっているよ。RustがMakefileやシェルスクリプト、Pythonスクリプトの代わりになるとは言わないけど、Rustなら多くの”速いプログラム”を快適に書けるのはすごいね。

＞Cで「速いプログラム」を書くのはどう思う？もちろんカーネル開発では無理だね。そういう場合は静的解析は必須だよ。

(Miriは静的解析ではないよ。)

それは問題の本質じゃないよ。静的解析の外にあるユニットで、安全性チェックを追加するために存在しているんだ。

他の選択肢が探求され、却下された可能性はどうやって分かるの？君がRustに不満を持っていることは、みんながそう思ってるわけじゃない。Rustの機能を好む人もいるし、私はそれをコンパイラに一体化してほしいと思う。問題ない？もしライフタイムチェックが別のツールなら、rustcがライフタイムルールに違反したバイナリを作れるなら、Rustはメモリ安全な言語とは言えないよ。コンパイラが成功したら正しさが保証されていることで、生産性が向上するし、私たちが考えることはどうでもいいんだ。

時には何かが勢いで選ばれることもある。実は言語にこだわってないんだ。雇われた言語でコーディングするけど、個人プロジェクトはC++やPythonでやることが多いよ。

正直言って、同じモノリシックなコードベースに二つのプログラミング言語を並行して混ぜるのは良くないと思う。フロントエンドとバックエンドのように用途やレイヤーが違う場合ならまだしも、両方を自分で扱うのはストレスになるし、Cの開発者とRustの開発者が分かれて作業することで技術的にもコミュニケーション的にも摩擦が生まれる。特に組み込みシステムに関わっていると、二つのツールチェーンを設定する手間や、Rust/LLVMのコンパイラの遅いコンパイル時間によるCIやデバッグの時間延長を想像するだけで”痛い”ね。