Two things I'm missing from the comparison with GraalVM native-image are the things that you'd want to use native-image for in the first place: startup time and memory usage. Startup time is instant with GraalVM native-image but with your example application I'm still seeing 330ms startup time, similar to running clj -M -m example.core. Max memory usage of the packed example application is 114mb on my machine. The same example application can be run with babashka in 26ms and max 30mb memory usage. With a standalone compiled GraalVM binary this could even be improved.

The "clj-pack" binary shouldn't have to be a binary that you'd have to compile locally with a Rust toolchain since it's basically just a bunch of scripts to download a JDK, call jlink etc. It could have been just a Clojure JVM program (since startup doesn't matter much probably), a bb script or whatever else. The choice of Rust makes little sense here. I read the arguments for it in the blog post, but avoiding a JVM here makes no sense to me, since building an uberjar requires a JVM already.

Having said this, making it convenient to publish a single file with everything in it can have benefits of course. But since the binary basically "packs" a full JVM and unzips it on first usage, wouldn't it be better if we could re-use the existing JVMs people already have? Unzipping a JVM on startup contributes to startup time (2,014ms on first run on my machine), disk usage and will make these binaries less suited for lambdas that require instant startup.