WASI vs. WASM のissueがcloseになった

難しいねぇ。

AssemblyScriptの文脈で上がってきた文字列をinterface typesでどう持つかというのもあった。

okuoku

WASMやWASIがhypeしたのは何故か

個人的には、

LLVM-IRはアプリケーション配布フォーマットとして微妙だった
WASM自体のデザインの妥当性(スタックマシン化、gotoの排除等、通常合意ベースで決めづらいところをしっかり決め、メジャーなブラウザに実装させた)
Webで使える可能性が高いのでRustやGo等もコンパイルターゲットとしてWebAssemblyを選ぶようになった

というあたりがあるだけじゃないかという気がしている。

つまり、WebAssemblyは面倒なところをちゃんとやった点に意義がある。

Write once run anywhereは一見魅力的なコンセプトではあるため多くの関心を引くが面倒くさいことをちゃんとやらないといけないという点がなかなか理解されないのではないだろうか。で、最もgenericなWASM共通規約になり得るのがWASIなので(= WASIのエコシステムに乗ることで開発コストを抑えられる可能性があるので)、WASIには本当に色々な要望があつまってくる。

例えば、暗号通貨ネットワーク向けの拡張なんてのも提案されている

が、さすがにそういうのは専用の拡張を組織している。

https://github.com/ewasm

okuoku

emscripten2native の選択

emscripten2nativeでは明示的にWASIを避けた。つまり、WebAssemblyランタイムのWASIサポートに頼らずに

自前のファイルシステムやOS抽象化レイヤをSDL2なりなんなりで実装する
WASIのような安全なinterface typesされたインターフェースを新規に開発するのではなく、Web APIのCバインディングを行うに留める

ことを選んだ。なぜなら:

WASIが通常のクライアントアプリケーション(ゲームやそのエディタ)を表現できるレベルになるにはあと数年は必要と見込んでいる
Webブラウザ上のWASIサポートは中途半端にならざるを得ない
アプリケーションの移植に必要な機能がそもそも現時点でも提案されていない & 実装される気配がない

人々は規格を着地させたがるが、たぶんWASIはまず強力なアプリケーションを何か見つけ、それに牽引させるような形でないと短期的に何かを着地させるのは難しいのではないだろうか。Emscriptenやnode.jsのような重要な実装が部分的にはWASIを実装しているのでそこを推せないか等。