> Clojure simply doesn't need these large features because they can ship most of them as regular libraries. ..plus Clojure itself can be though of as being a really nice small and zero-dependencies "library" itself as well. Single 3.9MB jar 🙂 https://mvnrepository.com/artifact/org.clojure/clojure/1.11.3 I remember one clojure "language feature" which was added not too long ago in the past. It was the ability to destruct the "& rest" arguments of function as a map, even if the "rest part" was a vector. Basically this became possible:

(defn foo [a b & {:keys [c d]}]
  {:a a, :b b, :c c, :d d})

(foo "a" "b" :c "c" :d "d")
;; => {:a "a", :b "b", :c "c", :d "d"}

@U9W4ZULJV I think that I was trying to refer to this change in clojure 1.11: https://github.com/clojure/clojure/blob/master/changes.md#21-keyword-argument-functions-take-a-trailing-map But perhaps I messed up the description of it, not sure 🙂

plus Clojure itself can be though of as being a really nice small and zero-dependencies "library" itselfI'd not make this argument myself because Java is kind-of a library for JVM too. Except you'd have to generate .class files yourself if you'd want to interface with JVM. So Java would be a way to generate .class files. In this regard Java is also a library, an addon for JVM. > I simply had to bump a clojure version number in deps.edn and that was it This is how you'd migrate from Java 6 to Java 7 and others. Just bump the version. I don't think there is a conceptual difference here. Except the tooling. What I tried to say was that since the programmer is allowed to go into the compiler part of this library it avoids a lot of issues that include waiting for language authors to "save the day". And in Clojure's case the community can design a library and improve on language author's ideas because the core is not closed for modification.