That’s true. But it makes no difference.
WASM is a runtime for “C like” languages which run still inside a managed sandbox.
But inside the sandbox it’s more or less like what you get from the C abstract machine. Of course it’s limited in some ways that make it “safe”, so no matter what “magic” you do inside the sandbox even with raw “memory”, you can’t escape the sandbox (and can’t “hijack” things there either to some degree with some of the typical C exploits, afaik).
I’m not questioning this.
But Scala Native is much closer. That’s the whole point.
Which means lowering the Scala IR down to a level that is close to what you need to run Scala on a bare C abstract machine. Which is reimplementing Scala Native…
I need to look at this. 
That’s the problem. What those proposals write often doesn’t have anything in common with what is actually there. WASM stuff is in large parts vaporware frankly…
Nothing compared to what LLVM (or actually the JS JITs) could do.
You would need to implement all these AOT optimizations to be even just theoretically competitive. But like mentioned a few times: Often even Rust code, compiled and optimized though LLVM, does not come anywhere close to the efficiency of JIT compiled JS.
That’s more or less how I interpreted that sample.
But this still means that you need to actually use these primitives to implement your own OOP. That’s why I said this is more like what you get with C++; actually even a little lower level as C++ brings already a default implementation for that stuff (but you still free to tinker with because C++ gives you enough control for that).
Sorry but I don’t get this part.
First of all there is no production GC language on WASM currently (besides experiments here and there). So the questions is moot, imho, because it asks for a comparison to something that does not exist.
Secondly, calling from and to a GC language from a non GC languages is a hairy and difficult task no matter the environment. Whether you’re on the JVM, CLR, or else where. Even when you can talk some low-level ABI directly (like it’s with Scala Native and C) it’s still not trivial.
Also doing this without going though some sort of FFI does not work anyway.
FFI implies usually argument marshaling. (You can do tricks in special cases to improve performance of your FFI, but this only works if both sides of the FFI are aware of that).
But what does this have to do with WASM? WASM defines only one canonical way to talk to the outside world (any other module or a WASM “world”). This is the component model! Based on the WASM canonical ABI.
It does not matter whether someone did this already.
There is only one way for that in the WASM world: Using the canonical WASM ABI.
WASM modules are closed systems by default. That’s the core of WASM sandboxing.
You can than dig small wholes here and there to talk to and from the inside of your sandbox. But these holes need to be explicitly defined, because you can’t share anything from the outside with the sandbox, or anything from the inside of the sandbox to the outside. (If WASM GC breaks that I would have actually some further and quite fundamental question regarding all the WASM marketing promises… Because than sandboxing would be a plain lie.)
I don’t see that.
There are no “two choices”. There is only one: Scala needs a GC; as without an efficient GC implementation in the runtime Scala on WASM is impossible.
So no matter which Scala IR gets compiled down to WASM, it will need to use WASM GC.
But to also utilize any of the potential advantages of the WASM platform you need low-level things in the language! You need it to talk canonical ABI with the outside world and ecosystem libs. You need it to write efficient compute kernels that can give you speedups for routines which are slow when implemented in JS.
You wanted to say impossible, right? Because without being able to talk canonical WASM ABI there is no integration with anything at all… 
To be honest I would not believe this claim before seeing some robust benchmarks.
I don’t see that.
Scala.js-on-WASM makes no sense. It won’t bring Scala to a new platform all in all. That’s dead end effort.
But of course I’m not paying this. So I don’t have any right to tell people what they should or should not do here. Just that in my opinion the current proposal pushed further will turn out as a large wast of time in the end. 
At least this would explain why they doing these crazy things at all. Do you have a source? Because I also never understood why MS is burning such ridiculous amounts of money on something that quite obviously doesn’t work well (and likely never will).
But GC is not the only thing here. The CLR as such is a static, ahead of time compiled program (in large parts). But even that is slow as dog on WASM. It’s not only about “the things running inside”. Just compare how fast this, or actually also CheerpJ which implements the JIT compiler part in WASM, compile JVM or .NET assemblies. But a compiler should be actually something that runs fine in WASM, because it amounts mostly to a lot of “number crunching”.
Or even better: See how Emscripten compiled programs run in the browser. They’re fast, but of course still slower than native. One could judge the WASM overhead from that.
For a language like Scala.js which is pretty high level compared to what you get from Emscripten the overhead will be much much bigger. That’s why I’m repeating over and over that Scala run in WASM won’t be fast. It will be slow. (And only when you hand optimize code, using the low-level capabilities of WASM, you can get, with luck, some speedups at all; but only in case all the Scala abstractions don’t eat the gains; Scala Native has at least some form of optimizer to “de-abstract” things. Scala.js doesn’t AFAIK…)