> There are plenty languages with WASM support that aren't "C-like" in this list
Really? I see marked as "production ready" (whatever this means in this case):
AssemblyScript
Brainfuck
C
C++
Go
Forth
Zig
Rust
COBOL
C#
F#
Lua
Clean
Lobster
TypeScript
Never
So the realistic options are: C/C++, Go, Zig, Rust, C#/F#, and Lua.
Where C#/F# is slow as hell, with a gigantic overhead.
Lua is likely slow (don't know for sure).
The rest looks pretty much like "the C languages" to me.
> […] and you don't need special "GC support" in WASM to implement a GC in WebAssembly, at the cost […]
Oh, someone is prepared.
Sure, you can build such thing. One can also build a Web-Browser in Brainfuck; somehow (and than even run it in a WASM container).
The point is that that's extremely inefficient.
In the browser it does even make less sense as there is the JS VM with a pretty solid GC right next to the WASM runtime.
So compiling a VM language to WASM is already questionable in itself. But without proper low-level building blocks to implement managed language runtimes efficiently this can be hardly even called working. Just have a look how for example Blazor compares to native JS (which people consider slow and sluggish already):
We're talking about garbage collection though, this will always be inefficient, doesn't matter much on which side of the fence it is implemented. At best you can save some WASM download size by piggybacking on the Javascript engine's garbage collector (that's essentially what the WASM GC proposal is about).
> We're talking about garbage collection though, this will always be inefficient, doesn't matter much on which side of the fence it is implemented.
No, that's just not true.
You can't implement GC in WASM currently in any sane way.
As already said more than once here: WASM is lacking needed features. (For example memory fence instructions).
Any GC build in WASM will be extremely slow and inefficient. It will be also a stop-the-world GC. Because you can't build anything else.
GC implemented in WASM is at the moment completely impracticable.
Sure, you "can" do it still. But that's like building a banking application in Brainfuck. You can do that. In theory. Maybe even someone did it "for real". All this does not matter. It's brainfuck.
And that's not only the GC.
VM runtimes, and JITs need some more features to be implemented efficiently.
WASM is also lacking those features (like computed go-to).
Bottom line is: It's impossible to implement a VM in the WASM VM even remotely acceptable.
This is also backed by data:
I've showed already the catastrophic performance of Blazor. (And this is something where millions of dollars went for years to make it even "work".)
> We're talking about garbage collection though, this will always be inefficient
Come on, it is a ridiculous claim. GCs can run completely concurrently with the actual code with barely any coordination between the runtime and the running code - they basically make allocation’s and deallocation’s costs asymptotically zero. You do not believe that manual allocations are free, right?
The whole point of explicit memory management is to avoid memory allocation and deallocation calls in the first place (by controlling where and when allocation/deallocation exactly happens, and that should not be anywhere near a hot code path). And with that, allocator performance doesn't really matter anymore (that's also why 'fast' memory allocators like mimalloc or jemalloc are really kinda pointless, if those make a measurable performance difference, than the code is already calling the alloc/free functions way too often.
> explicit memory management is to avoid memory allocation and deallocation calls in the first place
No, it isn’t. Memory management.
Also, so you want to write code with hardcoded sizes for everything or what? Yeah, I surely want programs that die on a string of length 35 because only 32 were allocated upfront.
Also, managed languages can have hot loops without any allocation going on, you know right?
You really need to spend a bit of time to educate yourself and tinker a bit with manual memory management (there's a bit more to it than just calling malloc/free each time you need to grab 35 bytes of memory).
Thank you very much, I’m quite familiar with it. As are professionals who write those GC systems we are talking about, probably much much more so than any of us.
Really? I see marked as "production ready" (whatever this means in this case):
So the realistic options are: C/C++, Go, Zig, Rust, C#/F#, and Lua.Where C#/F# is slow as hell, with a gigantic overhead.
Lua is likely slow (don't know for sure).
The rest looks pretty much like "the C languages" to me.
> […] and you don't need special "GC support" in WASM to implement a GC in WebAssembly, at the cost […]
Oh, someone is prepared.
Sure, you can build such thing. One can also build a Web-Browser in Brainfuck; somehow (and than even run it in a WASM container).
The point is that that's extremely inefficient.
In the browser it does even make less sense as there is the JS VM with a pretty solid GC right next to the WASM runtime.
So compiling a VM language to WASM is already questionable in itself. But without proper low-level building blocks to implement managed language runtimes efficiently this can be hardly even called working. Just have a look how for example Blazor compares to native JS (which people consider slow and sluggish already):
https://krausest.github.io/js-framework-benchmark/2022/table...