5 ms·

Its literally Java all over again. Don't. Just. Don't.

by hypfer 8y ago

guiriduro 8y ago
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/
lazyjones 8y ago
Or p-code. This is my knee-jerk reaction too, can't wait till someone implements a portable browser in wasm like it's 1997. If someone actually builds a working and useful portable OS and UI layer around wasm, I might stop joking about it.
- CyberDildonics 8y ago
  Most people don't have a p-code or java interpreter on their computer already, but 80% can already use webasm. https://caniuse.com/#feat=wasm https://caniuse.com/#feat=wasm
rkangel 8y ago
Why not? A single cross-platform compilation target seems like a great idea. Java got caught up with some proprietary stuff thanks to Oracle, but there's a useful goal there. In the same way that the web is a useful target for cross-platform UI applications.
- pjmlp 8y ago
  As if under Sun it was all flowers and such.
- deleted 8y ago
  [deleted]
Hywan 8y ago
No, it's not :-), see https://words.steveklabnik.com/is-webassembly-the-return-of-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...
- hypfer 8y ago
  So he's basically stating that Wasm is better at doing what Java/Shockwave/Flash did. Thats most likely correct but also beside the point. The concept of "That one Layer which enables Cross-Platform applications" is just something which has failed, does fail and will fail in the future. Idc if its better at being Java since its still trying to be java.
  - steveklabnik 8y ago
    I’m saying that’s the case in the browser, but I’m also a big believer in wasm outside of the browser too.
int_19h 8y ago
It's literally not. You can't compile C into efficient JVM bytecode, but you can with WASM.
- pjmlp 8y ago
  Graal project has other point of view. https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong
  - int_19h 8y ago
    Does it target pure JVM bytecode and runtime? This talks about GraalVM and how it's "optimized for many different languages", and they make the same claim on their page, specifically citing LLVM.
    - pjmlp 8y ago
      GraalVM is based on Graal, Java's future C2 JIT compiler implemented in Java, and already part of OpenJDK 11. Sulong makes use of Graal and Truffle to create a LLVM AST interpreter (with native code JIT via Graal, thus allowing seamless integration between C and Java code on the same JVM.
      - int_19h 8y ago
        When you say "reuses the JIT", does it reuse the JIT API that gets JVM bytecode as input, and native code as output? Or is it a lower layer, that JVM bytecode is implemented on top of, and that is not constrained by the Java object and memory model? Like, if it can do unbounded pointer arithmetic without emulating it with arrays (which is slow and inefficient), surely the JIT needs to have the corresponding low-level opcodes for that, like e.g. CLR does?
        pjmlp 8y ago
        Graal only knows about JVM bytecodes, and there isn't any emulation of pointer arithmetic. You need first to understand the role of Truffle in this. It is a framework to generate AST interpreters, that plugs into Graal. So an interpreter for LLVM gets written in Truffle, which while running a specific LLVM application, generates an interpreter for that specific code, so after awhile the JIT comes into the picture optimizing the generated interpreter that is processing that LLVM code. This goes a few rounds until it becomes almost indistinguishable from generating the code straight from LLVM. It is the same principle behind using PyPY and RPython to add new languages into PyPy. JRuby is one of the projects making use of this infrastructure to run C extensions. Naturally due to the slow startup until everything is finally converted into native code, this approach is only usable for long lived server based applications. You can get more information about it in some of these links, mostly outdated though. https://llvm.org/devmtg/2016-01/slides/Sulong.pdf https://llvm.org/devmtg/2016-01/slides/Sulong.pdf "Using LLVM and Sulong for Language C Extensions - LLVM Cauldron 2016" https://www.youtube.com/watch?v=bJzMfYX6n9A https://www.youtube.com/watch?v=bJzMfYX6n9A "Project Sulong: an LLVM bitcode interpreter on the Graal VM" https://www.youtube.com/watch?v=yyDD_KRdQQU https://www.youtube.com/watch?v=yyDD_KRdQQU

