2025年のRust: 基盤ソフトウェアを目指して

 (smallcultfollowing.com)
23 ポイント 投稿者 GN⁺ 2025-08-20 | 15件のコメント | WhatsAppで共有
  • Rustは今年で10周年を迎え、今後は基盤（Foundational）ソフトウェア開発の中核言語としての地位を確立しつつある
  • 基盤ソフトウェアとは、OSカーネル、クラウドプラットフォーム、組み込みデバイス、CLIツールなど、あらゆるものの土台となる層を指す
  • RustはC/C++級の性能と信頼性を提供しつつ、メモリ安全性を保証する型システムによって参入障壁を下げた
  • Rustの使命は単に基盤領域にとどまらず、Dioxus, Tauri, Leptosのようなプロジェクトを通じて上位アプリケーション開発にも波及効果をもたらしている
  • 今後は言語間相互運用性、型システムの拡張、エコシステム強化などを中核的な投資領域として計画している

Rustのビジョン: 基盤ソフトウェア

  • Rustの中核ビジョンは、基盤ソフトウェアをより簡単に書き、保守できるようにすることにある
    • 基盤ソフトウェアには、あらゆるシステムの土台となるOSカーネル、クラウドインフラ、組み込みデバイス、CLIツールなどが含まれる
    • すでにWindowsとLinuxカーネル、VSCodeの検索エンジンripgrep、Deno、Pythonのuvパッケージマネージャーなど、さまざまな場所で採用されている
  • この種のソフトウェアでは、性能・信頼性・生産性のすべてが同時に重要となる
    • 土台が崩れると上位レイヤー全体に影響が及ぶため、安定性は不可欠
    • 性能低下は上位レイヤーの性能限界につながるため、オーバーヘッドは最小限である必要がある

基盤ソフトウェアの性能、信頼性、生産性

  • 基盤ソフトウェアには他のすべてのソフトウェアと同様に多様な要求があるが、どの要素もいっそう重要になる
    • 信頼性は最優先課題である。土台が崩れれば、その上にあるすべてが失敗する構造だからだ
    • 性能オーバーヘッドは上位レイヤー性能の限界を左右するため、最小化しなければならない
    広告
  • 従来、こうした要件を満たすには2つの選択肢があった
    • C/C++: 大きな自由を与えるが、それに見合う完全性が求められる
    • Java、Goなどの高水準言語: 性能維持のために特別なコーディング方式が必要で、抽象化や利便性の活用に制約を受ける
  • Rustはゼロコスト抽象化とメモリ安全性を保証する型システムの組み合わせによって、従来のやり方を変えた
  • 高水準のコードを安全に書きながら、低水準の性能とメモリ安全性を同時に実現するための道具となっている

参入障壁を下げることと開発者の力を引き出すこと

  • Rustの発表では、型システムと静的検査を**「ほうれん草」**（良いものだが食べたくないもの）にたとえることがよくある
  • しかし現実には、型システムは開発者にとって強力な武器である
  • 初心者は型システムを学ぶことで、成功するソフトウェア構造を学べる
  • 熟練者は自分の構造設計におけるミスをより早く発見できる
  • Yehuda Katzの「集中している状態で作る抽象化が、疲れた未来の自分を助けてくれる」という発言も、これをよく要約している

非基盤ソフトウェアの領域

  • Rustのミッションが基盤ソフトウェアに焦点を当てているからといって、それ以外の領域が無視されるわけではない
  • Dioxus, Tauri, Leptosなどのプロジェクトは、Rustを活用してGUIやWebページのような高水準アプリケーション領域へも広げている
  • Rustの主な強みは本質的に基盤ソフトウェアに集中しているが、こうした試みも軽視すべきではない

