Rust に賭けて10年、そしてこれから期待すること

 (tably.com)
18 ポイント 投稿者 GN⁺ 2025-06-12 | 5件のコメント | WhatsAppで共有
  • Rust 1.0 の公開直後から10年間にわたり Rust を実務導入してきた経験と、これからの10年への期待をまとめた記事
  • 初期にはバージョン互換性の問題、ビルド時間、borrow checker への適応が難しかった
  • Rust コミュニティとエコシステムは、「卓越したプログラミング感覚」と強い共同体文化によって急速に発展し、優れた開発者が Rust に集まる傾向が際立っていた
  • **いまや一般的なシステムおよびバックエンド分野において Rust は「堅実な選択肢」**となっており、標準ライブラリの発展とクレートエコシステムの成熟によって不確実性が大きく減った
  • ビルド速度、移植性、const 機能、並行性、さまざまなドメインへの拡張など、Rust が解決すべき残る課題と発展の方向性を具体的に示している
  • 今後の10年は、より高速なコンパイル、幅広いドメインへの拡張、開発者体験の革新が続くと見込まれ、Rust エコシステムのポジティブなフィードバックループが加速すると期待している
  • 2015年6月、Rust 1.0 公開の熱気が落ち着き始めた約1か月後に、最初の Rust コードを書いた
  • C、Python、JavaScript を使ってきたが、Rust に触れてからはもう振り返ることがなくなった
  • Rust ベースのスタートアップ2社で、50万行を超えるコードを書いた経験をもとに、この10年を振り返る

初期はつらい時代だった - The early days were painful

  • Rust 導入初期には、クレートとコンパイラのあいだのバージョン互換性が非常に不安定で、小さなバグ修正のためにもビルド環境全体の更新を強いられることが多かった
  • borrow checker の概念とライフタイム管理は難しく感じられ、複雑な型が増えるほどコンパイル時間が急激に伸びる問題も深刻だった
  • 新機能やバグ修正が必要になるたびに「世の中のあらゆるバージョン」を更新しなければならず、互換性のあるバージョンを探すのに多くの時間を費やした

Rust コミュニティの卓越性 - The people were and are exceptional

  • Rust エコシステムには、シンプルでエレガントな実装と、高速で堅牢な性能を志向する卓越したプログラミング文化が根付いていた
  • TypeScript や Python を使うときよりも、Rust の依存関係の構造ははるかにクリーンで、ビルドも単純だった
  • コミュニティのボランティアによる献身的な貢献と、「今ではない／まだその時ではない」という慎重な姿勢が中核的な役割を果たしている
  • ロンドンでは Rust 開発者の採用に大きな利点があり、Rust 開発者の平均的な力量は非常に高い

Rust は（いくつかの分野では）堅実な選択肢になった - Rust has become a safe bet (in some domains)

  • 初期には標準ライブラリ（std）の不足のため、自前でユーティリティ関数やパッチを作る必要があったが、いまでは機能の大半が std とクレートに組み込まれており、不確実性は大きく減っている
  • ビルドやアップグレードの予測可能性、外部依存の減少、semver の遵守、borrow checker と推論エンジンの改善などによって、Rust を使う体験は大幅に安定した
  • 新しいクレート（例: jiff, polars, tauri）は過去の試行錯誤を踏まえて作られており、tokio, hyper, regex などは実運用で実証済みだ
  • かつては「車輪の再発明」が避けられなかったが、いまではビジネスロジックに集中して高性能で堅牢なアプリケーションを開発できるようになった

今日の Rust が示す開発環境 - Rust today feels like what programming should be

  • Rust は簡潔で堅牢なビルドシステム、最高水準のエラーメッセージと lint、優れたドキュメントと IDE 統合、強力な CI／回帰テストなど、プログラマ中心の共感性を備えた言語だ
  • 大規模なオープンソースプロジェクトの中でも、Rust ほどプログラマに優しい言語はまれだ
  • 数多くのコミュニティと貢献者による「長期的な投資」こそが、現在の Rust を形作った中核要因である

