5 ms·

>That idea of a universal/generic VM supporting many languages has been tried many times, with limited success, for example with the JVM, CLR, or Parrot. What m

• hackyhacky 3y ago
  > take something (aka Javascript) that's already distributed and adopted industry-wide and work backwards from that to create a "virtual machine & IL instruction codes specification & runtime". I don't understand this. WASM is not JavaScript: it can't do things that JavaScript can do (such as directly access the DOM) and JS can't do things that WASM can do (such as pointer arithmetic). Their abstractions are totally different, which is why they complement each other. JS does not run in the WASM virtual machine. Other than the fact that they both run in a web browser, they have almost nothing in common. So I think your analogy fails. WASM is not a JS IL, it's a separate IL that happens to be distributed by the same mechanism. As such, it can still fail and is still vulnerable to the hubris of the JVM, wherein a single memory model was selected for all platforms and all (higher-level) languages.
  • jasode 3y ago
    >I don't understand this. WASM is not JavaScript: [...] So I think your analogy fails. WASM is not a JS IL, it's a separate IL Yes, that's what it looks like now. To explain the Javascript-to-WASM evolution, we use the concept of the "Overton Window" shifting the industry by almost imperceptible degrees : https://en.wikipedia.org/wiki/Overton_window https://en.wikipedia.org/wiki/Overton_window - phase 1: 1995 Javascript the "toy language" but no IL. The industry doesn't need to be "afraid" of a toy scripting language because it's just there to make the monkey dance.[1] - phase 2: 2000s Javascript is being extended XMLHttpRequest() to create "serious" apps like drag & drop email and Google Maps - phase 3: 2013 extensive use of Javascript everywhere motivates a performance hack by creating subset in "asm.js" : https://en.wikipedia.org/wiki/Asm.js https://en.wikipedia.org/wiki/Asm.js - phase 4: 2017 instead of "asm.js" (and also using some Google NaCl ideas), the industry finally collaborates to create WASM to further optimize away the inefficient "asm.js" Since WASM today looks a lot like what JVM/CLR hoped to accomplish, why couldn't we have skipped the whole circuitous route of Javascript-then-WASM instead of just having "WASM in 1995" in the first place?!? Because of the Overton Window. If WASM was there from the beginning, it would have been too "threatening" in 1990s and corporate firewall admins would want to block all http/html that had it. ("Let's prevent WASM viruses") Javascript on the other hand is just for animating monkeys so there's no need to block it. That's how you eventually get universal distribution across clients including smartphones. With Javascript code already entrenched everywhere, it's easier to slide the Overton Window over to WASM. WASM didn't get created in a vacuum. It's existence is directly tied back to Javascript's usage and growth. [1] https://softwareengineering.stackexchange.com/questions/221615/why-do-dynamic-languages-make-it-more-difficult-to-maintain-large-codebases#:~:text=The%20by%2Ddesign%20purpose%20of%20JavaScript%20was%20to%20make%20the%20monkey%20dance%20when%20you%20moused%20over%20it.%20Scripts%20were%20often%20a%20single%20line https://softwareengineering.stackexchange.com/questions/2216....
    • zozbot234 3y ago
      > Since WASM today looks a lot like what JVM/CLR hoped to accomplish WASM is actually much lower-level than JVM or CLR, there's basically no comparison. The main feature in both CLR and JVM (accounting for the bulk of their complexity) is their object model which has no equivalent in WASM-GC, the closest thing (while quite different nonetheless) is probably the WASM components proposal which is still vaporware. (Could WASM-GC have shipped in the mid-1990s? Quite unlikely, the FLOSS community was in its infancy back then and JVM applets were seen as state of the art. Even the Cyclone language was only created in the mid-2000s, and having full type- and memory-safety with C-like performance and no need for pervasive GC was unthinkable prior to that. The plan9 folks had Limbo and Dis which were somewhat simpler, but there was zero broader interest in using something like that over the JVM.)
• lolinder 3y ago
  There's a lot wrong here with these timelines. Java applets came out at the same time as the original release of Java, and were definitely part of Sun's strategy for Java, but providing a platform for other languages wasn't in the plan. Others came because they specified the virtual machine so clearly that it was actually possible to target (unlike Python's), but if you look at the Java bytecode it's pretty clear that it exists to serve one language and all others must adapt. You calling the JVM not having raw pointers a "technical issue" makes it sound like it was a mistake on Java's part, but that's just a side effect of only intending to support a language that doesn't have raw pointers. Meanwhile, WASM isn't just JavaScript-made-fast—JavaScript is already very fast through JIT compilation, and it's not obvious that compiling it ahead of time to WASM would make it faster. I'm not even aware of any efforts to do so. WASM is actually what you seem to think Java was—a new runtime built for the web and designed to allow many languages to target it flawlessly. To the extent WASM has an advantage over previous shared runtimes, it's that it was designed to be shared from the start and was spearheaded by the largest modern platforms—the browsers themselves are the true Trojan horse here.
  • miohtama 3y ago
    > were definitely part of Sun’s strategy Java is a desktop light client programming language which found a small niche on server side.