ストレッチ目標と成長

  • 基盤ソフトウェアは低水準の詳細な制御を必要とするため、一般には**アクセシビリティと使い勝手（ergonomics）**は重要ではないと見なされがちである
  • しかし、必要な詳細制御があるからこそ、むしろ使い勝手が重要になる
  • 開発者が本当に重要な部分だけに集中できるよう支援すれば、生産性は大きく向上する
広告
  • Rustの高水準適用を推進するプロジェクトは、Rustプログラミングをさらに快適に改善する機会を提供している
  • こうした改善点は基盤ソフトウェア開発にもそのまま反映される
  • 核心は、制御権と信頼性を失わずに使い勝手を高めること

フルスタック支援の重要性

  • Rustで高水準アプリケーション開発を快適にするもう1つの理由は、フルスタックを1つの技術で構築できることにある
  • 当初はRustをデータプレーンサービスなど一部にだけ使おうとしていた開発者が、全領域へ拡大するケースが増えている
  • Rustは生産性が高く、1つの言語でライブラリやコードを共有できるためである
  • 本質的に単純なコードは、どの言語で書いても単純である

段階的な深化（Iterative Deepening）の体験

  • 理想的には、Rust利用者の最初の体験はシンプルであり、プロジェクトが進むにつれて、より多くの制御を局所的に段階的拡張できるべきである
  • これは単純に見えて、実際には非常に難しい課題である
  • 多くのプロジェクトは、初心者の参入障壁が高すぎたり、高度な制御段階を学ぶのに多くの知識を要求したりして失敗する
  • Rustが常に成功しているわけではないが、これを改善するために継続的に努力している

今後の計画

  • 本稿はこのシリーズの第1回であり、この後4回にわたってRustが基盤ソフトウェアにより適したものになるために必要な投資領域を提示していく予定である
    • 言語間相互運用性（smooth language interop） と 拡張性（extensibility）
    • 型システムを通じた目的の明確化（clarity of purpose）
    • エコシステム強化: より良いガイドライン、ツール、Rust Foundationの活用
    • 最後の記事では、Rustオープンソース組織の運営について、貢献と保守ができるだけ参加しやすく楽しい活動になるための方法を扱う予定

関連記事

15件のコメント

 
yeorinhieut 2025-08-23

Rustは何だか良さそうに見えても、厄介なファンダム（？）のせいで敬遠してしまう唯一の言語のように思います。
 
aer0700 2025-08-22

CやC++にも標準的なパッケージマネージャーがあればよかったのに、と思います。Cargoを見るといつもそう感じます。
 
cosine20 2025-08-21

ほうれん草ってすごくおいしいのに……
 
t7vonn 2025-08-21

最近は、Rustが使われていない場所はないですよね
 
lostid 2025-08-21

一応大企業に勤めていますが、Rustを使う分野がありません。煽らないでください。
 
t7vonn 2025-08-21

いちゃもんをつけないでください
 
bobross0 2025-09-03

うわ;;;;;;;;
 
crawler 2025-08-21

煽らないでくださいね ﾌﾞﾙﾌﾞﾙ
 
shakespeares 2025-08-22

うわ;;
 
qwas5544 2025-08-22

うわぁぁぁぁぁ;;;
 
lostid 2025-08-21

何はともあれ、最近のRust信者のせいでうんざりしそうです。オフラインではマイナーな中でもかなりの少数派なのに、オンラインではほとんどISIS状態……。ああ、どこか一か所に集まって、自分たちだけでやっていてほしい……
 
ifmkl 2025-08-21

Rust原理主義者にしては、実際に本人がちゃんと使っているのか疑問な場合も多いですよね。
 
skageektp 2025-08-21

それでも…Rustはお好きですよね？
ラスラムは嫌ってもいいですが、Rustは愛してください（泣）
 
taeunlee99 2025-08-21

FFmpegのときに痛い目に遭っても、すべてのコードをRustで書かなければならないとか何とか
 
