wasm component model

私はこれをWASI Component Modelと呼称したいと思う。と言うのも、WASIの仕様（となるであろう）ものである為。これはブラウザでサポートされるWasm Coreの仕様の拡張みたいなもの
端的に言えば、CPUやOSに依存しない広範の言語から共通で使えるdllまたはexeみたいなのを作れる。witと呼ばれるIDLを通して「コンポーネント」というものを作り（これは1つのライブラリと考えればよいだろう）、それらは1つの実行ファイルまたはライブラリ（WASMファイル）にガッチャンコできる、という理解（おそらくダイナミックリンクも提案されている）
WITはProtobuf的な何かみたいに捉えている。現状のwasm coreは単なる数値と線形メモリを駆使して操作するが、文字列やrecordなど、WIT構文はより幅広く定義できるようになっている
wasmで扱えるようにするには、各言語でそのままビルドしたwasiファイルがそのまんま適用できるというわけでなく、wasmが扱えるようなバインディングコードを注入する必要がある。これをWITファイルを通じて行うのがwasm-toolsというツール

私はこれをtinygoで試したが、正直キツかった。まあ駆け出しのものなので仕方がない。

このwasiコンポーネントファイルをライブラリとして動作させるためには、調べたところでは現状公式ランタイムと言えるwasmtimeまたはwasmerを使うか、jcoというjavascriptランタイム向けツールチェーンを使うしかない
従って、現状は実行ファイルとして成立させるのが恐らく最も身近な使用法である
現状他言語にてライブラリ的に使用する方法は恐らくjco程度に絞られる。これを使うと、容易にコンポーネントのエクスポート関数にアクセスできるコードを生成する。あとはRust向けに何か作られてるのかな？と言うことで、Node.js・Deno・Bunあたりでしか活用できる道は現状なさそう
TinyGoで試したが、恐らく通例のGoはwasmを作成するとアプリケーション的な使い方しかできないが、WASIならライブラリ的な利用が可能であった。よって、GoでのWebAssemblyビルドはwasiコンポーネントベースでの活用のほうが将来性は明るそうである (これは新しい発見)

誤解してた。jcoのグルー生成はトランスパイルであって、そもそも現状のWASIはランタイム意外の実行ができないのか。

という感じかなあ。ちなみにWIT IDLというVS Code拡張も作られていて、徐々に状況は進行中って感じだけれども、とにかく現状はできる選択肢がキツイ。

意外にも（と言ってもBlazorあるのでそうでもないが）.NETサポートが見た感じ恐らくRustの2番手として明らかにやりやすそうで、これは.NET9で恐らくサポート予定。WASMの活用は（javascriptは別として）Rustの次にC#が来そうだと言う風に感じた。

しかし、とりあえずwasmのとっつきづらさは個人的にバインディングライブラリの不足にあると思うし、現状のコンポーネント生成も手順少なくてもメッチャ辛い感じが第一印象。。 jcoみたいなツールみたいに、あるいは通常のWASMならRustのwasm-bindgenのように、wasmからサッと取ってきて、他言語にてAPI関数をサッと使えるグルーコードを生成してほしいじゃんね。そういうやつがPythonなりGoなりに出てこないと、かなりキツイ。
今のところ多くの人にとっては、OSごとにC ABI互換のライブラリをクロスコンパイルしてバインディング、のほうが圧倒的にどの言語でもコンピュータあるいは他言語との意思疎通には手数的にも楽なことは多いと思う。例えば、javascriptでも現状hyperimportやBunのFFIサポートなどが出てきており、これはC ABI言語のみに動作するが、圧倒的に使いやすそうに感じる。

本当にツール類が充実してくれば、先述したような「CPUやOSに依存しない広範の言語から共通で使えるdllまたはexeみたいなのを作れる」が実現できるだろう。とにかくポテンシャルは間違いなくあるがツール類が…ってその1点。個人的にはZigで感じた興奮よりはちょっと冷めたげなインプレッション。まあ現状標準化のさなかなのですが、大企業が大量に絡んでいるとは言え、恐らくWasmはjavascriptフロントエンド界みたいなのと比較しても、ドンと進歩する分野ではなさそうだと思います。多分堅調な進みかたで、ケッコーかかるでしょう。しかし、これが一番なんじゃないかな。

個人的には通してCMakeのようなビルドツールが欲しい。wacはそれにあたりそうだが、ちょっとまだしんどいかなーと思う。