This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-21
Channels
- # adventofcode (27)
- # announcements (2)
- # babashka (1)
- # beginners (111)
- # calva (11)
- # cider (82)
- # clara (6)
- # clojure (44)
- # clojure-dev (5)
- # clojure-europe (27)
- # clojure-nl (5)
- # clojure-spec (3)
- # clojure-uk (3)
- # clojurescript (29)
- # core-async (5)
- # cursive (4)
- # datalevin (1)
- # datomic (39)
- # exercism (4)
- # figwheel-main (1)
- # fulcro (32)
- # graalvm (7)
- # gratitude (1)
- # integrant (4)
- # jobs (1)
- # lein-figwheel (3)
- # leiningen (4)
- # lsp (3)
- # luminus (3)
- # meander (2)
- # nextjournal (1)
- # off-topic (10)
- # other-languages (26)
- # pathom (14)
- # polylith (9)
- # re-frame (16)
- # remote-jobs (1)
- # shadow-cljs (4)
- # specter (2)
- # sql (6)
- # timbre (2)
- # tools-build (12)
- # xtdb (9)
I'm wondering if not used Clojure functions are trimmed from GraalVM native image artifact? I know that for plain Java it works that way, however I'm not sure about Clojure in this case.
unless you do dynamic stuff like requiring-resolve
at runtime which really can bloat the image
Thanks for clarification. Now, I understand why some of the libraries that load code dynamically produce large artifacts.
@karol.wojcik yes, you can avoid this by doing the dynamic require at compile time, i.e. top level, but "inline" it's going to bloat stuff. I've made https://github.com/borkdude/dynaload specifically to address that issue (based on dynaload from spec)
See the GraalVM section here: https://github.com/borkdude/dynaload#graalvm
Whoa. I was aware of the existence of this library, but never understood it's purpose. Now it's clear to me why it matters.