The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms. But Clojure compiles quite a bit of Clojure code generating hundreds if not thousands of classes and then loads them before starting up the Clojure program. Still, there's ongoing work on the JVM (Project Leyden [1]) to speed up both startup and warmup even of such programs by caching more state.
Right, but the problem is that many programs do a lot more work when they start up than Hello, World. The Clojure runtime in particular does quite a lot at startup.
I don't like how this issue is constantly dismissed out of hand. It very obviously is actually a massive glaring issue which severely limits what clojure can reasonably be used for. Nobody would ever accept a 1 second startup time for CLI applications that we use all the time like git, kubectl, npm, docker, etc.
40ms? Clojure Hello World startup time is like 600ms and up. Yes sometimes you run npm and kubectl for hours but most of my usage is just running individual commands that take less than a second.
You still don't see many scripts or CLI apps in Java though. I was wondering if that would change now that you can run a source file directly, but then wouldn't the startup be slower, because now it's also having to compile.
That's pretty much the idea behind Project Leyden's "premain" work. The tricky bit is that the program startup being almost exactly the same each time isn't quite the same as being exactly the same. The JVM already caches some things and the capabilities of that mechanism are being expanded to cover more, including JITted code as well as some program computations done at initialisation.
Back when I wrote Clojure professionally, using GraalVM to generate a native executable of things like clj-kondo basically eliminated the startup latency.
[1]: E.g. see https://spring.io/blog/2023/10/16/runtime-efficiency-with-sp...