今後10年への期待 - What I’m looking forward to over the next 10 years

よりシンプルで高速なビルド - Simpler and faster builds

  • 複雑または遅い依存関係を、シンプルで高速なものに置き換える取り組みが今後も続くと期待している
  • pure Rust の標準ライブラリ、システム linker やライブラリ依存の削減、pure-Rust 暗号、永続 BTreeMap、Rust ベースのゲームエンジンなど、新たな試みに期待している
  • Tably でもここ数か月でフロントエンド／バックエンドのコンパイル速度が 60% 向上した

移植性の向上と #[cfg()] の最小化 - Improved portability and less #[cfg()]

  • さまざまなプラットフォームやオプションの組み合わせをテストするのは難しく、#[cfg()] による未検証コード、ドキュメントの不完全さ、IDE の問題などが生じる
  • #[cfg()] を trait system の内部へ移すことで、プラットフォーム／オプション保証や再コンパイルの最小化、MIR キャッシュ、高速な CIの実現が期待される

すべてのコードが const になること - Everything being const

  • コンパイル時により多くの処理を先に実行することで、マクロやビルドスクリプトへの依存を減らし、ランタイムエラーも事前に防げる
  • 現時点では制限があるものの、将来的には**「すべてのコードが const context で実行可能」な Rust を目指している**

並行性の単純化 - Simpler concurrency

  • 現行 Rust の非同期（Async）モデルは、'static bound、cancellation-safety、trait の制約など複雑さが高く、実務では扱いづらさがある
  • かつての user-space green thread（libgreen）のように、言語レベルでのシンプルな並行性の追求が必要だ

より多くのドメインで競争力を持つこと - Excelling in more domains

  • Rust のWeb ブラウザ内での活用（特に wasm/rustwasm）はまだ未開拓であり、クロスブラウザのスタックトレースなど多くの課題が残っている
    • leptos、sycamore などのフレームワークは発展を続けているが、なお改善の余地がある
  • Rapid prototyping、ビジネスロジック、GUI、機械学習、ゲーム開発など、Rust がまだ完全には切り開けていない領域も継続的に改善されていくと期待している

結論

  • Rust の成長の未来は非常に明確で希望に満ちている
  • 導入が進むほどエンジニアリングやテストの能力が高まり、それによってより広い採用と改善が生まれるという好循環がある
  • これからの10年で、より高速なコンパイル、多様な分野での適用、なめらかな開発体験が現実のものになるだろう
  • Rust の新たな10年に期待している

関連記事

5件のコメント

 
ndrgrd 2025-06-12

Rustはとても良いのですが、言語が要求してくることが多すぎます。
Rustを使っていると、アイデアの実装そのものに集中するというより、Rustという言語そのものを研究しているような気がします。

C++から移行するなど、すでに作られたプロジェクトを移すぶんには特に支障はないでしょうが、
新しいアイデアを実装するときに使いやすいのかは、正直よく分かりません。
 
felizgeek 2025-06-12

プロトタイピングにはPythonをおすすめします
 
ndrgrd 2025-06-12

個人的に型システムが好みなので、今はC#を使っていますが、このくらいで十分満足だと思います。
 
codemasterkimc 2025-06-12

個人的に地球環境を考えるなら Rust。レガシーな Spring コードを Axum に!!!
 
