Kevin Ball氏がホストを務めるSoftware Engineering Dailyのポッドキャストで、Steve Klabnik氏とHerb Sutter氏が、RustとC++に関するいくつかのトピックについて議論している。議論の内容には、これらの言語の共通点と独自性、相違点、進化の仕方などが含まれる。
完璧な言語は存在しない
Klabnik氏にとって、Rustがメモリセーフ言語であるという一般的な考え方のほかに、Rustが本当に異なるのは、最近のプログラミング言語ではあまり普及していないが、プログラミング言語の分野ではよく知られているアイデアからインスピレーションを得ていることだという。
一方、Sutte氏はゼロオーバーヘッド抽象化、つまり、抽象化のために過剰なコストを支払うことなく、より高いレベルの方法で物事を表現できるという考え方を強調している。ここでKlabnik氏は、Rustが「ゼロコスト」抽象化を実現する主なメカニズムが型によるものであることを考慮し、Sutter氏と同じことを述べている。
[Klabnik氏］基本的に、型システムで表現できることが多ければ多いほど、実行時にチェックする必要が少なくなります。
しかし、すべての抽象化がゼロオーバーヘッドというわけではないとSutter氏は言う。コンパイラが必ず無効にするオプションを提供する2つのC++機能として、例外処理とランタイム型付けを例に挙げている。
[Sutter氏] なぜかというと、この2つは手動でより書いた方がうまくいくからです。あるいは、使わなくてもコストがかかるからです。
つまり、言語設計は芸術や工芸と同じで、好みや言語がどうあるべきかという哲学に大きく影響されるということだ。そのため、完璧な言語が存在するというところにはまだ至っていない。
適用可能な分野
どちらの言語がどのように使われるのかについて、Sutter氏は、エコシステムの成熟度やスレッドセーフティ保証がどちらかを選ぶきっかけになるかもしれないが、両者は非常によく似たターゲットを持っていると言う。Klabnik氏は、Rustが大企業でもネットワークサービスを作るためによく採用されている事実を強調する。
[Klabnik] 例えばCloudflareは、バックエンドにRustのコードを使ってい ます。そして、彼らはインターネットトラフィックの10%を支えています。他の企業も[...] Pythonで書かれたものをRustに書き換え、その結果、クラウド料金から何千台ものサーバーを削減できました。
Sutter氏は、C++が時間と空間をコントロールする能力と、30年以上にわたってC++を中心に構築されてきたツール・エコシステムの豊かさを強調する。一方、Rustは比較的まだ新しい言語だ。
[Sutter氏】現在、会社からコードを出荷するにはこのツールを通さなければならないものがあります。このツールはC++は理解できますが、Rustは理解できません。そのコードは出荷できないです。もしRustで書いたとしても、VPの例外なしでは出荷できません。
言語はどのように進化するか
言語の進化に関して言えば、重要なポイントは、新機能のために言語に複雑さを加える価値がいつあるのか、ということだ。これは必ずしも簡単な決定ではない。この点に関して、Klabnik氏がC++について称賛する点の1つは、「合理的な範囲内」での下位互換性への取組である。
[Klabnik氏］私は、必ずしもRustチームが大枠で同じような考えを持っていないとは言いません。しかし、最近、複雑さを増すような提案がいくつかあり、個人的には必ずしも快く思っていないです。
Sutter氏は、C#チームがある時点で言語にnullabilityを追加することを決定し、これは確かに素晴らしいことだが、隠れたコストももたらしたと述べている。
[Sutter氏] ユーザーにとっての複雑さや、言語自体の複雑さだけでなく、今後20年間の複雑さもあります。なぜなら、この機能を永遠にサポートしなければならないからです。そして、それは進化を永遠に制約することになります。[...]nullabilityを追加すると、実際には言語全体がそれについてもっと知っている必要があることがわかります。
このような決断を下すことがいかに難しいかをさらに強調するために、Klabnik氏は、awaitに対するRustのpostfix構文と戦った事例を思い出している。この構文はprefixである他のほとんどの言語とは異なる。
[Klabnik] 現在、私はasyncとawaitを使ったコードをたくさん書いています。postfix awaitが採用されてよかったと思います。なぜなら、それは本当に、いろんな面でずっと素晴らしいからです。
言語エディションの力
Rust Coreチームが変化を管理する方法のひとつに、新しい機能が追加されたときにソースの互換性を保つための言語エディションの定義がある。
Sutter氏は、このメカニズムによって、既存のコードベースとの衝突を防ぐためにco_asyncやco_awaitキーワードを採用することなく、C++のasync/awaitサポートを導入できたかどうかを理解することに興味を示している。Klabnik氏は、エディションは新しい構文を追加する強力なメカニズムだが、限界があると説明している。
[Klabnik氏]
muteをuniqueに変更することは、純粋に構文の変更として全く問題ありません。なぜなら、最終的に 2015 用に 1 つのパッケージをコンパイルし、2024用に1つのパッケージをコンパイルし、2024がuniqueなどを追加すると、同じ内部[表現...しかし]にデシュガーされるからです。ただし、エディションにGCを追加することはできません。そうすると、より深いレベルで動作が実際に変わるからです。
同様に、Rustの標準ライブラリーは独自のバイナリであるため、したがって、すべてのエディションで使用されるすべての関数が含まれていることを確認する必要があります。
Klabnik氏とSutter氏はポッドキャストで、ここで要約できないほど多くの内容や詳細を取り上げている。その中には、C++て興味の標準化プロセスの重要性、ISO標準言語を持つことがRustコミュニティとっに深いかどうか、Rustの場合、コンパイラを 1 つではなく複数持つ理由と意味、コンフォーマンスへの対処方法、大学でC++やRustのような言語を教えることの価値などが含まれる。さらに詳しく知りたい方は、ポッドキャスト全編をお見逃しなく。