2022年、Rustの未来を探る旅 (1) はじめに
※大風呂敷を広げてやる気だけ表明する記事です。まだ中身はない。
はじめに
Rustは2009年頃に誕生し、2015年に正式リリースされたプログラミング言語です。その革新性はおよそ以下のように集約されます。
-
shared XOR mutable とそれに付随する発明 (所有権、ライフタイム) により、ミュータブル参照が正しく扱えるようになった (責任分界点が明確になった) こと。
- 上記のアイデアにより、高パフォーマンス・低フットプリントが求められるアプリケーションやOS・GC・アロケーターのない環境で動く必要のあるアプリケーションをより安全に書けるようになったこと。
- プログラマーが安全に・快適にプログラムを書くための既知の優れた道具 (パッケージマネージャーなど) を計画的に取り入れ、伝統的なプログラミング言語が抱えがちな問題を広範に解決したこと。
これらの革新性から、これまでC/C++が担ってきた領域を中心に、Rustはプロダクションレディーなプログラミング言語としての立ち位置をほぼ確立したといっていいでしょう。
そして、これからもRustは進化し続けることが期待されていますが、その一方でRustが抱える負債や限界も少しずつ目にとまるようになってきたと考えられます。
特に、Rustは2015年に正式リリースして以降は後方互換性に対して慎重なスタンスを取っているため、一度入れた間違いは簡単には正せないことがあります。新機能の安定化プロセスを工夫することで、ある程度この問題は抑えられることが期待されますが、それでも万全ではありません。
本シリーズでは、Rustや「Rust登場以後の世界のプログラミング」の未来を占うために、いくつかの決まった観点から様々なプログラミング言語を試してみたいと思います。
「視点」について
以下、いくつかの「視点」をメモとして挙げていきます。これらはRustの優れた設計や、逆にRustがうまく達成できなかったものが含まれています。
続く記事では、様々なプログラミング言語について、これらの視点の一部をピックアップしながら各言語の特徴を検証していきます。それによって、Rust自身やRust以降の世界のプログラミングに対する洞察を得ることが本シリーズの目的です。
また、本シリーズではもしかしたらプログラミング言語以外の道具 (対話的定理証明器など) も扱うかもしれません。その場合は必ずしもこのリストに沿わない場合もあるかもしれません。
一気に埋めるのは気が滅入るので、とりあえずメモ代わりに置いておきます。のちのち説明を足したり、新たな視点を足すかもしれません。
視点1: shared XOR mutable
Rustの革新性のうち、特に独自性が高いのは shared XOR mutable とそれに付随する発明です。
視点1-a: shared XOR mutable に沿ったミュータビリティーを表明できるか
説明をあとで書く
視点1-b: イミュータブル参照の期限切れ後にミュータブル参照を取得できるか
視点1-c: ミュータブル参照の期限切れ後にイミュータブル参照を取得できるか
視点1-d: 参照からの参照の取り出しをAPIとして抽象化できるか
視点1-e: ミュータブル参照を配列や構造体メンバに対して空間分割 (分配) できるか
視点1-f: ミュータブル参照の空間分割 (分配) をAPIとして抽象化できるか
視点1-g: ADTのミュータブル参照を射影できるか
視点1-h: イミュータブル参照からの読み出しは明示的か
視点1-i: スマートポインタの利用は明示的か
視点1-j: 循環参照を含むデータ構造を操作するさい、排他制御の粒度はいくらか
視点2: RAII
視点2-a: デストラクタの実行タイミングは字句的に決定されるか
視点2-b: GCとRAIIが両方ある場合、2つの相互作用はどうなるか
視点3: インターフェース・型クラス
視点3-a: フィールドを持つ型を継承する仕組みはあるか
視点3-b: インターフェースはゼロレシーバーなメソッドやダブルレシーバーなメソッドを持てるか
視点3-c: インターフェースは多相か
視点3-d: 既存の型に新規インターフェースの実装を与えることができるか
視点3-e: 既存の型と既存インターフェースの間に新規実装を与えることができるか
視点3-f: 実装が重複したときに何が起こるか
視点4: サブタイピング・漸進的型づけ
視点4-a: 構造的・公称的部分型システムをもつか
視点4-b: 合併型・交差型をもつか
視点4-c: 不変条件を不透過的に表明する方法 (newtype) をもつか
視点4-d: 不変条件を透過的に表明する方法 (refinement) をもつか
視点4-e: ADTバリアントに対するサブタイピングをもつか
視点4-f: 漸進的型づけがある場合、条件違反はどのようにハンドルされるか
視点4-g: 漸進的型づけとライフタイムがある場合、ライフタイム違反はどのようにハンドルされるか
視点5: エフェクトシステム
視点5-a: 羃等性・純粋性を表明できるか
視点5-b: 例外はどのようにハンドルされるか
視点5-c: 外部環境へのアクセスはどのように抽象化されるか
視点5-d: コルーチンはどのように抽象化されるか
視点5-e: 非同期処理はどのように抽象化されるか
視点5-f: エフェクトハンドラを設定できる場合、エフェクトハンドラは継続を複数回呼び出せるか。呼び出せるとすれば、ミュータブル参照に対する変更は巻き戻されるか
視点6: パッケージ管理
視点6-a: 依存関係の状態はプロジェクト間で隔離されているか
視点6-b: 同名パッケージの複数バージョンをインストールできるか
視点6-c: 依存グラフの再現性は担保されているか
視点6-d: パッケージの取り下げに対する耐性はあるか
視点6-e: ビルド時依存と実行時依存は区別されているか
視点6-f: 開発時依存と実行時依存は区別されているか
視点6-g: 同名の間接依存に対する経路が2つあるとき、2経路で間接依存のバージョンが一致する必要性を表明できるか。また、そのような暗黙の制約に気付く仕組みはあるか
視点6-h: 依存グラフのエッジでオプションを指定できる場合、オプションが別経路からの依存に干渉する可能性があるか
視点6-i: 異なるバージョン制約の組み合わせに対してパッケージをテストする仕組みは整備されているか
視点6-j: 依存制約の下限の正しさをテストする仕組みは整備されているか
視点6-k: 公開時に配布物にビルド済みソースを含める慣習はあるか / ある場合、VCSから直接依存を取得する場合はどのように対応しているか
視点7: 後方互換性
視点8: C/C++互換
wishlist
だいたいこのあたりを触ってみようかなと思っています。(間違いなく途中で挫折するけどとりあえずメモとして)
Discussion
パッケージ管理について、例えばサプライチェーン攻撃についての視点を加えるのはいかがでしょうか。
wishlistについて、例えばHareも挙げられるかもしれません。