Rust 仕事 ない
おことわり
この記事は私がRustを書く仕事を探しているのであれば教えてほしいといった趣旨の記事ではありません。
タイトルの内容をいざTwitterで呟こうものならどこからともなく転職エージェントが現れ高単価案件を紹介するというホラを吹いたり、うちはRustを書いている、ちゃんと探したのか、みんなRustを書いている、そんなにRustを仕事にしたいなら起業したらどうだといったいくつかのクソリプに収れんされていきます。
こういったワンパターンの流れが毎年のように繰り返され、うんざりしています。
この記事ではなぜRustの仕事がない状況が続いていて、どうすればRustの仕事がある状況を作れるのかという状況分析をしていきたいと思います。
若干Rustについてネガティブな書き方をしてしまうかもしれませんが、Rustが良い言語か、悪い言語かといった話はしません。
仮説1：Rustが本番環境で使われていないから
それはそう。
でもよく考えてみてください。
どんな言語も登場した後すぐ本番環境で使われてきたケースなんてものは、存在しません。
JavaScriptがIEに搭載された頃はありとあらゆる脆弱性を悪用してWebブラウザに過度な負荷をかけるブラクラが発生したものですから、インターネットに接続するときはJavaScriptの機能をオフにしましょうなんていうマナーが存在していたぐらいです。
今では考えられないですね。
プログラミング言語は公開した後に様々な問題を解決していき、パッケージをはじめとしたエコシステムを発展させていって初めて本番環境で使われるわけですから、少なくとも10年以上継続して発展していったRustが本番環境に適していない理由は現時点では見当たらないように思えます。
仮説2：Rustのユースケースが存在しないから
これもよく見る理由の一つです。
Rustのユースケースは他のプログラミング言語でも代替可能で、他のプログラミング言語のほうが優れているケースが多いです。
一例としては以下のようになります。
- CLIツール: JavaScript (TypeScript), Python, Go
- デスクトップアプリ: C#, Java
- スマートフォンアプリ: Swift, Kotlin, Dart
- Webアプリケーション: PHP, Ruby
- 組み込みアプリケーション: C, C++
RustはよくDenoやuv, Rolldownのようなワンバイナリで動くCLIツールで使われることが多いですが、実務では社内ツールの配布しやすさよりも、開発・改修スピードが重視されるため、ワンバイナリで動くCLIツールを内製するケースは少ないでしょう。
似たような問題を抱えている言語でGoがありますが、GoとRustの違いは何でしょうか？
おそらくビルドの速度が大きいように思えます。
Goはスクリプト言語のようにすぐコードを実行することができますが、Rustはコード量や依存関係が増えれば増えるほどビルド時間がどんどん長くなるので、スクリプトのような用途に向いていません。[1]
一方RustはGoを始めとしたGCやVMを持つプログラミング言語と異なり、組み込みアプリケーションでも使える優位性を持っています。
しかしながら組み込みアプリケーションの大半はHALやドライバのようなC/C++の資産がものをいう世界なので、例えRustのFFIを使ったとしてもすでにあるC/C++を置き換えるメリットは存在しない状況です。
仮説3：無給でもRustを書きたい人と、Rustを書いて大金をもらっている人の温度差
無給でもRustを書きたい人はたくさんいると思います。
FOSS開発者の私もそうです。
RustはFOSS開発者の中で爆発的に普及してしまったがために、お金を稼ぐためにコードを書くマインドを手放しぎみのように思えます。
例えばJavaやC#はお金を稼ぐためにコードを書くエコシステムが露骨に現れています。
結果としてLog4jのような、どこかの無名の誰かが感謝もされずに維持し続けているプロジェクトが支えている事例もあったりしますが、[2]とにかくお金を稼ぐマインドセットがどこかにないとビジネスにすらなり得ないということです。
一方最近はGAFAMのようなビックテックやCloudflare, OpenAIのような成長著しい企業が優秀なRust開発者を獲得するためにものすごい額の求人を出すようにもなっています。
このようにRustの市場はあまりにも極端になりすぎて、「JavaやC#のようにある程度コードが書ける人が実務経験をつんで、その経験をもとに様々な現場で働く」というキャリアプランを断念した人がひたすら無給でRustを書き続けるという悪循環を生み出しつつあります。
またGoとの比較になってしまいますが、日本でGoを採用する企業はなぜかお金をたくさん持っていたりするので、ここまで極端な市場構造にはなっていないように思えます。
ではどうすれば？
ここまで私が手を動かして文章を書いてきましたが疲れてしまいましたので、Gemini 3.1 Pro Previewにアイデアを出してもらいたいと思います（老化だ）。
案1：別言語の「裏方（モジュール）」としてRustを忍び込ませる
いきなり「100% Rustのプロジェクト」を立ち上げるのはビジネス上のリスクが高すぎます。
しかし、Node.jsの重い処理をNAPI-rsでRust化する、Pythonのデータ処理をPyO3でRust化する、といった「既存言語のパフォーマンスボトルネックをRustで解決する」というアプローチなら、普通の企業でもRustのユースケース（＝求人）を作ることができます。
🤔筆者コメント：このアイデアはいいですね。以前応募した、とある地図の企業でも採用されていました。[3]
ただ私は「求人サイトでRustをほとんど見かけない」ことをきっかけとして記事を書いているので、すでに別言語の経験をもとに入社した人や上司がこのアイデアを採用してくれるかどうかは微妙なところです。
記事でも軽く触れましたが、Rustはビルドに時間がかかるので、Rust単体で書いた時と、Node.jsやPythonに組み込んだ時で第一印象が結構変わりますし、ユースケースを解決できる言語がRustしかないのか気になるところです（Node.js+GoやPython+TypeScriptでも十分なケースも多いので）。
案2：Wasm（WebAssembly）やエッジコンピューティングの普及を待つ
Cloudflare Workersに代表されるようなエッジ環境や、Wasmの領域では、GoやTypeScriptよりもRustが第一級市民になりつつあります。
この「Rustでしか（Rustが一番）上手くやれない領域」が一般的な企業に降りてくるまで、エコシステムの成熟を待つ必要がある、という結論です。
🤔筆者コメント：Rust+Wasmについては私も長いこと追っていて、最近はWado[4]というプログラミング言語を触っているぐらいなのですが、ブラウザで動かすWasmについてはC/C++の資産をEmscriptenでコンパイルして持ち込むケースが大半で（SQLiteなど）、Wasmで新たに書いてもユーザーがメリットを感じないことが多いです。
エコシステムの成熟を待つ必要があるというのはWASIを見ればそうだなって思うのですが、その頃もRustが第一級市民であり続けるかは懐疑的です（RustというよりRustで書かれたWasmtimeによって支えられているので）。
案3：「メモリ安全性」や「省電力性（グリーンIT）」が金になるルールの登場を待つ
アメリカ政府が「C/C++を使わずメモリ安全な言語を使え」と勧告を出したように、「安全ではないコード＝コンプライアンス違反・ビジネスリスク」とされる時代が来れば、企業は嫌でもRustにお金を払うようになります。
また、サーバーの電力コストを下げるためにRustが選ばれるケースもあります。
🤔筆者コメント：これはバイデン大統領の頃言われていた話ですね。[5]
ただRustを少しやっていれば分かると思うのですが、Rustのメモリ安全性はunsafeキーワードによっていとも簡単に崩れていきますし、安全ではないコードを評価する人（レビュワーや上司）がC/C++が危険なことを認め、Rustを完全に理解したうえで安全だと判断するまでのハードルがめちゃくちゃ高いです。
Clippyをうまく使いこなせばある程度安全なコードを書けるようになりますが、そもそも安全なコードとは何ぞやって話になりそうですね。特に生成AI時代においては。
案4：結論「無理してRustを仕事にする必要はない」
RustはFOSSの世界で楽しく書き、仕事はお金の稼げる言語（GoやTypeScriptなど）で割り切って稼ぐ。
「好きな言語と稼げる言語は別」という、ある種の諦めと悟りのキャリア戦略を提案するのも、一つの誠実な結論だと思います。
🤔筆者コメント：は？
-
一応RustにもCargo Scriptというスクリプト用途で使える機能がnightlyに存在します https://zenn.dev/tkithrta/scraps/2d9ac39a2f569c ↩︎
-
A project some random person in Nebraska has been thanklessly maintaining since 2003. https://xkcd.com/2347/ ↩︎
-
https://www.cisa.gov/sites/default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf ↩︎
Discussion
c#→デスクトップは
どちらかと言うと間違いかな
メインはWebだと思います
少し、振り分けが古いような
Rustは安全性は高いけど普通に難易度高いし、お手軽に置き換えようとはなりにくいんですよね。
文中でも述べられてる通りユースケースが存在しないというのもある。既にあるC++プロジェクトを置き換えたいと思ったこともあるけど現状ほぼ安定しているので、Rustのメリットである安全性が活かせない（そのままでもほぼ安全）
新規プロジェクトで使うのはありだと思うけど、そもそもC++で書くようなプロジェクトが自分はあまりない。
Tauri使えばDesktopアプリもイケるけど…別の技術の方が楽では？っていう感じがする。
C / C++ を安全に書ける人にとっては Rust はそこまで難易度の高い言語ではないと思いますけどね
弊社では本番環境でもモバイルのバックエンドAPIにRust使っています
cargo-lambda を使ってaxumをlambdaでサーバレスに動かしています
が、やはり仰る通りビルドが遅いです！！
大変ありがたいことにRustのビルド高速化については検索してヒットするように、いくつか記事を書いてくださっている偉大な方々がいらっしゃいます
それに倣おうとするものの、Github Actionsでビルドするにはビルドキャッシュが重くなりすぎて運用上なかなか過酷であり、現状騙し騙しで運用しています（ド浅学ながらこの辺の苦労をいつか記事にしたいなぁとも思っております。）
ビルドキャッシュのサイズはどうしようもないので、キャッシュをs3に逃がしたり、いっそMac miniか何かでオンプレなSelf hosted runnerを建てたり……
そうした努力をする必要がありそうに思っています
「この辺の改善にかける時間/お金があったらいっそRustの既存コードをGoあたりにmigrationしたほうが幸せなのでは……」と悩みつつ、なにかRustから逃げるようで嫌だなぁという意地で現状維持を続けています。トホホです
Rustの仕事が無いというのは本当にその通りで、私が転職できない理由の1つにもなっています。
現職ではBlackBox目的関数の組み合わせ最適化問題をよく扱っていて、これは明確にRustが最も適していると思える領域です。
現状Rustの仕事はまだ少ないですが今後もっと増えていくよ、という記事を書きました。
よかったら読んでください。