4 ms·

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/S

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.
      - chriswarbo 3y ago
        > Each of those can already be implemented in pure WASM (without the new GC support) I'm not super familiar with WASM, but (according to this article/talk) implementing GC in pure WASM doesn't really work cross-module: in particular, there's no way to trace liveness across modules (e.g. if some JS is holding a reference to one of our WASM values), and the least-privilege/capability approach is lost since we have to grant access to all of our memory at once (e.g. if we're storing the heap as one big buffer). > just more or less awkwardly There are hacks and work-arounds, but it's a pretty silly situation when there's already a GC right there for the JS engine. It's important to get the details right when standardising (e.g. to allow future advances, rather than locking-in current techniques), but the current situation of downloading multiple standalone GCs isn't really acceptable.

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.
    - chriswarbo 3y ago
      > Each of those can already be implemented in pure WASM (without the new GC support) I'm not super familiar with WASM, but (according to this article/talk) implementing GC in pure WASM doesn't really work cross-module: in particular, there's no way to trace liveness across modules (e.g. if some JS is holding a reference to one of our WASM values), and the least-privilege/capability approach is lost since we have to grant access to all of our memory at once (e.g. if we're storing the heap as one big buffer). > just more or less awkwardly There are hacks and work-arounds, but it's a pretty silly situation when there's already a GC right there for the JS engine. It's important to get the details right when standardising (e.g. to allow future advances, rather than locking-in current techniques), but the current situation of downloading multiple standalone GCs isn't really acceptable.