テクニカル諏訪子: 【プログラミング】C、C++からRustに書き換えなくた方が良い

2022年、IT業界全体でC、C++、Go、PHP、Python、Java、C#、Swift等、全てのコードベースをRustに書き換えようという大きな動きがありましたが、幸いにも失敗に終わりました。
2023年になると、この動きは政府レベルにまでエスカレートし、幾つかの政府機関がRustへの書き換えを推奨し始めた事で、益々怪しく感じる様になりました。
あたしは直ぐに、Mozillaが政府に多額のお金をばら撒いて、Rustの宣伝をさせているのだと感じました。
というのも、政府が関心を持つ理由は常にそれしかないからです。
現実には、Rustへの書き換えは持続不可能です。

Rustの問題点

Rustという言語その物には特に問題はありません。
言語自体は悪くありません。しかし、問題は次の2点です：

コミュニティが非常に毒性が高く、精神的に不安定な人々に満ちている事
背後にある企業（Mozilla）が極端な左派政治に深く関与しており、人々が求めている技術よりも、グローバリストの人口削減アジェンダ（LGBTやヴィーガニズム等）を推進する事に多くの時間を費やしている事

現在、ドナルド・トランプが再び選挙に勝利し、不正に利用される郵便投票がなくなった事で、8年間も極端な左派の政治的正しさを支持していた多くの企業が、突如として活動家の姿勢を捨て、再び顧客重視に転じました。
しかし、Mozillaはこの活動家を諦めたくなさそうですが、Googleに対する最近の訴訟の結果、2025年8月以降はGoogleからの資金提供がなくなる事が明らかとなった今、彼らはウェブブラウザやメールクライアントの開発よりも、行動主義とAIに重点を置くと明言しました。
もしFirefoxやThunderbirdのメンテナンスを停止するのであれば、Rustのメンテナンスも停止する可能性はどれ程高いと思いますか？

一つの解決策は、Bell LabsがCやC++で行った様に、これらをパブリックドメインで利用可能にする事です。
しかし、CやC++とは異なり、RustはCargoという中央集権的なインフラに大きく依存している為、それが実現する可能性は低いです。

C、C++、JavaScript、Java/Kotlin、C#、PHPには依存関係のインフラはありませんが、サードパーティの依存関係マネージャが存在し、開発者はそれを使わない選択も出来ます。
GoやZigのインフラは非常に分散化されている為、所有者はいますが、依存関係はGitリポジトリに依存しており、それがGithubである必要はなく、また開発者はそれを使わない選択も出来ます。
Rustは違います。
Rustは中央集権的な依存関係インフラに依存しており、Rust標準ライブラリが極めてミニマルである為、それを使わざるを得ない可能性が非常に高いのです。

タスクに最適な言語を使用する

あたしのコードを読む人は、殆どCとGoしか使わない事に気づくでしょう。
しかし、あたしはC++、Lua、PHPも使用します。
ターミナルで動作するプログラムを作るのにC、ウェブバックエンドを作るのにGo、ゲームエンジンを作るのにC++、そのゲームエンジンでゲームをスクリプト化するのにLua、そして正社員として働いている仕事でPHPを使っています。
更に、C++を使ってFLTKでGUIプログラムを作る事にも取り組んでおり、非常に驚いた事に、あたしはそれを本当に気に入っています。

あたしが言いたいのは、誰もがあたしが使っている全ての言語を使う必要はないという事です。
しかし、それらに少なくとも触れておく事で、他人に頼るのではなく、自分で機能を書く重要性を学び、感謝する事が出来るという事です。
現在の殆どの開発者は、生計を立てて給料を稼ぐ為にプログラムを作っていますが、こうした開発者であっても、ゼロから機能を書く事を学ぶ事は長期的に見ても価値があります。
何故なら、理解出来ないセキュリティホールを閉じる時間が減り、新しいコードを書く時間が増えるからです。

手動でメモリチェックを行う習慣を身につけよう

Rustの最大の売りは、メモリ安全性と借用チェックです。
これは非常に便利で、一見すると素晴らしいアイデアの様に思えますが、致命的な欠陥があります。
コンパイラがメモリ安全性を保証してくれる事に慣れ過ぎると、コンパイラがメモリ安全性をチェック出来なくなった時に、非常に深刻な問題に直面する事になります。
コンパイラは人間が作った物であり、人間は必ずミスをする可能性がある事を忘れないで下さい。

CやC++の開発者は、殆どの事がデフォルトでは抽象化されていない為、何が起きたのかを把握し、それを解決する能力があります。
一方で、Rustの開発者はRustコンパイラの開発者に大きく依存する事になります。
そして先程述べた様に、Mozillaが来年には技術企業から活動家集団に変わろうとしている以上、この知識は誰も引き継がなければ失われてしまうでしょう。\

