Why Clojure? I’ll tell you why… | Hacker News Reader

Why Clojure? I’ll tell you why…

medium.com

6 pointsertucetin6 comments

"Clojure is a functional programming language, that runs on JVM"

...which means that the party is over: anything that I cannot permanently compile into straight machine code and generate a binary executable will have a double performance penalty: once to process the bytecode, and once to just-in-time compile it. Why would anyone in their right might settle for that? Please wait - compiling the planet... that's insane. It's far better to stick with one of ANSI common Lisps and get incremental, instantaneous compilation to straight machine code for any expression which evaluates.

To each their own, but in answer to your question "why would anyone in their right might settle for that?", where I am guessing you meant "right mind", one reason is because of the huge collection of Java libraries (and libraries written in other languages that run on the JVM) that can be easily called from Clojure. There are also some software deployment environments where the code must run on the JVM, or it is not considered for deployment, and Clojure can play well there.

Clojure on the JVM starts up in about a second with only the core Clojure code included. It can definitely take in the tens of seconds to read/compile-to-JVM-byte-code step for larger code bases that are not precompiled from source, but for long-running server processes, many people consider that a blip compared to VM startup times.

Of course that _is_ an issue for quick-running command line tools, and most people therefore don't use Clojure on the JVM for those purposes. Many _do_ use ClojureScript running on a JavaScript engine like node for such things, because its startup time is lower.

Someone ought to tell the 9 million Java developers that they're using a failed platform.

They don't listen :(

Why compile ahead of time when you know nothing about what the target platform is capable of? Why compile before profiling to make sure you run the correct optimizations? Startup times are sometimes important, but it's not the end-all-be-all of computer science.

It's not about startup times, just in time compiled code is slow in reality, and no contrived cases, of which there have been many, will change that. There is no profiling in just in time compilation. In order for a JVM to pull that off, it would first have to just in time generate code with counters, run that code, figure out when to analyse the results, then recompile and re-order it. That entire provess would make it run even slower than if it were interpreted.

Better then to do that once and generate optimized, reordered machine code and put the pedal to the metal during the lifetime of the program's run. Except there is no advanced optimizing compiler for programs which utilize a JVM, gee I wonder why... heh heh!

Reply on news.ycombinator.com