5 ms·

I don't believe that's the correct way to use WASM. If one has a GC collected language one may be better off compiling to JS, or at least a combination of JS an

I don't believe that's the correct way to use WASM. If one has a GC collected language one may be better off compiling to JS, or at least a combination of JS and WASM for some linear C-like computation that's then offloaded back to JS. People need to look at JS, WASM, WebGL/WebGPU and the other browser APIs as a single platform, and use the right parts for the right job, instead of reimplementing JS functionality in WASM and vice versa etc.

flohofwoe 3y ago
A platform shouldn't dictate details like what programming language to use to create applications for that platform. It's already bad enough with iOS and ObjC/Swift or Android with Java/Kotlin, but at least there are escape hatches on those platforms. WASM is the escape hatch that was needed on the browser platform.
- 3cats-in-a-coat 3y ago
  I'm discussing JS and WASM as two compile targets for your preferred language. No one is "dictating" anything. But JS and WASM are complementary in some important ways. GC being one.
  - brabel 3y ago
    Are you aware that WASM is going to have a GC soon? It's in phase 3 (Implementation Phase): https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals
  - flohofwoe 3y ago
    Emscripten has shown that Javascript is a terrible compilation target, that's why WASM exists in the first place (Emscripten started with compiling to vanilla JS, which was then 'standardized' into the asm.js subset, and finally ended up in WASM ... each of those steps improved performance, and a Javascript/asm.js backend would never have been accepted into upstream clang, while WASM is "just another ISA").
    - 3cats-in-a-coat 3y ago
      I find it frustrating you casually ignored the primary context of the comment/thread you're replying to, namely: suitable targets for GC (garbage collected) languages, not for C and C++, which you surely know are not garbage collected. WASM is a suitable target for Emscripten. But I never said otherwise, and this was not the discussion. Also. WASM is not "just another ISA" at all, as I explained in other comments throughout. For one it has an opaque call stack and no free jumps inside from one code location to another, unlike any other ISA in the world. This means it's terrible for languages which lean heavily into tail calls and coroutines, among other. It's also bad for GC languages as a custom collector can't compete with JS's GC.
      - flohofwoe 3y ago
        I simply don't see that there's a big enough difference between traditional garbage collection, refcounting and manual memory management. Each of those can already be implemented in pure WASM (without the new GC support), just more or less awkwardly. As for "just another ISA", there have been CPUs which had separate call- and data-stacks, with the call-stack living on the CPU and not directly accessible to code. In that sense WASM isn't much different then those esoteric CPUs, yet those also implemented "just another ISA". And even though WASM might not allow free control flow, I yet have to see a noticeable performance difference between WASM and native for this type of "worst case code": https://github.com/floooh/chips/blob/f5b6684ff6e899429544b2133b31d912ebc15f40/chips/z80.h#L1815-L1849 https://github.com/floooh/chips/blob/f5b6684ff6e899429544b21...
        3cats-in-a-coat 3y ago
        We can implement everything on an infinite tape read/writer, but the point is performance. I'm trying to find something to say about you calling a CPU "esoteric" due to its ISA, and then calling its ISA specifics "just another ISA". Kind of seems like a 180 in the middle of your sentence. But one way or another TCO and indirect calls are crucial for modern languages and I'm glad eventually it'll be usable in WASM as you pointed out in another comment.
        3y ago
davexunit 3y ago
JS is still going to be used by those compiling to WASM. WASM modules will need to import host functions from the JS environment. JS is an unappealing compiler target for a number of reasons, but I'll highlight one relevant to Scheme: no tail calls.
- 3cats-in-a-coat 3y ago
  You may unpleasantly surprised by this, but WASM also has no tail calls. No, despite it's "asm", it has no jumps ("goto") to addresses and labels except structured (nested blocks) ones, like in JS, and with a hidden/implicit call stack. Like in JS. This means if you want tail calls you need to emulate them with similar techniques you'd also use in JS. So, what else makes JS a less appealing compiler target? Let's unravel this myth.
  - flohofwoe 3y ago
    > but WASM also has no tail calls Is this still true? I don't know if I'm reading this right, but this page says the tail call extension is shipping since Chrome 112: https://chromestatus.com/feature/5423405012615168 https://chromestatus.com/feature/5423405012615168 PS: yep, shipped in Chrome 112, but not yet in any other stable browsers version (only in nightly or behind feature flags): https://webassembly.org/roadmap/ https://webassembly.org/roadmap/
    - 3cats-in-a-coat 3y ago
      I didn't know they're working on it, so thanks for the pointer. But clearly not something you can use yet. Unless somehow you only target bleeding edge Chrome. But that's an important advancement.
  - davexunit 3y ago
    I'm just more excited about WASM as a compilation target and I don't really feel like getting into details. The current WASM spec does not have tail calls, but there is a proposal for tail calls that is sitting behind a feature flag in V8 right now. I am currently working with Andy on Guile Hoot, a WASM toolchain for Scheme, and we use the instructions (return_call and friends) in that proposal. Like GC, the tail call proposal has high likelihood of landing across all browsers.
