5 ms·

I have the same questions still, after reading all the material and also researching between papers and conference talks. My takeaway so far is: it’s a faster,

by bfung 4y ago

I have the same questions still, after reading all the material and also researching between papers and conference talks. My takeaway so far is: it’s a faster, more flexible, and lighter JVM-like thing. As someone who had written Java Applets from back in the day on the UI side, and written plenty of server side and seen a lot of FaaS successes and failures (more the latter than the former), all the features and use cases map 1:1 - so not really new use cases. Just way better design and implementation (which may make architectures actually end-user usable), w/o money-ed interest. TL;DR, spicy take: “.class file v2”

enos_feedler 4y ago
“Just” without money-ed interest. That is actually huge.
nlitened 4y ago
> Just way better design and implementation Sounds like “far fewer features” to me. Anything that has a lot of features, accumulates a lot if design and implementation compromises (“flaws”)
brabel 4y ago
> it’s a faster, more flexible, and lighter JVM-like thing. Is there any benchmarks showing that wasmtime code can run faster than the equivalent JVM code? How is Wasmtime more flexible than the JVM? It's definitely lighter, for now, but I am not sure that will always be the case with the many WASM proposals.
- bfung 4y ago
  The article shows startup time from enter to output being very, very fast. Having rust, go, c, c++, being able to be transpiled to wasm byte code is already more flexible than jvm. Why isn’t there a popular C front end to jvm? -> there’s the flex. Also wasm runs in browser w/o loading applets. Worry about bloat when the project is more mature; there’s no bloat right now and worth exploring.
  - origin_path 4y ago
    Latest Javas can run hello world in about 50msec or less. If you AOT compile the app it can do so a bit faster than an app written in C, believe it or not. This is not really a competitive advantage for wasmtime. Actually, wasm is less flexible than the JVM because with GraalVM/Truffle you can run: 1. WASM 2. LLVM bitcode both on the JVM, alongside all the other languages it can do like Python, Ruby, Clojure, JavaScript, Kotlin, Smalltalk, R etc. Therefore you can run Rust, C and C++ on the JVM. Don't think you can run Go, but this is still way more languages on the JVM than WASM. https://www.graalvm.org/22.2/reference-manual/llvm/ https://www.graalvm.org/22.2/reference-manual/llvm/ https://www.graalvm.org/22.2/reference-manual/wasm/ https://www.graalvm.org/22.2/reference-manual/wasm/ When running these bytecodes on GraalVM, you also get full interop between languages: https://www.graalvm.org/22.2/reference-manual/polyglot-programming/ https://www.graalvm.org/22.2/reference-manual/polyglot-progr... You ask why there's no popular C frontend for the JVM. It's because nobody really cares about running C on a VM except for people targeting Chrome/Safari. You can do it with GraalVM and it has some uses for running C language extensions to scripting languages, but otherwise is a bit of a curiousity. Usually if you want to call a C library it's because it's an operating system API or because you want to do things that a VM wouldn't do well anyway e.g. stuff with inline native assembly.
    - bfung 4y ago
      To get back at a higher level - I’m not attacking the JVM - a lot of my career had been using it to much success. And the large benefits of wasm are still in the making/a bit unclear. In my original post, I question why this runtime is useful at all, as the jvm already does a lot of the same things. However, GC by default is not in wasm right now, and that enables non-GC languages to be ported over, while it makes no sense to port those languages to the jvm. And a lot of the important stuff is written in those non-GC languages; game engines, gpu compute usage for AI, and others I probably don’t know. The JVM is old ~ still good/great for backend server side things, but not great for fast startup (50ms is still 10,000’slower than wasmtime’s 5 micro second startup), non-gc stuff, and non-technical, impatient, end user browser stuff. Hence worth the exploration - and if it means jvm being replaced 10 years later, so be it (maybe there’ll be a Java to wasm port + gc for wasm by then).

by bfung 4y ago

enos_feedler 4y ago

“Just” without money-ed interest. That is actually huge.

nlitened 4y ago

> Just way better design and implementation Sounds like “far fewer features” to me. Anything that has a lot of features, accumulates a lot if design and implementation compromises (“flaws”)

brabel 4y ago

> it’s a faster, more flexible, and lighter JVM-like thing. Is there any benchmarks showing that wasmtime code can run faster than the equivalent JVM code? How is Wasmtime more flexible than the JVM? It's definitely lighter, for now, but I am not sure that will always be the case with the many WASM proposals.

bfung 4y ago
The article shows startup time from enter to output being very, very fast. Having rust, go, c, c++, being able to be transpiled to wasm byte code is already more flexible than jvm. Why isn’t there a popular C front end to jvm? -> there’s the flex. Also wasm runs in browser w/o loading applets. Worry about bloat when the project is more mature; there’s no bloat right now and worth exploring.
- origin_path 4y ago
  Latest Javas can run hello world in about 50msec or less. If you AOT compile the app it can do so a bit faster than an app written in C, believe it or not. This is not really a competitive advantage for wasmtime. Actually, wasm is less flexible than the JVM because with GraalVM/Truffle you can run: 1. WASM 2. LLVM bitcode both on the JVM, alongside all the other languages it can do like Python, Ruby, Clojure, JavaScript, Kotlin, Smalltalk, R etc. Therefore you can run Rust, C and C++ on the JVM. Don't think you can run Go, but this is still way more languages on the JVM than WASM. https://www.graalvm.org/22.2/reference-manual/llvm/ https://www.graalvm.org/22.2/reference-manual/llvm/ https://www.graalvm.org/22.2/reference-manual/wasm/ https://www.graalvm.org/22.2/reference-manual/wasm/ When running these bytecodes on GraalVM, you also get full interop between languages: https://www.graalvm.org/22.2/reference-manual/polyglot-programming/ https://www.graalvm.org/22.2/reference-manual/polyglot-progr... You ask why there's no popular C frontend for the JVM. It's because nobody really cares about running C on a VM except for people targeting Chrome/Safari. You can do it with GraalVM and it has some uses for running C language extensions to scripting languages, but otherwise is a bit of a curiousity. Usually if you want to call a C library it's because it's an operating system API or because you want to do things that a VM wouldn't do well anyway e.g. stuff with inline native assembly.
  - bfung 4y ago
    To get back at a higher level - I’m not attacking the JVM - a lot of my career had been using it to much success. And the large benefits of wasm are still in the making/a bit unclear. In my original post, I question why this runtime is useful at all, as the jvm already does a lot of the same things. However, GC by default is not in wasm right now, and that enables non-GC languages to be ported over, while it makes no sense to port those languages to the jvm. And a lot of the important stuff is written in those non-GC languages; game engines, gpu compute usage for AI, and others I probably don’t know. The JVM is old ~ still good/great for backend server side things, but not great for fast startup (50ms is still 10,000’slower than wasmtime’s 5 micro second startup), non-gc stuff, and non-technical, impatient, end user browser stuff. Hence worth the exploration - and if it means jvm being replaced 10 years later, so be it (maybe there’ll be a Java to wasm port + gc for wasm by then).