GN⁺ 2025-06-12
Hacker Newsの意見
  • とても前向きな内容の記事で、自分の経験とも一致している。ただ、暗い見通しを挙げるなら次の点。
    "asyncは'staticバウンド、キャンセル安全性、トレイトやdynに関する制約などのため、比較的高い複雑性コストを抱えている。現時点ではこの問題が解決される気配はない。同期/非同期プリミティブ間の分岐とエコシステム固有の特性がasync tax（追加コスト）を高めている。Effectsベースの解決策もあまり期待できない。"
    "Rust 1.0以前にはlibgreenという解法があった。分岐なしにユーザー空間で並行性を実装していたが、性能、移植性、保守コストが大きく、結局削除された。エンジニアリング能力さえ十分なら、もう一度検討する価値はあると思う。いつかstd::{fs, net}とfiber::{spawn, select}をgeneratorでzero-cost wrappingしたPoCを作ってみたい"
    • 「'static boundが複雑性を高めている」という議論は、Tokio async runtimeの設計上の選択にすぎず、Rust全体の設計と見るべきではないという意見。Embassy async runtimeはこうしたバウンドなしでも動作するが、その代わりpinningを自分で管理する必要がある。'static boundは実際には複雑さを下げる意図によるもの
  • 2022年末にRustに夢中になって学び始めた者として、2015年のようなもっと大変だった時期にこの言語を学んだ人たちの体験談はいつも興味深い。Rustがより成熟した時点で学べたので、すでに急な学習曲線がいくらか緩和されていたと感じており、その点では運が良かったと思う。最近は、記事で語られているRust初期の体験をZigで再び味わっている気分だ。ZigはRust初期と似た段階にあるように思う。それでもすでに楽しく使っている
    • 「見つけたときより良い状態で残す」という文化が強い。ツールや言語が分かりにくかったとしても、それはユーザーのせいではないという考え方が根付いている。自分が混乱したなら他の人も混乱するはずで、見つけるたびに改善することはみんなにとって大きな利益になる。木を植えるのに二番目に良い時は今日だ、ということわざが当てはまる。この文化のおかげで、以前Rustを試して挫折した人でも、1年後には十分に改善された体験を得られる。だからRust初心者への最高のアドバイスは「6か月待ってみて」だった
    • MSFTやGoogleのようなビッグテック、あるいはLinuxのような大規模オープンソースプロジェクトに採用された言語なら、すでにエコシステムが十分成熟している証拠だ。ただ、Zigはまだ既存ツールと比べて（大きな）変化を見せているとは言えず、その意味での確信はない
  • Rustは関数型プログラミングを促す感じがする。もともとはadvanceのたびに内部状態を変更するパーサーを作っていたが、可変性とborrow systemのために難しく、statelessなパーサーに変えざるを得なかった。内部インデックスを更新する代わりに、インデックスを返す構造へと変更することになった。こういうふうに、従来のやり方がうまく通用せず、Rustでは新しいアプローチが必要になることはよくあるのか気になる
    • 自分にも似た経験がある。単純なケースならmutableで命令型のスタイルでも問題ないが、複雑さが増すほど関数型スタイルに寄せ、変更をできるだけ避けるようになる。borrow checkerとライフタイムのせいで伝統的なパターンは難しく、自然と関数型寄りになる。関数型で実装することに慣れていないと大変かもしれないが、コンパイラがより満足してくれる感覚がある
  • Async/awaitがRustを使わない唯一の理由だ
    • 実際には、async/awaitはRustを使うべき主な理由のひとつだと思う。並行処理パターンをずっと簡単にしてくれるからだ。最初のうちは、まるで悪性の伝染病のように、すべてのコードが最終的にasyncにならざるを得ない感覚だったが、asyncコードと相互作用する方法が分かると楽になる。普通はspawn、spawn_blocking、futures::streamが活用の90%を占めるし、適切に「境界」を設けておけばasyncが伝播する必要もない
    • ある程度その気持ちは分かる。でも自分はRustのasync/awaitがしっくり来ていて、最大の採用理由になっている。構文も好きだし、function colouringの問題もあまり気にしない。特にtokioを使うときは、必要な標準関数のasync版が一通りそろっているので、うまく解ける感じがある。こうした点が障壁になることはあるが、並行プログラムを書くのがずっと簡単で、パフォーマンスも悪くないので満足している。キャンセル（cancellation）のような点では少し迷うこともあるが、それは自分の実力不足だと思っている
    • 今はもう全部そろっているのでは？