Wasm 1.0 (and 2.0) is a fairly straightforward portable assembly.

It's a great target for a simple language (unless you insist on someone else doing your GC for you, which mandates their design on your language).

And it's also fairly easy to build a Wasm interpreter, or an AOT compiler.

> Wasm 1.0 (and 2.0) is a fairly straightforward portable assembly.

It's also largely useless outside of targeting c/c++ and derivatives. Most code we write cannot target wasm without severe drawbacks.

This is about the same as saying that the x86 or ARM instruction sets are largely useless outside of targeting C/C++ and derivatives...

Not at all. It's much more efficient to implement a GC on x86 or ARM than it is on Wasm 1.0/2.0, because you control the stack layout, and you don't have an impenetrable security boundary with the JS runtime that your GC needs to interop with.

Not to mention the issue that bundling a GC implementation as part of your web page can be prohibitive in terms of download size.

Tbh I never understood nor cared why people would want to use a garbage collected language with WASM in browsers when there's already Javascript. One of the main points of WASM was to avoid GC overhead alltogether (thus the 'garbage-free' subset asm.js which then became WASM).

WASM is not nearly as capable as either architecture.

But.... they would certainly be much more useful architectures and devices if they chose to cater more to actual needs rather than performance under C/C++

The same to applies to the languages, which prioritize speed over reducing bugs.

What's “not capable” about it? Isolating code and data?