3 ms·

I've never seen 80ms in practice and he elides over how (even if true) it would only matter for command line programs as if those are rare, when in fact they ar

I've never seen 80ms in practice and he elides over how (even if true) it would only matter for command line programs as if those are rare, when in fact they are quite common. Only knowing "java my.jar" means you have zero knowledge about the nature of your language's run-time and having a good understanding of your languages run-time is necessary to write good code. The more complex the run-time of your language, the higher the cognitive load of that language. His discussion of memory use doesn't mention the pre-allocation of the heap for the JVM. The memory used by the application itself is irrelevant when the JVM is what is actually using the memory.

floatboth 10y ago
You can start up the VM in 80ms for sure, you'll just need much more time after that to load all the damn classes from the bloated libraries you're gonna use. (Especially terrible with functional runtimes like Clojure's.) > pre-allocation of the heap for the JVM Pre-allocation doesn't matter, it's not allocating physical memory?? The GHC Haskell runtime literally mallocs one terabyte when the program starts :D However OpenJDK/HotSpot's baseline memory usage is indeed higher than many other VMs'. Even if you compare with alternative JVMs: I tested a basic Jetty app — it used ~60 MB on JamVM, ~70 MB on OpenJDK.