6 ms·

The JVM, the .Net CLR: mature, stable, secure - why do we need another alpha-level VM thing that was devised to make Javascript faster that can awkwardly run sl

The JVM, the .Net CLR: mature, stable, secure - why do we need another alpha-level VM thing that was devised to make Javascript faster that can awkwardly run slow(er than native) bytecode? How is that progress?

johncolanduoni 8y ago
Because it’s not “devised to make JavaScript faster”. WASM is first and foremost designed as a compilation target for languages that work with a simple linear memory and don’t use a garbage collector, like C/C++/Rust (extensions to interact directly with the JavaScript GC are in progress, but quite a ways off). The progress it enables is the ability to run performance sensitive code written in these languages in a software-sandboxed environment at anywhere near native speed, as opposed to multiple times slower. Also neither the JVM nor the CLR even seriously attempt to offer the security when executing untrusted code that WASM does. WASM has been deployed for over a year in all the major browsers, making vulnerabilities in its implementations very valuable. Yet we haven’t seen some huge explosion of CVEs due to its addition, unlike the early history of the JVM and CLR’s attempts to implement robust software sandboxes (before they both threw up their hands and stopped trying to market their sandboxing features as suitable for running untrusted code).
- lazyjones 8y ago
  > unlike the early history of the JVM and CLR’s attempts to implement robust software sandboxes (before they both threw up their hands and stopped trying to market their sandboxing features as suitable for running untrusted code). Is this a fair comparison? JVM and CLR allow general purpose programming and syscalls across several platforms. What can you do with WASM today? Only whatever is allowed by browsers.
  - krapp 8y ago
    WASM was designed with the intent that it run in the web as well as natively[0]. It just happens that the technology is still in its infancy and, because initial support was deployed in browsers, the web is currently the primary focus of developer interest. And, unfortunately (to me) the most likely means of "native" deployment for WASM applications is going to be in Electron, but that's due to a limitation of the initiative of developer culture, not WASM itself. [0]https://webassembly.org/docs/non-web/ https://webassembly.org/docs/non-web/
    - lazyjones 8y ago
      IOW, JVM/CLR wanted primarily to support locally run, trusted application code and gave up on browser sandboxing. WASM is primarily run on browsers and hasn't attempted yet to support full applications. Apples vs. oranges.
      - krapp 8y ago
        I don't think it's apples and oranges, I think it's approaching the same destination from different starting points.
  - johncolanduoni 8y ago
    I wasn’t claiming that they don’t have distinct feature sets; WASM for example can’t currently do any kind of shared memory concurrency, let alone provide a GC with shared memory concurrency. The claim that it’s just a recapitulation of the JVM however is equally innacurate. Nobody would seriously consider running multiple mutually-untrusted JVM programs in the same process, but WASM is offered in that manner in every major browser. That said, nothing stops a WASM embedder from offering system calls, and you can already use whatever system resources you want via Node as easily as you can use the DOM in a browser.
FridgeSeal 8y ago
Because it’s not another shitty language runtime like JVM or CLR, it’s a machine-code level target. You can take your Java/Rust/.Net/Haskell/etc/etc apps and compile them down to WASM, much like you would if you were using LLVM to compile down to assembly.
- pjmlp 8y ago
  I bet the existing AOT compilers for Java and .NET are able to produce much better optimized code than any available WASM implementations.
  - FridgeSeal 8y ago
    And LLVM can do better than those in turn, would I prefer if we were using LLVM as the underlying target for machine code? Hell yeah I would, but we’re not quite there yet, and if it’s a toss up between the JS powered 3MB+ websites and endless shitty electron apps or WASM, I’m going to elect for WASM. At least with WASM if it takes off, it can at least path the way for a more better and more appropriate (LLVM, AoT CLR, etc) universal machine code later down the line. That’ll never happen if we’re chained to JS though.
    - deleted 8y ago
      [deleted]
    - pjmlp 8y ago
      I rather have the AOT compile times from Java and CLR based toolchains. As for LLVM as the underlying target for machine code, it is already a thing, nothing new here. https://www.imsystech.com/high-level-languages/ https://www.imsystech.com/high-level-languages/ https://www.infoq.com/articles/ios-9-bitcode https://www.infoq.com/articles/ios-9-bitcode
    - jashmatthews 8y ago
      LLVM _is_ the backend for Mono. It's easier for LLVM to produce better code if it doesn't have to go via a register based bytecode VM like WebAssembly. Was discussed here not so long ago: http://troubles.md/posts/wasm-is-not-a-stack-machine/ http://troubles.md/posts/wasm-is-not-a-stack-machine/

