This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-31
Channels
- # beginners (64)
- # boot-dev (5)
- # calva (2)
- # clojars (2)
- # clojure (27)
- # clojure-europe (2)
- # clojure-india (1)
- # clojure-italy (30)
- # clojure-nl (3)
- # clojure-spec (46)
- # clojure-uk (19)
- # clojurescript (38)
- # code-reviews (2)
- # cursive (2)
- # datomic (15)
- # events (2)
- # graphql (3)
- # kaocha (1)
- # leiningen (5)
- # lumo (2)
- # off-topic (29)
- # perun (1)
- # re-frame (40)
- # reagent (5)
- # rum (3)
- # spacemacs (11)
- # specter (4)
- # tools-deps (4)
@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