Web およびクラウド開発、Rust は普及するでしょうか?

編纂者：ヤン・ジェン

昨年、Web 開発会社 Mainmatter は Web 向け Rust に戦略的に賭け、EuroRust カンファレンスを立ち上げ、Rust Foundation に加盟し、社内およびオープンソースの両方で多くの Rust プロジェクトに取り組んでいます。

Mainmatter は、Rust が今後数か月から数年のうちに Web およびクラウド分野で普及すると非常に楽観的であり、Rust は Web 開発の新時代への第一歩であると考えています。この時代では、開発者はこのテクノロジーを使用して、開発者の経験と生産性を犠牲にすることなく、これまで想像もできなかったレベルの効率、安定性、信頼性、保守性を実現できます。

この投稿の目的は、Mainmatter がこの賭けに自信を持っている理由と、Rust が Web とクラウドで明るい未来を持っていると私たちが信じている理由を共有することです。

1. 大企業が支持するRustの将来

Rust は約 10 年前に登場して以来、開発者から多くの注目と愛を集めてきました。この言語を愛用しているのは開発者だけではなく、大企業の意思決定者も Rust を優れたテクノロジーとみなしており、過去数年間でこの言語は業界全体で広く採用されてきました。

AWS はプラットフォームで Rust を多用しており、Google は Android で、Microsoft は Windows で Rust を使用しています。基本的に、Rust は、システム プログラミング、オペレーティング システム、さまざまな組み込みシステム、低レベル ツール、ゲーム、ゲーム エンジンなど、これまで使用されていた多くの分野で C と C++ に取って代わると予想されています。

もちろん、上記に加えて、今後さらに大きな可能性を秘めているのが、Web とクラウドです。 Rust は、これら 2 つの分野のバックエンド改善スペースに無限の想像力をもたらします。バックエンドが新しいレベルに開発されると、チームは以前は不可能だった機能にアクセスできるようになります。

Rust はまだ新しい技術ですが、Truelayer、Discord、Temporal、Nando's、svix、Wingback など、多くの企業が Web やクラウドで Rust を効果的に使用しています。

Google も長年にわたって Rust を積極的に採用しており、最近、他のどの言語と比較しても Rust による生産性の低下は実際には見られないと述べたことも言及する価値があります。

2. Webを構築するというRustの野望

比較的新しいとはいえ、結局のところ、Rust のエコシステムは 1.0 のリリース以来 8 年しか経っていません。しかし、Rust とその Web エコシステムは、実際のアプリケーションを構築するための現実的な選択肢となるほどの成熟度に達しています。

arewewebyet.org によって確認されているように、Rust は明らかに Web に対応しています。

まず、Web アプリケーションの堅牢でパフォーマンスの高い基盤となる非同期ランタイムである tokio があります。 2 番目で最も重要なことは、Rust にはすでに axum や actix-web などの成熟した、よくメンテナンスされた Web フレームワークがあることです。 ORM だけでなく、関連するすべてのデータ ストア用の成熟したドライバーが存在します。最後に、(デ)シリアル化、国際化、テンプレート化、可観測性など、Web アプリケーションの構築に関連する他のすべての側面をカバーするライブラリが見つかります。

全体的に、Rust は野心的であり、Web バックエンドを構築するための堅牢で安定した構成要素を提供します。

3. Web 用に Rust に切り替える必要はありますか?

もちろん、「なぜ Rust に切り替える必要があるのか​​」と疑問に思う人もいるかもしれません。すでに Ruby、Java、Elixir、TypeScript、Go、またはその他の言語を使用しているチームにとって、Rust に切り替えるメリットは何でしょうか?

Rust が Web 上での構築に最適な選択肢となる主な側面は 2 つあります。1 つは効率性とパフォーマンスです。もう 1 つは、型システムによってもたらされる信頼性と保守性の利点です。

1. 効率性とパフォーマンス

Rust は効率性とパフォーマンスに優れていることで知られています。これは、Web アプリケーションで一般的に使用される JavaScript、Ruby、Python などの言語よりも数桁も優れたパフォーマンスを発揮します。他の言語（Java、C#、Go など）の方がパフォーマンスの上限が高い場合もありますが、Rust ツールキットがすぐに使用できるパフォーマンス レベルに近づくには、多くのエンジニアリング努力を投入する必要があります。