Its literally Java all over again. Don't. Just. Don't.

by hypfer 8y ago

Its literally Java all over again. Don't. Just. Don't.

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/

lazyjones 8y ago

Or p-code. This is my knee-jerk reaction too, can't wait till someone implements a portable browser in wasm like it's 1997. If someone actually builds a working and useful portable OS and UI layer around wasm, I might stop joking about it.

CyberDildonics 8y ago
Most people don't have a p-code or java interpreter on their computer already, but 80% can already use webasm. https://caniuse.com/#feat=wasm https://caniuse.com/#feat=wasm

rkangel 8y ago

Why not? A single cross-platform compilation target seems like a great idea. Java got caught up with some proprietary stuff thanks to Oracle, but there's a useful goal there. In the same way that the web is a useful target for cross-platform UI applications.

pjmlp 8y ago
As if under Sun it was all flowers and such.
deleted 8y ago
[deleted]

Hywan 8y ago

No, it's not :-), see https://words.steveklabnik.com/is-webassembly-the-return-of-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...

hypfer 8y ago
So he's basically stating that Wasm is better at doing what Java/Shockwave/Flash did. Thats most likely correct but also beside the point. The concept of "That one Layer which enables Cross-Platform applications" is just something which has failed, does fail and will fail in the future. Idc if its better at being Java since its still trying to be java.
- steveklabnik 8y ago
  I’m saying that’s the case in the browser, but I’m also a big believer in wasm outside of the browser too.

int_19h 8y ago

It's literally not. You can't compile C into efficient JVM bytecode, but you can with WASM.

pjmlp 8y ago
Graal project has other point of view. https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong
- int_19h 8y ago
  Does it target pure JVM bytecode and runtime? This talks about GraalVM and how it's "optimized for many different languages", and they make the same claim on their page, specifically citing LLVM.
  - pjmlp 8y ago
    GraalVM is based on Graal, Java's future C2 JIT compiler implemented in Java, and already part of OpenJDK 11. Sulong makes use of Graal and Truffle to create a LLVM AST interpreter (with native code JIT via Graal, thus allowing seamless integration between C and Java code on the same JVM.
    - int_19h 8y ago
      When you say "reuses the JIT", does it reuse the JIT API that gets JVM bytecode as input, and native code as output? Or is it a lower layer, that JVM bytecode is implemented on top of, and that is not constrained by the Java object and memory model? Like, if it can do unbounded pointer arithmetic without emulating it with arrays (which is slow and inefficient), surely the JIT needs to have the corresponding low-level opcodes for that, like e.g. CLR does?
      - pjmlp 8y ago
        Graal only knows about JVM bytecodes, and there isn't any emulation of pointer arithmetic. You need first to understand the role of Truffle in this. It is a framework to generate AST interpreters, that plugs into Graal. So an interpreter for LLVM gets written in Truffle, which while running a specific LLVM application, generates an interpreter for that specific code, so after awhile the JIT comes into the picture optimizing the generated interpreter that is processing that LLVM code. This goes a few rounds until it becomes almost indistinguishable from generating the code straight from LLVM. It is the same principle behind using PyPY and RPython to add new languages into PyPy. JRuby is one of the projects making use of this infrastructure to run C extensions. Naturally due to the slow startup until everything is finally converted into native code, this approach is only usable for long lived server based applications. You can get more information about it in some of these links, mostly outdated though. https://llvm.org/devmtg/2016-01/slides/Sulong.pdf https://llvm.org/devmtg/2016-01/slides/Sulong.pdf "Using LLVM and Sulong for Language C Extensions - LLVM Cauldron 2016" https://www.youtube.com/watch?v=bJzMfYX6n9A https://www.youtube.com/watch?v=bJzMfYX6n9A "Project Sulong: an LLVM bitcode interpreter on the Graal VM" https://www.youtube.com/watch?v=yyDD_KRdQQU https://www.youtube.com/watch?v=yyDD_KRdQQU