One of the big issues for a WebAssembly-First programming language becoming big is that Rust is already has a very good WebAssembly story, being a direct compiler supported target.
In addition, WebAssembly was designed to be able to run languages like C and C++ (and Rust) efficiently, and so does not have built in garbage collection.
Thus a language that wants to be WebAssembly first, is either going to have to bring in a garbage collector, have safety with something very similar to Rust's borrow checker (in that case, it would be similar complexity to Rust), or else put the burden on the programmer for safety like C and C++ (in that case, what is the advantage over them).
My x86_64 and ARM CPUs were also designed to able to run languages like C and C++ (and Rust) efficiently, and so does not have built in garbage collection.
Wasm 1.0 did not include garbage collection, but there is a lot of effort right now by many people to add it (that is what I work on myself currently).
Once wasm has GC, languages like Grain will be able to save a lot on code size, and have some advantages over the "first set" of wasm languages (C/C++/Rust/Zig/etc., all using linear memory), like smaller sizes, less memory fragmentation, and properly collecting cycles with JS.
Rust doesn't have first class WASM support. It lacks many things Emscripten provides to C++. I'd say C++ has first class support for WASM. Very straightforward to get start!!
In addition, WebAssembly was designed to be able to run languages like C and C++ (and Rust) efficiently, and so does not have built in garbage collection.
Thus a language that wants to be WebAssembly first, is either going to have to bring in a garbage collector, have safety with something very similar to Rust's borrow checker (in that case, it would be similar complexity to Rust), or else put the burden on the programmer for safety like C and C++ (in that case, what is the advantage over them).