さらに、Rust には重要な利点があります。それは、ガベージ コレクターがバンドルされていないことです。ガベージコレクション言語は高速ですが、常に一貫して優れているわけではありません。ガベージ コレクターは未使用のメモリを解放するために一時停止を導入しますが、これはアプリケーションのテール レイテンシに悪影響を及ぼす可能性があります。 Rust にはこの問題はありません。これらのスパイクなしで一貫したパフォーマンスを提供します。

C と C++ は、このような安定した一貫したパフォーマンスを実現できる唯一の言語です。残念ながら、どちらの言語も、特に手動のメモリ管理に関しては、自ら足を撃ち抜く傾向があり、落とし穴がたくさんあります。 Linux の創始者である Linus Torvalds 氏は次のように述べています。

「ハードウェアに非常に近いため、何でもできます。危険です。チェーンソーをジャグリングしているようなものです。また、落とし穴がたくさんあり、見落としやすいこともわかりました。

このような危険性があるため、C と C++ は、これら 2 つの言語の専門家、または専門家のチームがある場合にのみ使用する必要があります。そうしないと、セキュリティホールだらけの不安定なシステムができあがってしまいます。

また、Web 空間では、JavaScript、Python、Ruby、Elixir など、ほとんどの人が非常に異なる言語を使用しているため、この種の専門知識を持つ人はほとんどいないことを忘れないでください。一方、Rust では同じ落とし穴に悩まされることがないため、開発者は以前のレベルの効率でソフトウェアを構築できます。

Rust は、メモリ使用量を大幅に削減しながら、Web バックエンドの構築に使用される他のテクノロジよりも桁違いに優れたパフォーマンスを発揮することがよくあります。

もちろん、Rust Web サーバーが他のテクノロジーに比べてほんのわずかな時間でリクエストに応答できるということは、同じ数のリクエストに少ないサーバーで応答できることを意味し、結果としてホスティング コストも削減されます。

中小規模の製品や企業にとって、ホストされているクラウド サーバーの数を減らすことは、毎月の経費を大幅に削減することを意味します。

当社の Python サービスの平均リクエスト数は 1 秒あたり約 50 件、NodeJS の平均リクエスト数は 1 秒あたり約 100 件、Rust の平均リクエスト数は 1 秒あたり約 690 件です。通常は 1 つの Python サービスをホストする k8 EKS ノードに 4 つの Rust サービスをインストールできます。 ——Redditユーザー

ただし、コスト削減はメリットの 1 つにすぎません。使用するサーバーの数が減れば、エネルギーの使用量も減ります。データセンターを再生可能エネルギーで稼働させるのは素晴らしいことですが、最も環境に優しいエネルギーは、やはり使用しないエネルギーです。 Rust は気候危機を解決することはできないかもしれませんが、私たちが作成したソフトウェアを実行するとリソースが消費され、現実世界に実際の影響を与えることを認識する必要があります。ソフトウェア業界では、これを忘れがちです。リソースをより効率的に使用し、より少ない入力で同じ出力を得ることができる場合、これはテクノロジーを選択する際の重要な考慮事項です。

2. 信頼性と保守性

パフォーマンスと効率は重要ですが、多くの場合、Rust の強力な型システムがもたらす信頼性と保守性の利点の方がおそらく重要です。

次のようなコード スニペットは、Web アプリケーション (Ruby on Rails) ではごく一般的です。

 class User attr :name attr :active attr :activation_date def activate(activation_date) self.active = true self.activation_date = activation_date save end def save … end end … user.activate(Time.now)

このコードは非常に簡潔で読みやすく、このようなコードを記述するとすぐに目的に到達できますが、問題もあります。この例では、ユーザーのプロパティは確認できますが、それらのプロパティにどのようなルールがあるのか​​はわかりません (たとえば、active が true の場合、activation_date も設定する必要があるでしょうか? active が false の場合、おそらく activation_date は nil である必要がありますか?)。これらの仮説を検証するには、情報を取得するために比較的多くの労力を要する activate メソッドの実装を研究する必要があります。

