@flyboarder do i understand right that this loader doesn't need to be written in a jvm language even? since what it does is launch a jvm

another implication of this that just occurred to me - if we launch with a separate process, we can revisit boot daemon, since the blocker there was inability to change working dir within a jvm

@alandipert yes you are correct! - compiling to native-image makes it much faster than a jvm language, with all the perks of clojure

another way we can improve the first launch time is by including the base-uber.jar which currently isn’t available on clojars, there was a pr for this in boot-bin that never got merged - a minor change to the download url is all thats needed once the jars are available

one thing I noticed was the amount of duplicate code between Boot (boot-bin) and (boot-clj) - most of this could be handled by the loader and passed to the jvm as system properties, reducing the amount of double processing happening on the JVM - imo this slows us down considerably since none of it can currently be aot compiled due to the dynamic class loading