やあ。Hackの深淵へようこそ。
君が今手にしているのは、ただの「PHPの型付き版」ではない。Facebook（Meta）という巨大なウェブ帝国を支え、数千万行のコードベースを高速に捌くために設計された、極めて合理的な実行エンジン「HHVM」を操るための鍵だ。
今日は、多くの開発者が「なんとなく」で済ませてしまっている、「型付けとメモリ管理の深い関係」について話をしよう。ここを理解すれば、君はもう単なるコーダーではない。HHVMの挙動を支配するアーキテクトの視点を持てるようになるはずだ。
—
1. なぜ「型」がメモリを救うのか？
多くの人は「型宣言はバグを防ぐためのもの」だと思っている。それは半分正解だが、半分は甘い。
HHVMにとって、型は「実行時の推論コストを消し去るためのガイドマップ」なんだ。
PHPのような動的型付け言語では、変数が `int` なのか `string` なのかを、プログラムが実行されるたびに確認（タグチェック）する必要がある。これには膨大なCPUサイクルとメモリ上のデータ構造が必要になる。
一方、Hackでは静的な型システムによって、コンパイル時にその変数の正体が確定する。HHVMはそれを知っているから、「型タグ」というメモリの無駄遣いを排除し、生のバイナリデータとして扱い、ガベージコレクション（GC）の負荷を劇的に下げることができるんだ。
—
2. メモリを食い尽くす「動的配列」との決別
PHPでやりがちなのが、`vec` や `dict` を使わずに、何でも入る汎用的な配列をこねくり回すことだ。これがメモリ管理における「地雷」になる。
悪い例：メモリを浪費する構造
// 何が入るか不明瞭なため、HHVMは「あらゆる可能性」に備えてメモリを確保する
function process_data(mixed $data): void {
// 構造が不安定だと、GCはこれを「複雑なオブジェクト」として監視し続け、
// メモリ解放のタイミングを遅らせる原因になる。
}
良い例：型付きコレクションで最適化
// vec
// これはCPUのキャッシュヒット率を上げ、GCのトラッキングコストをゼロにする
function process_ids(vec
foreach ($ids as $id) {
// 確実な型であるため、無駄なチェックなしに高速にアクセスできる
}
}
—
3. HSL（Hack Standard Library）の「隠れた力」
HSLへの移行を推奨するのは、単にAPIが綺麗だからではない。HHVMのJITコンパイラが最も効率的に最適化できる関数群だからだ。
例えば、古いPHPの `array_map` と、HSLの `Vec\map` を比較してみよう。
`Vec\map` は、型システムと密接に統合されており、戻り値の型が推論可能なため、HHVMは中間結果を生成せずにメモリを節約した実行パスを生成できる可能性がある。
ここがポイント：
HSLを使うことは、HHVMに「私はここを効率的に実行してほしい」とヒントを出し続ける行為なんだ。
—
4. 大規模アプリケーションで陥りやすい「型」の罠
初学者がよくやる失敗、それは「過度なNullable」だ。
// 悪い例：なんでもNullableにする
type UserProfile = shape(
‘name’ => ?string,
‘age’ => ?int,
);
`?string` はメモリ上で `string` とは異なる特別なフラグを必要とする。これが数百万件のデータになったとき、メモリ使用量は跳ね上がる。
「可能な限り型を絞る」ことは、単なる規律ではなく、メモリ節約の知恵なんだ。
—
5. まとめ：君が手に入れるべき「アーキテクトの視点」
Hackでコードを書くとき、常にこの問いを頭に浮かべてほしい。
1. 「このデータ構造は、HHVMが連続したメモリとして確保できるか？」
2. 「この型宣言は、実行時の型チェックを排除できているか？」
3. 「HSLを使って、コンパイラに最適化の余地を与えているか？」
これらを意識し始めたら、君はもうHackの初心者ではない。HHVMという巨大なエンジンを、自分の手足のように操り始めている証拠だ。
型付けは、足枷ではない。それは、君のコードを高速に、そして堅牢に走らせるための「空力性能」を上げる工夫そのものなんだ。
まずは、今のプロジェクトにある `mixed` を一つずつ、適切な `shape` や `vec` に置き換えることから始めてみよう。その小さな一歩が、数ギガバイトのメモリ節約に繋がるかもしれない。
さあ、Hackを掌握しよう。君ならできるはずだ。