activate メソッドの呼び出しを見ても、エラーが発生するかどうか、またはどのタイムゾーンで時間を費やすべきかを知る方法はありません。 Ruby は柔軟性でよく知られているため、少し極端かもしれませんが、こうした問題の多くは他の言語にも存在します。 Java を例に挙げてみましょう。まだ、型システム内の active プロパティと activation_date プロパティに関するルールをエンコードできていません。これらのプロパティが null になる可能性がある場合でも、実行時に NullPointerException が発生するリスクがあります。

コード ベースが拡大し、開発チームが拡大するにつれて、あるいは単に一部の人が退職したり参加したりすると、状況は変化します。コードベースで作業するすべての人が、アプリケーション全体とコードベース全体で行われたすべての暗黙の仮定について完璧なメンタルモデルを持っていることを期待するのは難しいですが、これらの概念を理解するには、レガシーコードを注意深く読む必要があります。これにより、効率が低下するだけでなく、生産時のエラー率が増加する可能性もあります。

上記と同じコード スニペットですが、Rust ではより明確で表現力豊かになっています。

 enum User { Inactive { name: String, }, Active { name: String, active: bool, activation_date: DateTime<Utc>, }, } impl User { fn activate(&self, activation_date: DateTime<Utc>) -> Result<(), DBError> { match self { User::Inactive { name } => { let new_user = User::Active { name: name.clone(), active: true, activation_date: activation_date, }; new_user.save() } User::Active { .. } => Err(Error::default()), } } fn save(&self) -> Result<(), DBError> { … } }

まず、User モデルでは、Rust の列挙型関連データを使用できます。こうすることで、非アクティブなユーザーとアクティブなユーザーの見た目、およびどのシナリオでどの属性を設定するかが完全に明確になります。実際、アクティブなユーザーと非アクティブなユーザーの属性は同じではなく、各ユーザーには自分にとって意味のある属性のみがあります。それらはそれぞれのユーザーのステータスを表します。さらに、属性の型は明確に定義されています。Rust は型付けされているのに対し、Ruby は明らかに型付けされていないだけでなく、型も非常に正確です。例: activation_date フィールドの場合、予想されるタイムゾーンもタイプ内で正しいです。

activate 関数のシグネチャは、Rails の例で暗黙的である多くの情報も明示的にエンコードします。ここでも、期待されるタイムゾーン activation_date は型内で正しく、関数は Rust タイムゾーン Result を返します。これにより、呼び出し時にエラーが発生する可能性があることが明確になります。実際、Rust コンパイラーでは、処理されない実行時例外が発生しないように、Result の成功とエラーの両方のバリアントを処理する必要があります。

さらに、Rust には暗黙的な null 可能性の概念がないため (Java とは異なり)、関数が呼び出されたときに関数の activation_date パラメータには常に値があることが保証されます。 activation_date の計算された位置に値がない場合、Option<DateTime<Utc>> は期待される DateTime<Utc> とは異なる型であるため、activate 関数に渡すことができない可能性があります。 Rust コンパイラは、Option の Some バリアントによって activate メソッドの呼び出しが行われるコード パスのみを許可するため、関数の実行時に activation_date に値が確実に設定されます。

これは明らかにかなり単純な例ですが、Rust の主な強みの 2 つを非常によく示しています。

(1) Railsの例に暗黙的に含まれている概念やルールの多くは、Rustコードでは型を通じて明示的に伝えられます。アクティブ ユーザーと非アクティブ ユーザーを明確に区別でき、日付フィールドの場合は、予想されるタイム ゾーンも型にエンコードされます。この表現力により、特にコードベースの初心者にとってコードが理解しやすくなり、保守性が向上します。

（2）Rustでは、他の言語（JavaやGoなどの型付き言語を含む）で一般的なエラーのクラス全体が実行時ではなくコンパイル時に検出されるため、信頼性も大幅に向上します。コンパイラは、activate 関数の activation_date パラメータに値があり、関数が返す可能性のあるエラーが処理されることを保証します。

