6 ms·

Another nail in the Java coffin? I hope if doensn't refuse to die (again)

by eb0la 7y ago

marcosdumay 7y ago
I don't think Java is a great language, but killing at this time would destroy a lot of value. Besides, people mostly do not use Java because of the JVM, so I don't think WA will even make a dent on it. It's more likely that Java gets ported into WA than that WA kills it.
spullara 7y ago
Don't you mean JavaScript? This will have 0 effect on Java at this point since it isn't used in the browser anymore.
- lmkg 7y ago
  WASM is angling to break out of the web and become a cross-platform runtime. Its main competition for this space is Java.
  - somurzakov 7y ago
    some of the compute workload still needs to be on a backend because of security concerns. if you offload too much stuff on a client-side, then any hacker can mess with it and break your system. for example you can get angular debugger extension for chrome and mess with any online shop that uses this system to "adjust prices" for your cart during checkout
    - sho_hn 7y ago
      Parent meant WASM on the server.
    - woodrowbarlow 7y ago
      the backend could compile to wasm as well.
      - somurzakov 7y ago
        and what is the profit in compiling C/C++/Rust into wasm, instead of native binary code?
        woodrowbarlow 7y ago
        well this thread was about wasm vs java, but... advantages: sandbox, portability disadvantages: performance, platform integration nobody's saying that server-side wasm will be universally the right choice.
        yazaddaruvala 7y ago
        Better hosting/deploying/debugging/etc because WASM can be hot-loaded and easily embeddable. e.g. https://www.cloudflare.com/products/cloudflare-workers/ https://www.cloudflare.com/products/cloudflare-workers/
    - zozbot234 7y ago
      This is only a problem for online services, multiplayer games etc. These shouldn't trust client-provided data, including data that comes from WASM. But there are countless applications that can be entirely local, with no need to interact with any sort of "cloud" services. WASM can potentially be quite helpful there
  - thesuperbigfrog 7y ago
    Show me a WASM VM that approaches the OpenJDK JVM in maturity and capabilities. Until such a creation comes to be, the OpenJDK JVM will continue to thrive.
    - didibus 7y ago
      Ironically, GraalVM might end up being one of the better WASM VM: https://medium.com/graalvm/announcing-graalwasm-a-webassembly-engine-in-graalvm-25cd0400a7f2 https://medium.com/graalvm/announcing-graalwasm-a-webassembl...
      - thesuperbigfrog 7y ago
        True, but GraalVM is based on the OpenJDK / OracleJDK JVM: "GraalVM Community Editions are based on OpenJDK version 1.8.0_232 and on OpenJDK version 11.0.5. GraalVM Enterprise Editions are based on Oracle Java version 1.8.0_231 and on Oracle Java version 11.0.5." Source: https://www.graalvm.org/docs/getting-started/ https://www.graalvm.org/docs/getting-started/ So, it's still the OpenJDK JVM underneath.
        didibus 7y ago
        Yup, that's why I said ironically, because it might end up that the best non-web VM for WASM turns out to be the JVM Though V8 is more likely to be what WASM first targets.
  - spullara 7y ago
    Without defining a standard set of abstractions around operating system resources it is pretty far from competitive with Java and more closely related to something like LLVM bitcode.
    - saagarjha 7y ago
      LLVM bitcode is not cross platform.
      - spullara 7y ago
        It is very close and with a standardized ABI it can be (that is how it was slightly modified to be used in Google's Portable Native Client). It is much more similar to WASM than Java byte code. https://www.chromium.org/nativeclient/pnacl/introduction-to-portable-native-client https://www.chromium.org/nativeclient/pnacl/introduction-to-...
    - MaulingMonkey 7y ago
      > Without defining a standard set of abstractions around operating system resources That part is called WASI.
- eb0la 7y ago
  For me Java is legacy. A good runtime for the web will have a lot of developers worldwide. I am betting on it not just for the web, but to replace legacy apps as soon as we get a good runtime not just for the web. Probably Electron can be one of such new runtimes
  - didibus 7y ago
    I don't know what your experience with the JVM is, but it really isn't legacy. It's actually much more state of the art. Can you explain a bit more in what way you see it as legacy? Because the JVM has some of the best GCs, and JIT + AOT compilation of any VM around. And its portability story is quite impressive. You can argue Java as a language has some legacy hanging around, though they've made great progress there with the latest versions. But the JVM has support for other languages as well, such as Ruby, Python, Scala, Kotlin, Clojure, Common Lisp, JavaScript, Fantom, etc. Now WASM isn't a runtime. WASM is more akin to Java Bytecode or LLVM bitcode. Each browser vendor will implement their own WASM VM. Currently, there is no standard for Garbage Collection, which means GCed languages won't be good candidates for WASM. If you want to use Python, Java, C#, Kotlin, TypeScript, Haskell, etc. your resulting program will need to bundle a full runtime for your language compiled to WASM as well. In all cases, this will end up having slower performance, and on the web will cause bigger download sizes. Hopefully, this gets addressed in the future. The flip side is portability. For example, Go compiled to WASM could run on all WASM non-web compliant VMs. But it'll run slower than GO compiled for the target machine directly. That's why a good use case for WASM right now is to allow JavaScript to make use of C/C++ libraries in the browser. As well as Node.js to do the same in non-browser contexts. This will often mean an HTML/CSS/JS UX with certain section of it in C/C++/Rust. It does mean that Electron apps will be able to make use of portable C/C++ libraries more easily, as they get compiled to WASM and the V8 runtime will be able to run that WASM and eventually offer interop with the DOM and JS. Though that's not yet supported, as the boundary between GCed JS/DOM and WASM hasn't been fully figured out yet. Also, WASI is the standard library for WASM, and that'll need to grow as well. Progress is being made there too, but its goal is to remain minimal, and delend more on libraries. Conclusion, let's say you have WASM, Java Bytecode and LLVM bitcode, and maybe even .net IR. All of them are a form of virtual assembly which need a VM to run them. Any language could build a compiler to any of these. But they have different trade offs. Java Bytecode is pretty simple, and the VM has a standard memory model and GC with a large accompanying library, and a state of the art JIT. Making it a great target for higher level languages. .net IR is pretty similar, though the bytecode can be a bit more difficult in its handling of reified generics. That can make it a bit harder to target for higher level languages. Its JIT isn't as sophisticated, same as its GC, but it comes real close, and has good tooling around it and an excellent standard library. LLVM will remain king for high performance, as it is designed to handle all kind of optimizations, and support multiple's language feature set efficiently. That said, it isn't as portable and isn't optimized for small binaries and fast parse times. It too, is best for low level languages as it doesn't enforce a memory model. WASM also doesn't enforce a memory model, making it a great target for low level languages. It is optimized for safety and portability. Which means it'll most likely always be slower than LLVM. But it also tries to be as fast as it can, and theoritically could beat out Java Bytecode or .net IR given it can avoid GC overhead. It also is optimized to be streamed over the wire, that means small binaries that can be quickly parsed. So ideal for code that you can't predict where it is going to run, like the web. The VM landscape overall is looking pretty healthy. But I think there's misconceptions out there, especially around the JVM and .net Core, and also about people's hype for WASM. Specifically, the JVM and .net Core are almost impossible to beat for what they do. So don't expect better from WASM. Similarly, JS is almost impossible to beat for what it does, and WASM doesn't plan to replace it, but enhance it.
ilikehurdles 7y ago
It will bury JS long before it buries Java(/JVM), if it will bury either. I'm not sure there is any convincing reason to use wasm on the backend, where java is prevalent.
- gnulinux 7y ago
  As in, JS development for browser? You'll still need JS to run WebAssembly in the browser. It'll bury JS in the sense that you are able to develop in any other language like C++, and compile your program to JS+WebAssembly, so you don't need to develop in JS anymore. But JS itself (under the hood) is probably to stay for longer.
  - 52-6F-62 7y ago
    And then if all web apps move to a canvas-painted UI with all the code in web assembly then there will be a major accessibility problem. Unless screen readers can now dive down into the canvas layer?
    - jhoechtl 7y ago
      You raised a very valid point here. How much difference will be between a canvas-painted web-app and a native Windows application? The line woll get increasingly blurry.
      - BlueTemplar 7y ago
        The "web" app will have worse performance.
        gnulinux 7y ago
        You mean for accessibility? Maybe but there shouldn't be any fundamental reason why an accessibility tool can read a windows app and not web app, since under the hood Chrome and Firefox can use the same interface this tool interfaces with. If you meant performance in terms of runtime, I'm not convinced this is the case. Obviously WebAssembly will have some overhead, but I don't think the overhead is critical enough for most applications to matter. Especially if those applications are written in anything other than C/C++, they'll have similar performance characteristics.

Another nail in the Java coffin? I hope if doensn't refuse to die (again)

by eb0la 7y ago

Another nail in the Java coffin? I hope if doensn't refuse to die (again)

I don't think Java is a great language, but killing at this time would destroy a lot of value. Besides, people mostly do not use Java because of the JVM, so I don't think WA will even make a dent on it. It's more likely that Java gets ported into WA than that WA kills it.

spullara 7y ago

Don't you mean JavaScript? This will have 0 effect on Java at this point since it isn't used in the browser anymore.

lmkg 7y ago
WASM is angling to break out of the web and become a cross-platform runtime. Its main competition for this space is Java.
- somurzakov 7y ago
  some of the compute workload still needs to be on a backend because of security concerns. if you offload too much stuff on a client-side, then any hacker can mess with it and break your system. for example you can get angular debugger extension for chrome and mess with any online shop that uses this system to "adjust prices" for your cart during checkout
  - sho_hn 7y ago
    Parent meant WASM on the server.
  - woodrowbarlow 7y ago
    the backend could compile to wasm as well.
    - somurzakov 7y ago
      and what is the profit in compiling C/C++/Rust into wasm, instead of native binary code?
      - woodrowbarlow 7y ago
        well this thread was about wasm vs java, but... advantages: sandbox, portability disadvantages: performance, platform integration nobody's saying that server-side wasm will be universally the right choice.
      - yazaddaruvala 7y ago
        Better hosting/deploying/debugging/etc because WASM can be hot-loaded and easily embeddable. e.g. https://www.cloudflare.com/products/cloudflare-workers/ https://www.cloudflare.com/products/cloudflare-workers/
  - zozbot234 7y ago
    This is only a problem for online services, multiplayer games etc. These shouldn't trust client-provided data, including data that comes from WASM. But there are countless applications that can be entirely local, with no need to interact with any sort of "cloud" services. WASM can potentially be quite helpful there
- thesuperbigfrog 7y ago
  Show me a WASM VM that approaches the OpenJDK JVM in maturity and capabilities. Until such a creation comes to be, the OpenJDK JVM will continue to thrive.
  - didibus 7y ago
    Ironically, GraalVM might end up being one of the better WASM VM: https://medium.com/graalvm/announcing-graalwasm-a-webassembly-engine-in-graalvm-25cd0400a7f2 https://medium.com/graalvm/announcing-graalwasm-a-webassembl...
    - thesuperbigfrog 7y ago
      True, but GraalVM is based on the OpenJDK / OracleJDK JVM: "GraalVM Community Editions are based on OpenJDK version 1.8.0_232 and on OpenJDK version 11.0.5. GraalVM Enterprise Editions are based on Oracle Java version 1.8.0_231 and on Oracle Java version 11.0.5." Source: https://www.graalvm.org/docs/getting-started/ https://www.graalvm.org/docs/getting-started/ So, it's still the OpenJDK JVM underneath.
      - didibus 7y ago
        Yup, that's why I said ironically, because it might end up that the best non-web VM for WASM turns out to be the JVM Though V8 is more likely to be what WASM first targets.
- spullara 7y ago
  Without defining a standard set of abstractions around operating system resources it is pretty far from competitive with Java and more closely related to something like LLVM bitcode.
  - saagarjha 7y ago
    LLVM bitcode is not cross platform.
    - spullara 7y ago
      It is very close and with a standardized ABI it can be (that is how it was slightly modified to be used in Google's Portable Native Client). It is much more similar to WASM than Java byte code. https://www.chromium.org/nativeclient/pnacl/introduction-to-portable-native-client https://www.chromium.org/nativeclient/pnacl/introduction-to-...
  - MaulingMonkey 7y ago
    > Without defining a standard set of abstractions around operating system resources That part is called WASI.
eb0la 7y ago
For me Java is legacy. A good runtime for the web will have a lot of developers worldwide. I am betting on it not just for the web, but to replace legacy apps as soon as we get a good runtime not just for the web. Probably Electron can be one of such new runtimes
- didibus 7y ago
  I don't know what your experience with the JVM is, but it really isn't legacy. It's actually much more state of the art. Can you explain a bit more in what way you see it as legacy? Because the JVM has some of the best GCs, and JIT + AOT compilation of any VM around. And its portability story is quite impressive. You can argue Java as a language has some legacy hanging around, though they've made great progress there with the latest versions. But the JVM has support for other languages as well, such as Ruby, Python, Scala, Kotlin, Clojure, Common Lisp, JavaScript, Fantom, etc. Now WASM isn't a runtime. WASM is more akin to Java Bytecode or LLVM bitcode. Each browser vendor will implement their own WASM VM. Currently, there is no standard for Garbage Collection, which means GCed languages won't be good candidates for WASM. If you want to use Python, Java, C#, Kotlin, TypeScript, Haskell, etc. your resulting program will need to bundle a full runtime for your language compiled to WASM as well. In all cases, this will end up having slower performance, and on the web will cause bigger download sizes. Hopefully, this gets addressed in the future. The flip side is portability. For example, Go compiled to WASM could run on all WASM non-web compliant VMs. But it'll run slower than GO compiled for the target machine directly. That's why a good use case for WASM right now is to allow JavaScript to make use of C/C++ libraries in the browser. As well as Node.js to do the same in non-browser contexts. This will often mean an HTML/CSS/JS UX with certain section of it in C/C++/Rust. It does mean that Electron apps will be able to make use of portable C/C++ libraries more easily, as they get compiled to WASM and the V8 runtime will be able to run that WASM and eventually offer interop with the DOM and JS. Though that's not yet supported, as the boundary between GCed JS/DOM and WASM hasn't been fully figured out yet. Also, WASI is the standard library for WASM, and that'll need to grow as well. Progress is being made there too, but its goal is to remain minimal, and delend more on libraries. Conclusion, let's say you have WASM, Java Bytecode and LLVM bitcode, and maybe even .net IR. All of them are a form of virtual assembly which need a VM to run them. Any language could build a compiler to any of these. But they have different trade offs. Java Bytecode is pretty simple, and the VM has a standard memory model and GC with a large accompanying library, and a state of the art JIT. Making it a great target for higher level languages. .net IR is pretty similar, though the bytecode can be a bit more difficult in its handling of reified generics. That can make it a bit harder to target for higher level languages. Its JIT isn't as sophisticated, same as its GC, but it comes real close, and has good tooling around it and an excellent standard library. LLVM will remain king for high performance, as it is designed to handle all kind of optimizations, and support multiple's language feature set efficiently. That said, it isn't as portable and isn't optimized for small binaries and fast parse times. It too, is best for low level languages as it doesn't enforce a memory model. WASM also doesn't enforce a memory model, making it a great target for low level languages. It is optimized for safety and portability. Which means it'll most likely always be slower than LLVM. But it also tries to be as fast as it can, and theoritically could beat out Java Bytecode or .net IR given it can avoid GC overhead. It also is optimized to be streamed over the wire, that means small binaries that can be quickly parsed. So ideal for code that you can't predict where it is going to run, like the web. The VM landscape overall is looking pretty healthy. But I think there's misconceptions out there, especially around the JVM and .net Core, and also about people's hype for WASM. Specifically, the JVM and .net Core are almost impossible to beat for what they do. So don't expect better from WASM. Similarly, JS is almost impossible to beat for what it does, and WASM doesn't plan to replace it, but enhance it.

ilikehurdles 7y ago

It will bury JS long before it buries Java(/JVM), if it will bury either. I'm not sure there is any convincing reason to use wasm on the backend, where java is prevalent.

gnulinux 7y ago
As in, JS development for browser? You'll still need JS to run WebAssembly in the browser. It'll bury JS in the sense that you are able to develop in any other language like C++, and compile your program to JS+WebAssembly, so you don't need to develop in JS anymore. But JS itself (under the hood) is probably to stay for longer.
- 52-6F-62 7y ago
  And then if all web apps move to a canvas-painted UI with all the code in web assembly then there will be a major accessibility problem. Unless screen readers can now dive down into the canvas layer?
  - jhoechtl 7y ago
    You raised a very valid point here. How much difference will be between a canvas-painted web-app and a native Windows application? The line woll get increasingly blurry.
    - BlueTemplar 7y ago
      The "web" app will have worse performance.
      - gnulinux 7y ago
        You mean for accessibility? Maybe but there shouldn't be any fundamental reason why an accessibility tool can read a windows app and not web app, since under the hood Chrome and Firefox can use the same interface this tool interfaces with. If you meant performance in terms of runtime, I'm not convinced this is the case. Obviously WebAssembly will have some overhead, but I don't think the overhead is critical enough for most applications to matter. Especially if those applications are written in anything other than C/C++, they'll have similar performance characteristics.