GN⁺ 2025-08-20
Hacker Newsの意見

  • 中核ソフトウェアを論じる際、Rustで最も惜しい点はABIだという指摘。RustでOSを作り豊富なサービスを提供するには、OSがアップグレードされてもアプリケーションがライブラリを再コンパイルせずに使える必要がある。WindowsはCOM、AppleはかつてObjCのdynamic dispatch（現在はSwift ABI）、AndroidはJVMとバイトコードでこの問題を解決している。Rustは実質的に extern "C" しかサポートできないため、動的ライブラリの活用が制限される。VM層（JVM、.NET）なしでABIを提供するのは非常に難しく、いったん決めた実装詳細を絶対に変えられないため、優先順位が下がるのも理解できる。実際にこのモデルで成功したのはSwiftとCOMくらいだという。Rustに完全なABIが導入されれば、ほぼ完璧な言語に近づくはずだという意見。（依存関係をバイナリ形式で管理できれば、コンパイル時間も大きく減る）

    • Rustが基本的に選択的（opt-in）なABI安定性だけを導入しようとしている理由は、zero-cost abstractionを志向しているからだという説明。安定したABIは性能低下を伴うことは、C++の事例（C++ ABIに関する説明）からも裏づけられる。Rust同士でプラグインを動的ロード（dlopen）する用途には、stabbyやabi_stableなどのツールがあり、かなりうまく動く。より汎用的な言語間相互運用のためには、crABI（crABI提案書）が将来の代替案になりうる。ただしこれはRustだけで解決できる問題ではなく、他言語やLinuxディストリビューションなど複数コミュニティの支持と協力が必要だという。RustはI/Oやメモリ割り当て方式を明示的に選ぶ言語なので、Swiftのようにすべてを共有ライブラリだけで解決する構造は合わないかもしれない点にも触れている。
    • ほぼ同じ問題をWasm Componentsで解決しようとする試みも進んでいる。WebAssemblyが移植可能な命令フォーマットだとすれば、WebAssembly Componentsは移植可能な実行／リンク形式だという。完全に repr(wasm) / extern "wasm" のように簡単ではないが、wit-bindgen や wasm32-wasip2 ターゲットを活用すれば、それほど難しくなく使える。Wasm Components紹介動画
    • これが本当に必要なのか疑問だという意見。より多様な「もの」（slices、trait objectsなど）をインターフェースとして渡せると便利ではあるが、現実的には extern "C" ABIだけでも必要なことは一通りできる。そしてextern ABIをより多くの型へ拡張する提案も見たことがあるという。
    • Rustカンファレンスで、このテーマについてSwiftのやり方を強く参考にした内容の発表を見たことがあるとのこと。おそらく今後はこちらの方向に発展していくだろうという予想。
    • 実際にはすでにそういうものがある。その名は「C」だという指摘。

  • Rustは本当に好きだが、いくつかのいら立たしい慢性的問題にももっと注目が集まってほしい

      1. self-referencing structの問題。たとえばソースファイルとパース済みASTを同じstructに入れたくても、今は簡単ではない。offset referenceのようなものがあるとよい。
      1. orphan rule（孤児トレイト規則）。理由は理解できるが、やはり面倒な規則だ。新しい機能で回避できることはあるが（時には2〜3重のラッピングが必要）、本当にそこまでしなければならないのか疑問だ。
      1. 適切なコンパイル時間を得るには、プロジェクトを小さなcrateにたくさん分割しなければならない。その理由は理解できるが、結果はあまり良くない。crateは1つのコンパイル単位として扱われるが、これは循環依存が許されているためだ。しかし大半のコードには実際には循環依存はないのだから、これをopt-inにするか、crate内部のitemやファイルを依存グラフに従って自動的にコンパイル単位へ分割してほしい。
    • 思いついたものを書いただけだが、まだ他にもありそうだ。それでもRustは建設的な批判を差し引いても人生最高の言語だという。
      • Rustはcrate間では循環依存を許さないが、crate内モジュール間では循環依存が許されるという指摘。大半のコードには循環依存がないと思うが、たとえばtestサブモジュールを持つ任意のモジュールでは循環依存が適用される。テストをきちんと分離しようとすると、すべてのテスト関数をcrateルートに定義しなければならず、現実的には非効率だという。
      • 1と2には完全に同意するという反応。4つ目としてpartial self borrows（メソッドがstructの一部だけを借用する機能）が欲しいという意見も追加。3については、複数crateを一度に配布できるなど、まずはもう少し良い支援が必要だと考えている。
      • orphan ruleについて、Rustが別のより良い代替案を導入すべきだと言っているのか、それとも単にこれを置き換えられる機能が必要だと言っているだけなのか、もう少し説明してほしいという要望。
      • orphan ruleには全面的に同意するという声。アプリケーションcrateではこれを無効化したり、proc macroなどで十分な衛生性が保証される場合には規則を緩和できるとよい、という意見。

  • “Smooth, iterative deepening”という表現をかみしめつつ、Rustがcross-language互換性を重視しすぎると、かえって複雑さを増し安全性を損なうリスクがあるという見方。こういう場合は、むしろlibcのようにシステムの最下層を置き換える形のほうが有益だろうという。Goはcross-language呼び出しをほとんどしない。Googleは中核ライブラリを自前で開発して基盤を固めたが、Rustではさまざまなバージョンの基礎ライブラリが乱立し、多くが未完成だという指摘。

    • 過去20年間、計算機科学の中核課題の1つは、同じマシン内で複数プログラムが効率的に通信する方法だったという話。多くはMSのDLLベースをソースと状態で回避しようとしたり、CORBAのようなオブジェクト要求ブローカーは定着に失敗した。QNX的なRPCも同様。結局、今も相性の良くないものを無理やり結びつけようとする試みが繰り返されているだけだという。
    • 実際にはすべてをソケットで処理することもできるが、ソケットは低レベルなバイトストリームであり、適切でない抽象化にもかかわらず使い勝手が良いため使わざるを得ないという意見。
      • 自分の見るところ、この投稿で扱っているのは既存のDLL/COM/Wasm componentsのような真のcross-language shared library代替を目指す話ではなく、C++を段階的にRustへ移行したいという現実的なニーズだという指摘。全体的なメモリ安全性向上のために「既存プログラムをどうするか」は大きな課題であり、現在のRustとC++の相互運用レベルでは不十分だ。両言語がソースレベルで円滑に協調できれば、RustがかなりのC++領域を置き換える現実的可能性も高まる。
      • ソケットとプロトコルさえ合えば、ほぼ最良のcross-language abstractionになることもある気がする。では本当に理想的だと思うcross-language呼び出し抽象化とは何なのか、気になるという声。

  • 「割り当てを避ける、GCをトリガーさせない」という発想は、最新のGCやJITの考え方に合っていないという指摘。現代のGCはstop-the-world latencyがほとんどない場合も多く、GC全体のCPU使用量はresident setとheapサイズの比率が主要な変数になる。JITはAOTより最適化の機会が多く、より積極的に探索できる（投機的最適化のおかげ）。実際に重要なのは、起動／ウォームアップ遅延、メモリオーバーヘッド、悪化した最悪時性能ではなく、平均性能だという。さらに手動メモリ管理が必ずしもより効率的とは限らず、実際のRAM使用量が3倍になってもコスト差がゼロということすらありうる。このテーマをうまく扱った ISMM学会発表 も勧めている。

    • JITのほうがより多くの最適化機会を見る、という意見が具体的に何を意味するのか気になるという反応。JITは結局AOTの補完にすぎないのではないかという。
    • ここで言う「現代のGC」がどの実装を指しているのかを問うコメント。

  • フラグ付きコメントと議論は論点をよく押さえていたという評価。「公式仕様を持つ言語標準を作ろう」「複数実装が必要だ」といった現実的に重要な問いだ。特に@infogulchは、言語が産業の基盤になるなら公式仕様が不可欠だという点を的確に指摘していた（参照コメント）。

    • なぜフラグされたのかが明確でないうえ、実際には標準仕様がない言語や複数実装のない言語でも産業基盤になった例は多い、という機知ある例示。たとえばRubyには古いISO標準があるといっても特定バージョン向けに限られ、Pythonは事実上実装そのものが標準だ。Rustも同様で、主流ユーザーの立場からすれば、それを理由に言語を変えることにはならないという。
    • 「公式言語標準」について気になって検索したところ、rust-lang/reference というリファレンス文書が見つかった。Rustプロジェクトは言語仕様化にかなり真剣に取り組んでいる。最近の ブログのビジョン紹介記事 では進捗が詳しく説明されている。仕様策定は非常に大きく難しい作業だが、週末にもmasterブランチへPRがマージされるほど、今も活発に進んでいるという。
    • 複数実装が必要だという点についても、gccrsなどの代替Rustコンパイラ がすでに公式に開発されており、その助けになればという補足。
    • LLMとRustはいずれも本質的には一部の要求を満たし、生産性を少し向上させる程度だと見る懐疑的な見方。ただし、コミュニティが無責任に影響力だけを拡大しようとする態度には同意できないという。
    • “published language standard”とは正確に何を指し、現実にどんな助けになるのか、もう少し説明してほしいという質問。
    • Rust自体への不満はないが、一部ユーザーが形式仕様（formal specification）の重要性を理解していない態度には残念さがあるという意見。あらゆる計算機システムは、仕様にどれだけformalに向き合うかで寿命と信頼性が左右される。明確な仕様がなければ、単に「ある実装がたまたまある入力で動いた」という事実に全面的に依存するしかなく、そのような脆弱な土台の上にシステムを載せるのは危険だという。計算において仕様こそがシステムであり、実装は副次的な最適化にすぎないという主張。

  • 人々はしばしばRustに仕様が必要かという問い自体に疑問を呈するが、そのこと自体がソフトウェアエンジニアリングに本物のエンジニアリングがあまりに少ないことの証左だという指摘。

    • ソフトウェアエンジニアリングは本当の意味でのエンジニアリングではないと思う。橋や高層ビルのように3回建ててようやく正しく作るわけにはいかないが、ソフトウェアではむしろそれが良いアプローチになりうる、という意見。

  • Rustを「プログラマに見られたい人だけが使う言語」と評したコメントに対し、自分は実際にプログラミングを愛する人間で、Rustは新鮮な衝撃だったという反応。あれほど苦痛だったC++の時代には到底戻りたくない。そして言語標準（ferrocene仕様の寄贈）や実装数はそれほど重要ではないと考えている。PythonやJavaも中心となる単一実装に大きく依存しつつうまく回っている。C++は複数コンパイラ対応を追求した結果、かえってプラットフォームごとの複雑な問題ばかり増えた。cargoの「めちゃくちゃ」とは具体的に何なのかわからず、C++のほうがよほど不便だったという。

    • cargoについて具体的に何が問題なのか知りたいという問い。
    • 言語やツールの標準化／実装多様性が本当にそこまで重要なのか、まだ早すぎるのではないか、またRustが早い段階からそこに労力を注いでいたら今ほど成功していただろうか、という疑問も添えている。この記事はそうした包括的な「すべての置き換え」を主張しているのではなく、特定のターゲット用途への支援や適性を強調したいのだろう、という見方。
    • cargoは今ある主要言語の中で世界最高のパッケージマネージャだと思う。これまでのパッケージマネージャが失敗してきた点をよく学び、最も洗練され、インフラとしての完成度も高い。ネームスペースや完全なrepeatable buildなど多少の改善余地はあるが、今のcargoを他言語に載せるのはほぼ不可能に近い。このレベルのインフラを持つ言語はほとんどない。