4 ms·
My 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. Toda
by dorfsmay 8y ago
My 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.