WASI 0.3がリリース！次世代WebAssemblyの標準化がさらに加速

ついにWASI 0.3が公開されました。以下のリンクからリリースノートおよび詳細な変更点を確認できます。WebAssemblyのポテンシャルをさらに引き出す今回のアップデート内容をぜひチェックしてみてください。詳細はこちら: https://github.com/WebAssembly/WASI/releases/tag/v0.3.0

これに関しては好きでもあり嫌いでもある。どうやって追えばよかったんだ？頑張ってみたけど、2年近くほぼ何も公開されてなかったし。3月に最後に確認した時も、全く進んでないように見えた。

だからwasiv3についてはかなり疑わしいんだよね。面白いことに、私はすでに約束（promise）のいくつかを実装済みだけど、カスタム統合されたスタンドアロンのwasmこそがより現実的な未来だと思ってる。

WASIコンポーネントという約束は果たされていない。市場は成果物を動的にホットロードしたりリンクしたりしたいんだ。でもWASIプロジェクトの方は、それを使うために専門的な魔法みたいな知識が必要で、結局デプロイ前に静的にリンクしないといけない。これじゃユースケースの99%が台無しだよ。

こういう開発を陰でこっそり進めるのは正直気に入らないな。

過去にWASIを使ったことがあるなら、どんな用途で使ったか教えてもらえる？コンテナやVMのような他のサンドボックス環境と比べて、WASIならではのメリットがあったのかすごく興味がある。

.tar.gz をダウンロードしたくないなら、今回のリリース内容（.wit インターフェースファイル）はGitHubで直接見れるよ：https://github.com/WebAssembly/WASI/tree/v0.3.0/proposals

方向性が違う。WASIはシンプルで安定しているべき。当初はシンプルなUnixライクなAPIモデルを中心に回っていて完璧に近かった。それなのに、今は意見の分かれるコンポーネントモデルなんてものを持ち込んでいて、WebAssemblyの仕様に含めるべきではなかった不必要な複雑化だと個人的には思う。

本当のコンポーネントモデルというものは別個に開発されるべきで、特定のエコシステムに盲目的に縛られるべきじゃない。そうでなければ、異なるエコシステム間での容易な相互運用性を提供するという本来の目的が完全に失われてしまう。

なぜWebAssemblyの委員会が、CORBAのような化け物をねじ込むことが受け入れられるアイデアだと思っているのか理解できない。WebAssemblyはもっと身軽で高速であるべき！余計なものは他の技術で実装すればいいし、そうすべきだ。

WASI 0.3.0向けにコンパイルするプログラムで、今回の変更点をどう使うかを示したZigのコード例ってどこかにある？

みんな、Bytecode AllianceのブログでWASI 0.3の発表記事を公開したよ：https://bytecodealliance.org/articles/WASI-0.3

今のリンクはリリースノートだけでインターフェースレベルの変更しか網羅していないけど、発表記事の方ではWASI 0.3の新しい点、WASI 0.2との違い、具体的な例などをもっと詳しく説明しているよ。

タイミングが良すぎて笑う。ちょうど先週、WebAssemblyとWASI 0.2について調べたばかり（https://jsdw.me/posts/wasm-components/ ）で、まだしばらくは0.3なんて来ないだろうって思い込んでたから！

ツールが整って、Rustでwasi 0.3ターゲットが使えるようになったらしっかりチェックしてみるよ。

WASIモジュールが自分自身のカスタムセクションをイントロスペクション（自己検査）できたら最高なんだけどな（それ以上の introspect もできればもっといい）。でも、うまいやり方がどうしても思いつかない。一部のユースケースではかなり便利な機能だと思うんだけど。

昨日話題になってたこれも参照しておいて：

https://news.ycombinator.com/item?id=48448083

“The Road to the WASM Component Model 1.0” (bytecodealliance.org)

95ポイント | emschwartzによる投稿 | 99コメント

スタックフルな非同期実装はスタック切り替えのプロポーザルを使っているの？既存の実装に後付けするのは非常に難しいから、ほとんどのランタイムでは未実装で、wasmtimeのx86_64 Linuxでしか使えないんじゃないかと思ってたんだけど。