5 ms·

Really the future of the Modern Java Platform is Graal - https://www.graalvm.org/reference-manual/embed-languages/ https://www.graalvm.org/reference-manual/embe

Really the future of the Modern Java Platform is Graal - https://www.graalvm.org/reference-manual/embed-languages/ https://www.graalvm.org/reference-manual/embed-languages/ Java is not Spring Boot. For example, this is Python 3.8 compliant runtime on top of Graal - https://www.graalvm.org/reference-manual/python/ https://www.graalvm.org/reference-manual/python/ You can also compile your application into a native image (like Go?) - https://www.graalvm.org/reference-manual/native-image/ https://www.graalvm.org/reference-manual/native-image/ you can try it in the next 5 mins 1. docker pull ghcr.io/graalvm/graalvm-ce:latest 2. docker run -it ghcr.io/graalvm/graalvm-ce:latest bash 3. gu install python 4. graalpython -m venv myvenv

kaba0 6y ago
What is more impressive is the graaljs implementation, that when warmed up, has comparable performance to god damn v8. All that with a complete polyglot runtime, so you can call python code from js and vice versa and the best part: it will inline and JIT compile over language boundaries. Also, truffleruby (graalvm’s ruby implementation) is/was two times faster than regular ruby - that’s how much engineering went into the JVM. And of course well-performing (but worse than JIT) AOT compilation is also a possibility with it, though I feel it is not needed as often as people think.
- cogman10 6y ago
  Doesn't stop there. There's also project sulong that tries to bring LLVM IR into the graal ecosystem. Giving you the ability to integrate C/C++/Rust/Fortran/etc. Whatever has an LLVM backend could possibly run side by side with Java/javascript/python all without major FFI penalties and possible cross language optimizations. https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong
erikds 6y ago
Never heard about Graal before. When reading the description it reminds me of WebAssembly. Can anyone compare how they compare?
- diroussel 6y ago
  The simplest way to think of Graalvm is that it’s not a VM, it’s just a plungin replacement for Hotspot. Hotspot is written in C++ and hard to change. So once the java JIT is written in java it will be easier to innovate. But then they took the base and used the java to machine code capabilities to be able to do ahead of time compilation to machine code. But the most amazing part is that if you use the graal apis to define an interpreter for a language (any language) then graal can generate a compiler from that interpreter. It will compile all that is known at compile time and leave to runtime what needs to happen at runtime. So essentially it does partial compilation.
- kaba0 6y ago
  WebAssembly is lower level with raw memory management, meant primary for running low-level languages in the browser. Graal instead is a bit more complex to describe, since it incorporates many things. Perhaps the most important part of it is an abstract syntax tree-based interpreter, which can be used to implement a dynamic language with ease, and Graal can basically convert such an interpreter to a language runtime that uses the many many advancements behind the JVM like advanced JIT, GCs and the like. Such an implementation for small languages can easily surpass the “host” runtime in performance, for example R, Ruby. What makes graal even more interesting is that this intermediate AST is language agnostic, it basically maps the guest language to JVM built-ins — this allows completely polyglot code bases (with JIT compilation between boundaries) and even has an llvm ir-based interpreter because dynamic languages often have C-based standard libs (and since it can inline between deps now, it may be faster than native FFI). But the whitepaper titled One VM to rule them all could give a much better overview than I could. Since it is primarily a JIT compiler, it can be used as AOT as well. (Also, there is graal wasm I believe as well)
- loic-sharma 6y ago
  Yup, they are very similar as both are used to run code at high performance. WebAssembly was designed for the browser. Users want their websites to load quickly, so startup time is crucial. Also, users want to browse sketchy websites, so security is also crucial. WebAssembly is more like an instruction set for a "fake" CPU. It's very low-level and is not ideal for running high-level languages like Ruby (though it's possible!). On the other hand, GraalVM isn't constrained by these browser requirements. This lets Graal do nifty tricks so that highly dynamic languages - like Ruby or JavaScript - run as fast as possible.

kaba0 6y ago

What is more impressive is the graaljs implementation, that when warmed up, has comparable performance to god damn v8. All that with a complete polyglot runtime, so you can call python code from js and vice versa and the best part: it will inline and JIT compile over language boundaries. Also, truffleruby (graalvm’s ruby implementation) is/was two times faster than regular ruby - that’s how much engineering went into the JVM. And of course well-performing (but worse than JIT) AOT compilation is also a possibility with it, though I feel it is not needed as often as people think.

cogman10 6y ago
Doesn't stop there. There's also project sulong that tries to bring LLVM IR into the graal ecosystem. Giving you the ability to integrate C/C++/Rust/Fortran/etc. Whatever has an LLVM backend could possibly run side by side with Java/javascript/python all without major FFI penalties and possible cross language optimizations. https://github.com/oracle/graal/tree/master/sulong https://github.com/oracle/graal/tree/master/sulong

erikds 6y ago

Never heard about Graal before. When reading the description it reminds me of WebAssembly. Can anyone compare how they compare?

diroussel 6y ago
The simplest way to think of Graalvm is that it’s not a VM, it’s just a plungin replacement for Hotspot. Hotspot is written in C++ and hard to change. So once the java JIT is written in java it will be easier to innovate. But then they took the base and used the java to machine code capabilities to be able to do ahead of time compilation to machine code. But the most amazing part is that if you use the graal apis to define an interpreter for a language (any language) then graal can generate a compiler from that interpreter. It will compile all that is known at compile time and leave to runtime what needs to happen at runtime. So essentially it does partial compilation.
kaba0 6y ago
WebAssembly is lower level with raw memory management, meant primary for running low-level languages in the browser. Graal instead is a bit more complex to describe, since it incorporates many things. Perhaps the most important part of it is an abstract syntax tree-based interpreter, which can be used to implement a dynamic language with ease, and Graal can basically convert such an interpreter to a language runtime that uses the many many advancements behind the JVM like advanced JIT, GCs and the like. Such an implementation for small languages can easily surpass the “host” runtime in performance, for example R, Ruby. What makes graal even more interesting is that this intermediate AST is language agnostic, it basically maps the guest language to JVM built-ins — this allows completely polyglot code bases (with JIT compilation between boundaries) and even has an llvm ir-based interpreter because dynamic languages often have C-based standard libs (and since it can inline between deps now, it may be faster than native FFI). But the whitepaper titled One VM to rule them all could give a much better overview than I could. Since it is primarily a JIT compiler, it can be used as AOT as well. (Also, there is graal wasm I believe as well)
loic-sharma 6y ago
Yup, they are very similar as both are used to run code at high performance. WebAssembly was designed for the browser. Users want their websites to load quickly, so startup time is crucial. Also, users want to browse sketchy websites, so security is also crucial. WebAssembly is more like an instruction set for a "fake" CPU. It's very low-level and is not ideal for running high-level languages like Ruby (though it's possible!). On the other hand, GraalVM isn't constrained by these browser requirements. This lets Graal do nifty tricks so that highly dynamic languages - like Ruby or JavaScript - run as fast as possible.