4 ms·

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 a

• 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.
  • int_19h 7y ago
    > 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. Not necessarily. The problem is that JVM is too high-level, and imposes not just a memory model, but also an object model, with many constraints to impose memory safety. That can be difficult to work around without performance penalties. So languages that are designed to target JVM from the get go, tend to be designed with those limitations in mind, constraining them. .NET bytecode is somewhere in the middle between that and wasm. It has things such as raw pointers and pointer arithmetic, dynamic allocation of stack, unions, and other things that aren't memory-safe. This allows languages that don't want to have memory safety imposed on them (like C++), or that have their own ideas about how to impose it properly (like Rust), do whatever they want, and run efficiently on top of CLR. But it still has that high-level object model, much like JVM, which can be used for interop that's higher-level than just a C ABI. wasm, for the time being at least, is a VM that is limited to a C ABI. Their future plans, such as interface types, can potentially approach the complexity of the JVM and CLR object models, but with more isolation boundaries (because memory isn't shared between modules).