3 ms·
Early experiments with Graal seems to tell a promising story with regards to compiling to native. Whenever Graal is mentioned, a host of reservations towards O
by fnordsensei 8y ago
Early experiments with Graal seems to tell a promising story with regards to compiling to native.
Whenever Graal is mentioned, a host of reservations towards Oracle usually appears though.
- dorfsmay 8y agoMy concerns about the JVM aren't so much CPU, but memory usage and ease of distribution. Those two factors have, IMO, helped take golang where it is today. Today you cannot run your Clojure apps on a small 250 MB VM, and distributing it means getting the right version of the JVM, the right libraries etc... I don't know how Graal will handle those two issues, it'll be interesting to watch.
- fnordsensei 8y agoI found this pretty interesting: https://medium.com/criciumadev/serverless-native-java-functions-using-graalvm-and-fn-project-c9b10a4a4859 https://medium.com/criciumadev/serverless-native-java-functi... Single data point, but nevertheless. Cold Execution Times: Java Function -> 660 ms Native Java Function -> 460 ms Go Function -> 470 ms Hot execution times: Java Function -> 30 ms Native Java Function -> 30 ms Go Function -> 30 ms Container Memory usage of Hot Function: Java Function -> 17.8 MiB Native Java Function -> 0.9 MiB Go Function -> 1.2 MiB Container Image Size: Java Function -> 266 MB Native Java Function -> 13.6 MB Go Function -> 15.1 MB
- pjmlp 8y agoWhere is Go? Still not a match for Hotspot and around me everyone still asks for .NET and Java projects. And those data structures with indirect calls are never going to go away.
- pjmlp 8y agoMight be, then again no one else bothered to actually save Java, so we get whoever cared, regardless of the monetary reasons.