その結果、経済全体を崩壊させる様な深刻なエクスプロイト（例えば、数ヶ月前にCrowdStrikeで見られた様な物）が発見された時、その問題を修正出来る人がいなくなるでしょう。
これは、Mozillaが技術企業でなくなった途端にこうしたエクスプロイトが発生するという意味ではありません。
こうしたエクスプロイトは、多くの場合、発見されるまでに何年もかかる物です。
例えばLinuxカーネルを見てみると、多くのエクスプロイトが何年も、時には20年以上もカーネルに存在し、最近になって漸く発見される事がよくあります。

Rustが失敗しないとしたら？

若い世代の人々は覚えていないでしょうが、あたしは2010年に何が起きたかをまだ覚えています。
当時、全てのPHPコードをRubyに書き換えようという大きな動きがありました。
Rubyの方が遥かに優れていると言われていたからです。
しかし数年後には、Rubyの方がPHPよりも更に酷い事が明らかになりました。
PHPからRubyへの移行は、トランスジェンダーになるに例える様な物でした。
後悔が来た時には、引き起こされた損害を元に戻すにはあまりにも遅過ぎたのです。
そしてRubyが衰退する中、PHPは大きく改善されました。

CとC++の標準は3年ごとに変更されます。
Cは殆ど変わりませんが、C++は毎回多くの改良が加えられています。
一方でRustは常に変化している様に感じられ、ついていくのが難しいと感じます。

従って、Rustも同じ運命を辿ると考えています。
現実的に言えば、CとC++が再び人気になる事はないでしょう。
Rubyが衰退した時、人々はNode.js（Javascript）やDjango（Python）に移行しました。
しかし、Rust開発者がZigやOdinの様なコミュニティが管理する言語に流れる、或はJaiが最終的に登場した時にそちらに移る可能性が高いと予想しています。

全てのトレンドと同じ様に、Rustも最終的には失敗するでしょう。
特に、これ程時間が経ってもRust開発者を求める企業が殆どないという事実は、このトレンドがどう終わるかを物語っています。

アセンブリを学ぶべきか？

絶対に学ぶべきです！
例え職業で使う事がなくても、アセンブリを読んで理解する能力は、高水準言語やフレームワーク（Laravel、Django、React）、エンジン（Unity、Unreal、Godot）、デプロイツール（Docker、Kubernetes、Nix）に依存する事で失われつつある現状で、非常に重要で求められるスキルとなるでしょう。
但し、アセンブリはアーキテクチャに依存している為、プロセッサやオペレーティングシステム、コンパイラごとに異なります。

先ず最初に、MIPS o32とRISC-V 64のアセンブリを学ぶ事をお勧めします。
これらは最も簡単だからです。
その後、PowerPC、SPARC、ARM64のアセンブリを学ぶとよいでしょう。
これらは少し難しいですが、未だ簡単な部類に入ります。
最後に、Intel/AMD、ARMv7、ARMv8のアセンブリを学んで下さい。
これらは最も難しいからです。

あたしはLinux上のMIPSのアセンブリに最も詳しいので、以下はその例です：

.section .text

.global __start

__start:
  li $v0, 4004    # 書き出し
  li $a0, 1       # STDOUT
  la $a1, prompt  # 文字
  li $a2, 15      # 長さ
  syscall         # 実効

  li $v0, 4003    # 読み込み
  li $a0, 0       # STDIN
  la $a1, buffer  # 文字
  li $a2, 128     # 長さ
  syscall         # 実効

  move $t0, $v0   # 長さの保存
  la $t1, buffer
  add $t1, $t1, $t0
  lb $t2, -1($t1)
  li $t3, 0x0A    # ASCIIでの「\n」
  beq $t2, $t3, rmnl # 最後の文字は「\n」だったら、削除する
  j printgreet

rmnl:
  addi $t0, $t0, -1

printgreet:
  li $v0, 4004
  li $a0, 1
  la $a1, greeting1
  li $a2, 18
  syscall

  li $v0, 4004
  li $a0, 1
  la $a1, buffer
  move $a2, $t0
  syscall

  li $v0, 4004
  li $a0, 1
  la $a1, greeting2
  li $a2, 8
  syscall

  li $v0, 4001    # 終了
  li $a0, 0       # C言語で「return 0;」みたいな感じ
  syscall

.section .data
  prompt:    .asciz "お名前は？ "
  greeting1: .asciz "こんにちは、"
  greeting2: .asciz "さん\n"
  buffer:    .space 128

コンパイルするには：

$ mips-linux-musl-as main.s -o main.o
$ mips-linux-musl-gcc main.o -o main -nostdlib -static
$ qemu-mips ./main
お名前は？諏訪子
こんにちは、諏訪子さん
$

RISC-Vの例もお見せしたかったのですが、正しく動作させる事が出来ませんでした。
未だ十分に慣れていませんが、MIPSとそれ程大きな違いはないはずです。

以上