The performance difference between Clojure and the pure Java implementations was much smaller than I'd thought. Quite amazing for a dynamically typed language to get so close to Java in performance, to be honest.
The ring-clojure performance was much lower than the Java equivalent, but that's expected because de-serialization can be A LOT faster when you use static types for guiding parsing (e.g. cache the string keys and never allocate object keys, maybe small values that are common as well). I wonder if Clojure contracts could be used for the same tricks.
That's not surprising given that they rewrote all the middleware in Java and the Clojure part was just a very thin wrapper around vertx. And that's fine, it's what makes Clojure usable in production, but the vast majority of Clojure users bash Java all the time, take this libraries for granted and ignore the fact that a big range of software for the JVM is better written in Java than in Clojure.
The clojure pieces are nothing more than a wrapper which is exactly what clojure is best used for.
* "Clojure frees developers from the perils of writing concurrent programs, but at a price."
* "When concurrency is not a factor, consider using Java."
Pure FP generally scales well with caching/memoization, because functions are pure, and with concurrency, because data is immutable. However the paradigm typically allocates more garbage and often creates more indirection due to its declarative nature (think function composition/pipelines/laziness and so on). So it is not as suitable for fine-grained/low level optimizations as imperative programming.
If your service doesn't take your server to its edge, which is most often the case, then there really isn't any advantage writing parts in Java as far as performance is concerned.
This approach shines in those cases where you deal with very high throughput.
