That's perfectly fine, and I totally understand people who don't want to sit and wait 70ms for their script to finish running (that 70ms is not the time it takes to start), but let's not turn a <40ms startup into 1.5s. Now, it is true that if you want to launch a minimal HTTP server in Java you may need to wait ~100ms, which may be too long for you, but is also a far cry from 1.5s.
It is, but I am still quoting what I saw before, it was not a fantasy. I don't deny it's likely better nowadays, sure, but I remain moderately skeptical because JVM is still a runtime that needs to boot.
Then again, Golang has one as well, though it does manage to start it up faster it seems.
You might be interested in OpenJDK's new ability to 'cache' classes to accelerate class loading. JEP 483: Ahead-of-Time Class Loading & Linking. It doesn't persist code generated by the JIT, but can improve startup time appreciably.
> This program runs in 0.031 seconds on JDK 23. After doing the small amount of additional work required to create an AOT cache it runs in in 0.018 seconds on JDK 24 — an improvement of 42%.