johncolanduoni 8y ago

Because it’s not “devised to make JavaScript faster”. WASM is first and foremost designed as a compilation target for languages that work with a simple linear memory and don’t use a garbage collector, like C/C++/Rust (extensions to interact directly with the JavaScript GC are in progress, but quite a ways off). The progress it enables is the ability to run performance sensitive code written in these languages in a software-sandboxed environment at anywhere near native speed, as opposed to multiple times slower. Also neither the JVM nor the CLR even seriously attempt to offer the security when executing untrusted code that WASM does. WASM has been deployed for over a year in all the major browsers, making vulnerabilities in its implementations very valuable. Yet we haven’t seen some huge explosion of CVEs due to its addition, unlike the early history of the JVM and CLR’s attempts to implement robust software sandboxes (before they both threw up their hands and stopped trying to market their sandboxing features as suitable for running untrusted code).

lazyjones 8y ago
> unlike the early history of the JVM and CLR’s attempts to implement robust software sandboxes (before they both threw up their hands and stopped trying to market their sandboxing features as suitable for running untrusted code). Is this a fair comparison? JVM and CLR allow general purpose programming and syscalls across several platforms. What can you do with WASM today? Only whatever is allowed by browsers.
- krapp 8y ago
  WASM was designed with the intent that it run in the web as well as natively[0]. It just happens that the technology is still in its infancy and, because initial support was deployed in browsers, the web is currently the primary focus of developer interest. And, unfortunately (to me) the most likely means of "native" deployment for WASM applications is going to be in Electron, but that's due to a limitation of the initiative of developer culture, not WASM itself. [0]https://webassembly.org/docs/non-web/ https://webassembly.org/docs/non-web/
  - lazyjones 8y ago
    IOW, JVM/CLR wanted primarily to support locally run, trusted application code and gave up on browser sandboxing. WASM is primarily run on browsers and hasn't attempted yet to support full applications. Apples vs. oranges.
    - krapp 8y ago
      I don't think it's apples and oranges, I think it's approaching the same destination from different starting points.
- johncolanduoni 8y ago
  I wasn’t claiming that they don’t have distinct feature sets; WASM for example can’t currently do any kind of shared memory concurrency, let alone provide a GC with shared memory concurrency. The claim that it’s just a recapitulation of the JVM however is equally innacurate. Nobody would seriously consider running multiple mutually-untrusted JVM programs in the same process, but WASM is offered in that manner in every major browser. That said, nothing stops a WASM embedder from offering system calls, and you can already use whatever system resources you want via Node as easily as you can use the DOM in a browser.

FridgeSeal 8y ago

Because it’s not another shitty language runtime like JVM or CLR, it’s a machine-code level target. You can take your Java/Rust/.Net/Haskell/etc/etc apps and compile them down to WASM, much like you would if you were using LLVM to compile down to assembly.

pjmlp 8y ago
I bet the existing AOT compilers for Java and .NET are able to produce much better optimized code than any available WASM implementations.
- FridgeSeal 8y ago
  And LLVM can do better than those in turn, would I prefer if we were using LLVM as the underlying target for machine code? Hell yeah I would, but we’re not quite there yet, and if it’s a toss up between the JS powered 3MB+ websites and endless shitty electron apps or WASM, I’m going to elect for WASM. At least with WASM if it takes off, it can at least path the way for a more better and more appropriate (LLVM, AoT CLR, etc) universal machine code later down the line. That’ll never happen if we’re chained to JS though.
  - deleted 8y ago
    [deleted]
  - pjmlp 8y ago
    I rather have the AOT compile times from Java and CLR based toolchains. As for LLVM as the underlying target for machine code, it is already a thing, nothing new here. https://www.imsystech.com/high-level-languages/ https://www.imsystech.com/high-level-languages/ https://www.infoq.com/articles/ios-9-bitcode https://www.infoq.com/articles/ios-9-bitcode
  - jashmatthews 8y ago
    LLVM _is_ the backend for Mono. It's easier for LLVM to produce better code if it doesn't have to go via a register based bytecode VM like WebAssembly. Was discussed here not so long ago: http://troubles.md/posts/wasm-is-not-a-stack-machine/ http://troubles.md/posts/wasm-is-not-a-stack-machine/