全体的に、誰もが Rust のパフォーマンスに注目している一方で、Rust がもたらす信頼性と保守性の向上は見落とされがちです。ただし、これらの利点は、純粋なパフォーマンス数値よりも、プロジェクトの長期的な成功に関係する可能性があります。

4. 錆は最初は苦いが、後に甘くなる

Rust の主な強みは信頼性、保守性、効率性、パフォーマンスであるため、この言語の使用例は明らかにこれら 4 つの側面に特に関連するものになります。しかし、そのメリットには考慮する必要があるコストが伴います。

全体的に、Rust は他のテクノロジー、特に Web プロジェクトでよく使用されるテクノロジーと比較して、依然として高い先行投資を必要とします。

JavaScript や Ruby などの言語は結果を素早く得られるように設計されていますが、Rust ではそれほど自由度が低く、動作する結果を得るにはプログラムがすべてのコンパイラ チェックに合格する必要があります。これらの言語と比較すると、Rust を使用するにはより多くの初期作業が必要です。さらに、Rust を使用する前に乗り越えなければならない山があります。それは、Rust 独自の所有権システムを習得することです。

しかし、プロジェクトの初期段階を過ぎて、より長い期間に視野を広げていくと、保守性、信頼性、安定性などの側面が非常に重要になり、最初にRustを使用するための追加投資は、時間の経過とともに報われるでしょう。

Rust アプリケーションは信頼性が高いため、バグ修正に費やす時間が少なくて済み、メンテナンスも簡単なので、成長し変化するチームと効率的に作業しやすくなります。

結局、Rust のワークロードは最初は大きくてその後小さくなり、最初は苦くてその後甘くなることがわかります。他の言語では、その逆のことが当てはまることがよくあります。つまり、時間の経過とともにチームが拡大するにつれて、信頼性と保守性の課題の影響が大きくなり、コストが高くなり、作業負荷が増加します。

5. Rustを使用する前にいくつかの質問

Rust の強みと採用曲線に基づいて、特定の状況で Rust を選択するかどうかを評価するときに答えるべき主な質問は次のとおりです。

(1) チームにはすでに Rust の専門知識がありますか (Rust を使用していないチームの多くは、空き時間に Rust でコードを書く開発者が多いため、実際にはすでに専門知識を持っています)。

（２）信頼性の要件は何ですか？

（３）長期保守計画はどのようなものですか？

（4）構築するシステムの規模はどれくらいですか？また、Rust はホスティングでどれくらいのコストを節約できますか？

（５）上記の質問に対する回答に基づいて、追加の初期投資は価値があるでしょうか？

追加の初期投資に価値がないという結論になるケースもありますが、明らかに Rust が有利な評価になるケースもあります。私たちが目にする典型的な使用例には次のようなものがあります:

（１）製品の重要なビジネスロジックを実装する基幹業務システムにおいては、信頼性と長期的な保守性が第一に考慮される。

（２）金融システムの場合、エラーに対する許容度は一般的に低く、Rustによってもたらされる安定性の向上が決定的な要因となる可能性がある。さらに、パフォーマンスは重要な要件であり、取引システムなどの特定のシナリオでは明らかな財務的影響を及ぼします。

（3）高いスループットとパフォーマンスを提供しなければならないシステムは、明らかにRustの恩恵を受けるでしょう。複数のマイクロサービスの前にあるプロキシ サーバーなどのシステムは、オーバーヘッドを最小限に抑え、一貫したパフォーマンスを実現する必要があります。このような場合、ガベージコレクション言語とその信頼性の低いパフォーマンス特性は通常は選択肢になりません。

（4）最後に、大規模に運用されるシステムであれば、ホスティングコストを大幅に節約できる可能性があります。

Rust を使用する決定が下されたら、2 つの主な導入方法があります。アプリケーション全体を Rust で最初から書き直すか、他のテクノロジーと並行して段階的に導入することを検討するかのいずれかです。スペースの制約上、これについては詳しく説明しません。

オリジナルリンク: https://mainmatter.com/blog/2023/08/14/the-case-for-rust-on-the-web/#why