- スタンドアロンの静的バイナリとしてツールを配布すれば、ユーザーは開発環境やツールチェーンを別途インストールせずにすぐ利用できる
- コンパイル工程は、異常動作するコードが配布される可能性を下げる追加の安全装置として機能する
- インタープリタ言語ベースのツールは、さまざまな依存関係のインストールやディスク容量の浪費、アップグレード時の繰り返し再インストールなど保守負担が大きい
- 依存関係が多いほどセキュリティ脆弱性や攻撃対象領域が広がり、ハッキングのリスクや保守上の問題が発生しやすい
- コンパイル言語ベースの静的バイナリは外部環境の変化の影響を受けないため、配布後も安定した使い勝手を保証できる
スタンドアロンの静的バイナリ配布の利点
インストール不要ですぐ使える
- Open AIがCodexをRustで再構築し、TypeScriptを捨てた事例のように、コンパイル言語で書かれた単一バイナリを配布すれば、ユーザーは追加のツールチェーンを入れずにすぐ実行できる
- 最大の利点は速度や効率ではなく、インストールなしですぐにツールを使える点にある
コンパイラによる追加の安全装置
- コンパイル段階での検査により、異常なコードが配布される可能性が低くなる
- 例としてGoogle Cloud CLIはPythonベースで、何度も実行不能な状態で配布されたことがある
- 大規模チームでもこの種の問題を避けるのは難しく、小規模チームがインタープリタ言語ベースのツールを安定して配布するのはさらに難しい
ツールチェーンへの依存が不要
- コンパイル言語ベースのツールは単一バイナリだけを配布すればよいが、Python、Ruby、TypeScriptなどのインタープリタ言語のツールは必ずその開発環境が必要になる
- Rubyで書かれたmdl(markdown linter)のように、開発環境(Ruby)がアップグレードされるたびに再インストールが必要になる
- JavaScriptベースのmarkdownlintを使う場合は、npmおよび44個以上の依存関係のインストールが必要
ディスク容量の無駄の問題
- 人気のFOSSコーディングアシスタントaiderはPythonで書かれており、Homebrewでインストールすると追加で51個のパッケージが入る
- 実際のディスク使用量は3GiB以上増え、これは大半のLinuxディストリビューションの容量より大きい
- 一方、Rustで書かれたuvパッケージマネージャは35MiBの単一バイナリだけでインストールでき、Rust本体やrustupも不要
セキュリティ脆弱性の増加
- ツールの依存関係が増えるほど攻撃対象領域が拡大し、セキュリティ脆弱性にさらされる可能性が高まる
- OpenAIのCodexパッケージには、24個の直接依存と184個の間接依存が存在する
- たとえOpenAIがすべての依存関係を監査していても、依存関係のバージョンが固定されていなければ、今後の更新によって脆弱性、悪意あるパッケージ、動作停止などの問題が発生しうる
保守のしやすさ
- JavaScript、TypeScript、Pythonなどのインタープリタ言語ベースのツールは、依存関係が削除されると動作不能になる
- left-pad事件のように、単一パッケージの削除で大規模なサービスやツールが麻痺することがある
- コンパイル言語はビルド時点でのみ依存関係が必要なため、その後で外部リポジトリが消えてもツールは引き続き正常に動作する
筆者の経験
- adb-enhancedなど、過去にはPythonでツールを作っていたが、その後はGoでgabo、wp2hugoなどさまざまなツールをオープンソース化した
- PythonやTypeScriptなどでスタンドアロンツールを開発することは、もはや考えていない
- 必ず**静的リンクされたバイナリを配布できる言語(Rust、Go、C++など)**で書くことを勧める
結論
- スタンドアロンツールはRust、Go、C++などのコンパイル言語で開発する
- 外部依存を最小限に抑えた静的バイナリの形で配布すべき
3件のコメント
ディスク容量の無駄の問題についてはかなり共感せざるを得ないですね...AKS を運用していますが、コンテナイメージ容量が 1GB を超える Python アプリを見るたびに頭が痛くなります。
今はとりあえず Dockerfile を持ってきて自分で容量を削って上げ直していて、500MB 以下にできなければそのまま諦めます(笑)
pytorch+cuda依存関係で、バージョン違いだけで引っかかるパッケージがあって……本当にひどいです。大した機能もないのに、小さなデーモンごとに依存関係が2GB近く入ります……
単純な推論用に使うCPUランタイムならまだ少しはマシですが、最近求められるLLMサービスのせいで、トラフィックもトラフィックなりに、容量も容量なりに増えていくので、コスト計算するときは悪態をつきたくなります(笑)