nirvdrum 3y ago
Despite its name, people are using WebAssembly outside of the browser. And it could be useful to have a GC in those contexts. Hooking in something like V8 is counter-productive in those cases.

flohofwoe 3y ago

A platform shouldn't dictate details like what programming language to use to create applications for that platform. It's already bad enough with iOS and ObjC/Swift or Android with Java/Kotlin, but at least there are escape hatches on those platforms. WASM is the escape hatch that was needed on the browser platform.

3cats-in-a-coat 3y ago
I'm discussing JS and WASM as two compile targets for your preferred language. No one is "dictating" anything. But JS and WASM are complementary in some important ways. GC being one.
- brabel 3y ago
  Are you aware that WASM is going to have a GC soon? It's in phase 3 (Implementation Phase): https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals
- flohofwoe 3y ago
  Emscripten has shown that Javascript is a terrible compilation target, that's why WASM exists in the first place (Emscripten started with compiling to vanilla JS, which was then 'standardized' into the asm.js subset, and finally ended up in WASM ... each of those steps improved performance, and a Javascript/asm.js backend would never have been accepted into upstream clang, while WASM is "just another ISA").
  - 3cats-in-a-coat 3y ago
    I find it frustrating you casually ignored the primary context of the comment/thread you're replying to, namely: suitable targets for GC (garbage collected) languages, not for C and C++, which you surely know are not garbage collected. WASM is a suitable target for Emscripten. But I never said otherwise, and this was not the discussion. Also. WASM is not "just another ISA" at all, as I explained in other comments throughout. For one it has an opaque call stack and no free jumps inside from one code location to another, unlike any other ISA in the world. This means it's terrible for languages which lean heavily into tail calls and coroutines, among other. It's also bad for GC languages as a custom collector can't compete with JS's GC.
    - flohofwoe 3y ago
      I simply don't see that there's a big enough difference between traditional garbage collection, refcounting and manual memory management. Each of those can already be implemented in pure WASM (without the new GC support), just more or less awkwardly. As for "just another ISA", there have been CPUs which had separate call- and data-stacks, with the call-stack living on the CPU and not directly accessible to code. In that sense WASM isn't much different then those esoteric CPUs, yet those also implemented "just another ISA". And even though WASM might not allow free control flow, I yet have to see a noticeable performance difference between WASM and native for this type of "worst case code": https://github.com/floooh/chips/blob/f5b6684ff6e899429544b2133b31d912ebc15f40/chips/z80.h#L1815-L1849 https://github.com/floooh/chips/blob/f5b6684ff6e899429544b21...
      - 3cats-in-a-coat 3y ago
        We can implement everything on an infinite tape read/writer, but the point is performance. I'm trying to find something to say about you calling a CPU "esoteric" due to its ISA, and then calling its ISA specifics "just another ISA". Kind of seems like a 180 in the middle of your sentence. But one way or another TCO and indirect calls are crucial for modern languages and I'm glad eventually it'll be usable in WASM as you pointed out in another comment.
      - 3y ago

davexunit 3y ago

JS is still going to be used by those compiling to WASM. WASM modules will need to import host functions from the JS environment. JS is an unappealing compiler target for a number of reasons, but I'll highlight one relevant to Scheme: no tail calls.

3cats-in-a-coat 3y ago
You may unpleasantly surprised by this, but WASM also has no tail calls. No, despite it's "asm", it has no jumps ("goto") to addresses and labels except structured (nested blocks) ones, like in JS, and with a hidden/implicit call stack. Like in JS. This means if you want tail calls you need to emulate them with similar techniques you'd also use in JS. So, what else makes JS a less appealing compiler target? Let's unravel this myth.
- flohofwoe 3y ago
  > but WASM also has no tail calls Is this still true? I don't know if I'm reading this right, but this page says the tail call extension is shipping since Chrome 112: https://chromestatus.com/feature/5423405012615168 https://chromestatus.com/feature/5423405012615168 PS: yep, shipped in Chrome 112, but not yet in any other stable browsers version (only in nightly or behind feature flags): https://webassembly.org/roadmap/ https://webassembly.org/roadmap/
  - 3cats-in-a-coat 3y ago
    I didn't know they're working on it, so thanks for the pointer. But clearly not something you can use yet. Unless somehow you only target bleeding edge Chrome. But that's an important advancement.
- davexunit 3y ago
  I'm just more excited about WASM as a compilation target and I don't really feel like getting into details. The current WASM spec does not have tail calls, but there is a proposal for tail calls that is sitting behind a feature flag in V8 right now. I am currently working with Andy on Guile Hoot, a WASM toolchain for Scheme, and we use the instructions (return_call and friends) in that proposal. Like GC, the tail call proposal has high likelihood of landing across all browsers.

nirvdrum 3y ago

Despite its name, people are using WebAssembly outside of the browser. And it could be useful to have a GC in those contexts. Hooking in something like V8 is counter-productive in those cases.