This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-21
Channels
- # admin-announcements (2)
- # aws-lambda (2)
- # beginners (26)
- # boot (179)
- # cider (36)
- # cljs-dev (118)
- # cljsrn (23)
- # clojure (150)
- # clojure-android (1)
- # clojure-austin (7)
- # clojure-austria (3)
- # clojure-canada (1)
- # clojure-dev (7)
- # clojure-dusseldorf (4)
- # clojure-germany (3)
- # clojure-greece (34)
- # clojure-nl (4)
- # clojure-quebec (9)
- # clojure-russia (30)
- # clojure-spec (38)
- # clojure-uk (3)
- # clojurescript (46)
- # clr (1)
- # core-async (2)
- # css (2)
- # cursive (17)
- # datomic (12)
- # devcards (8)
- # dirac (1)
- # docker (2)
- # hoplon (216)
- # jobs (2)
- # kekkonen (1)
- # lein-figwheel (18)
- # leiningen (2)
- # luminus (1)
- # mount (4)
- # off-topic (2)
- # om (15)
- # onyx (1)
- # parinfer (1)
- # pedestal (2)
- # planck (26)
- # reagent (98)
- # spacemacs (6)
- # specter (19)
- # spirituality-ethics (54)
- # untangled (22)
- # vim (24)
- # yada (4)
what is the current strategy around indy and clojure? could it be an implementation option for certain uses-cases if enough benefits could be demonstrated, or does the jdk 1.7+ requirement simply make it a no go?
i'm fully aware it doesn't magically solve all problems and there are pros/cons/tradeoffs as usual
Until the decision is made to drop Java 6, it seems to be a no go, and so far I didn’t think anyone had demonstrated that indy actually produces any performance benefits in Clojure?
(esp. given the direct linking introduced in Clojure 1.8)
Ghadi has data on this
Rich is wary of invokedynamic because it was pretty bad for a long time. If you look at JRuby who pushed it harder than anyone, I think they still don't trust it enough to use it by default
We will look at it eventually but it's just not the highest priority right now