かなり雑に書いてるので、雑に読んでください。
Bun が Zig で開発されていることを知り、そこから Zig を調べてみています。
調べていくと自分が求めていた言語っぽいというのがあり、社外では学生に QUIC や TLS 1.3 を Zig で OSS を開発してもらうお仕事を出したり、社内では実際に採用に向けて調査を進めています。
そもそもの目的
自分の会社では Erlang VM を利用した製品をメインに利用しています。ただ Erlang VM 遅いんです。少なくとも暗号処理であれば Rust の方が 2 倍ほど速いです。Erlang VM 自体 JIT を採用したり、いろいろ頑張ってくれているのですが劇的な高速化というのは今すぐには難しいのが現実です。
そこで NIFs (Native Implemented Functions) を使って頑張るという戦略があります。早い話が Erlang VM の C 拡張です。C で落ちないコードが書ければいいのですが、残念ながら自分はそんなスキルは持ち合わせていません。そのため、今の製品では C 拡張は一切利用せず、すべてピュア Erlang で書いています。
ただ今後 QUIC や HTTP/3 、WebTransport といったプロトコルを利用した製品を開発する場合はErlang VM だけでは厳しいと感じています。実際に eBPF (extended Berkeley Packet Filter) やら GSO (Generic Segmentation Offload) や io_uring を触る可能性がありますが、 Erlang VM では今のところ触れません。
そこで NIFs を利用してプロトコルの write/read 部分は NIF で書いた処理を利用し、それ以外を Erlang VM で処理するというのを考えていました。
ただ C/C++ は自分にはしんどいな … となっていました。
Erlang NIFs に Rust を検討していた
最初の候補は Rust を NIFs として扱う Rustler というのがあり、これと Quiche を組み合わせ作り込んでいく予定でした。
ただ、せっかくだから QUIC や WebTransport は自前実装で行きたいという気持ちはぼんやりとあり続けました。Google はもちろん AWS 、MS 、Fastly、Cloudflare、Meta、Apple がそれぞれ自前実装をしています。最近 HTTP/3 に対応した HAProxy も自前です。
つまり QUIC は「自分たちにあった QUIC 実装」というのを持った方がビジネス的にも良いのではないか？と思い始めました。
実際、 WebRTC の自前スタックを持って製品を開発し、販売したことはビジネス面で大きなメリットでした。
最終的には会社が経営的に余裕があることから、時間をかけてでも自分たちにあった QUIC 実装を持った方がいいと判断に舵を切りました。
そこで Rust で QUIC を自前で実装するかーと考えていろいろ調べたりはしていました。偶然、会社に Rust ﾁｮｯﾄﾃﾞｷﾙ がいるので相談したりしていました。そんな時に Zig が候補として登場したという状況です。
Zigler を見つける
すでに Erlang VM + Zig を試している人が居たのが大きいです。
これで、間違いなく動くことは保証されました。あとは Zig に自分が必要な機能が足りているかどうかです。
暗号ライブラリ
Zig はなんと std.crypto で暗号ライブラリがとても充実しています。これも決め手の一つです。暗号ライブラリの作者が libsodium の作者というのもぐっときます。
一通りそろっています。これは素晴らしい、採用検討しようとなりました。
async/await と multithread
マルチスレッドもサクッといけそうです。非同期処理周りはまだまだ課題はありますが、epoll / kqueue さえ動けば不満はないです。io_uring はまだ先かと思っています。
Wasm / WASI 対応
Zig は今時の言語っぽく最初から Wasm や WASI への出力に対応しています。今は、ブラウザで音声や映像を処理する場合は Wasm がほぼ必須となってきています。
特にブラウザで End to End Encryption の実装をする場合は Wasm 以外の選択肢はありません。現在は暗号ライブラリが充実している Go を利用して実現していますが、今後は Zig に切り替えられればと考えています。
また Edge Worker では WASI の動作を前提としていく流れは止められないと思っており、WASI が利用できるようになるのもとても楽しみです。
Zig の暗号ライブラリの作者は WASI 向けの暗号ライブラリを作っていたりもします。
Zig には性能と書きやすさを期待
すくなくとも Erlang VM よりは早いですし、自分にとっては書きやすいと感じています。
- std ライブラリ以外は利用する予定がないのでパッケージマネージャーは不要
- build.zig はよくできている
- コードがとにかく読みやすいので困ったらコードを読むが苦じゃない
- メモリ管理を独立させるという考え方がとても良い
- 今後もシンプルさを維持してくれそう
自分が Zig に期待するのはこの辺りです。
今後
まずは学生に QUIC と TLS 1.3 の実装を進めて貰いつつ、自分たちも一緒に学んでいこうと思います。開発課程は https://discord.gg/shiguredo で公開して進めていくので興味ある人は見てみてください。
Erlang VM + Zig での QUIC 実装（最終的には WebTransport) もゆっくりですが進めていきます。Rust も意識しつつまずは Zig に投資という状況です。
Rust じゃダメなんですか？
ダメじゃないです。むしろプロトコル界隈は Rust が多いです。Cloudflare と AWS は Rust で QUIC を実装しています。最近では Google も Android 向けの DoH over HTTP/3 は Rust (Cloudflare の Quiche) を利用しています。
単に Zig の方が自分の目的にとってはよさそうに感じている以上の理由はないです。失敗して誰から怒られるわけでもないので自分の好きなように技術選定しています。
