I disagree in the particular case of Clojure and Java (there are other places where I would agree, famously Jane Street gets by with staying in OCaml as much as

I disagree in the particular case of Clojure and Java (there are other places where I would agree, famously Jane Street gets by with staying in OCaml as much as possible and writing copious amounts of C-ish OCaml where necessary). > keeping track of performance regressions using CI is not hard It's actually kind of hard on the JVM. Again, if you have only a few hotspots then it's easy enough to set up some tests, but if you really need coverage over most of your codebase, it can get tricky, especially because these optimizations can combine in nonlocal ways so just exercising one function in one context doesn't guarantee the same performance in another. When taking into account warming up JIT compilation, benchmarks can become a real time suck. Criterium runs take a long time. You can't pop them like candy in the same way you can with unit tests, otherwise you can easily face hour+ CI runs. The usual way I've seen this work successfully is if you get lucky and your project has very few overall code paths that you can test with e.g. integration tests and you can catch essentially all perf regressions there. > requires the team to master a new language that isn't the first choice for other code in the project I think you really need to have a good grasp of Java to write Clojure well (or you'll develop it as you write more Clojure). Both because the ecosystem makes liberal use of Java libraries and because otherwise none of the stack traces or even the optimization decisions listed in this article will really make sense. Clojure doesn't do much to hide Java from you (which has its own set of pros and cons).