> It's not fast.

My emulators here have roughly the same performance as the same code compiled as native executable (e.g. within around 5%) - this is mostly integer bit twiddling code. Unless you hand-optimize your code beyond what portable C provides (like manually tuned SIMD intrinsics), WASM code pretty much runs at native speed these days:

https://floooh.github.io/tiny8bit/

This post is actually a joke, but it does bring about an important point: For an interpreter, having more information results in faster execution. WASM is much closer to Java bytecode than you might think, and SpiderMonkey/V8 are basically the JVM. WASM also undergoes multiple different stages and kinds of JIT compilation in most browsers, and detailed type and usage information helps that produce faster execution.

Also, don't forget that WASM is designed to replace JavaScript, thus it must interoperate with it to smooth the transition. Rosetta and Prism also work to smooth the transition from x86 -> ARM, and much of the difficult work that they do actually involves translating between the calling conventions of the different architectures, and making them work across binaries compiled both for and not for ARM, not with the bytecode translation. WebAssembly is designed to not have that limitation: it's much more closely aligned to JS. That's why it wouldn't make sense to use a subset of x86 or similar, as it would simply produce more work trying to get it to interface with JavaScript.

> We would be better off standardizing on a subset of x86 and writing translators to arm etc. Or standardize on arm and translate to x86.

This is basically what Native Client (NaCl) was, and it was really hard to work with! We don't use it anymore and developed WASM instead.

The types are there for garbage collection, which is there for integration with the Web APIs which are all defined in terms of garbage collected objects.

> It's not fast.

Not disagreeing with you, but here’s an article from Akamai about how using WASM can minimize cold startup time for serverless functions.

https://www.akamai.com/blog/developers/build-serverless-func...

I guess you didn't read to the end?

> Friends, as I am sure is abundantly clear, this is a troll post :)

I mean standardizing on an x86 subset would replace wasm's native portability with a kind of 'emulated' compatibility, and this is one of wasm's strengths. If we do that, non-x86 hardware(mobile etc.) will pay the translation tax. So, keeping Wasm agnostic makes more sense anyway.