4 ms·

> I suppose the "novelty" is the existence of compilation to WASM target in more and more compiler toolchains Which ones? AFAIK WSAM runs only "C-like" langua

> I suppose the "novelty" is the existence of compilation to WASM target in more and more compiler toolchains Which ones? AFAIK WSAM runs only "C-like" language properly. Everything else is a major hack and slow as hell. When it even exists of course. Because to my knowledge there aren't much languages that compile to WASM besides C/C++/Rust. Because WASM lacks features for VM languages (and that is the big majority of languages). Did something in this regard change lately?

rtpg 4y ago
I wasn't being careful with my language. But we're basically looking at a continuation of the Emscriptem "hack" with WASM, meaning that you can run CPython in the browser and have a lot of third party pacakges work (much better than GraalVM's "PoC" Python interpreter). And yeah, I guess we're able to run things in the browser with WASM. One could say "well why use it on a machine outside the browser", to which I reply the obvious thing: hell of a lot easier to just use one VM rather than two. I think there are also social dynamics at play when it comes to _anything_ related to Oracle, which does poison the well. It's unfair to the GraalVM people's serious work, but it is what it is.
flohofwoe 4y ago
There are plenty languages with WASM support that aren't "C-like" in this list (and you don't need special "GC support" in WASM to implement a GC in WebAssembly, at the cost of bundling the GC implementation in your WASM blob) https://github.com/appcypher/awesome-wasm-langs https://github.com/appcypher/awesome-wasm-langs
- still_grokking 4y ago
  > 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): https://krausest.github.io/js-framework-benchmark/2022/table_chrome_104_windows.html https://krausest.github.io/js-framework-benchmark/2022/table...
  - flohofwoe 4y ago
    > The point is that that's extremely inefficient. 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).
    - kaba0 4y ago
      > 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?
      - flohofwoe 4y ago
        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.
        kaba0 4y ago
        > 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?
        4y ago

rtpg 4y ago

I wasn't being careful with my language. But we're basically looking at a continuation of the Emscriptem "hack" with WASM, meaning that you can run CPython in the browser and have a lot of third party pacakges work (much better than GraalVM's "PoC" Python interpreter). And yeah, I guess we're able to run things in the browser with WASM. One could say "well why use it on a machine outside the browser", to which I reply the obvious thing: hell of a lot easier to just use one VM rather than two. I think there are also social dynamics at play when it comes to _anything_ related to Oracle, which does poison the well. It's unfair to the GraalVM people's serious work, but it is what it is.

flohofwoe 4y ago

There are plenty languages with WASM support that aren't "C-like" in this list (and you don't need special "GC support" in WASM to implement a GC in WebAssembly, at the cost of bundling the GC implementation in your WASM blob) https://github.com/appcypher/awesome-wasm-langs https://github.com/appcypher/awesome-wasm-langs

still_grokking 4y ago
> 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): https://krausest.github.io/js-framework-benchmark/2022/table_chrome_104_windows.html https://krausest.github.io/js-framework-benchmark/2022/table...
- flohofwoe 4y ago
  > The point is that that's extremely inefficient. 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).
  - kaba0 4y ago
    > 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?
    - flohofwoe 4y ago
      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.
      - kaba0 4y ago
        > 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?
        4y ago