Hacker News Reader

Comment by slifin | Hacker News Reader

Clojure doesn't mean digging into the Java world

Use Graalvm if you want native quick starting binaries or start learning Clojure via ClojureScript

Clojure means running the JVM, and if you are serious about performance and monitoring in production then it definitely means getting into the JVM world. And let's be honest, most of the performance and monitoring tools are written in Java.

Writing the code is really the first stage of commitment to a language or platform. You are going to spend way more time running code than you spend writing it. The choice of platform is therefore more important than the choice of language in a lot of ways, and Clojure runs on the JVM (or some JVM-like solution like Graal) so you better have some JVM experts around.

I'm pretty sure, if someone goes on stage at any Clojure conference and asks: "how many of you had to use JVM performance and monitoring tools" there won't be too many hands. And if you ask "how many of you have to read or write Java code every day to maintain your Clojure stack" there won't be too many hands either. You don't need to be an expert in JVM to successfully build, deploy and maintain stuff written in Clojure. It helps, but that's hardly a requirement. None of the most popular Clojure books really dive into JVM - it is not needed.

> Use Graalvm if you want native quick starting binaries or start learning Clojure via ClojureScript

Yes this is very slick, but still a bit bleeding edge IMHO.

I do know the small "binaries" of Clojurescript via the Closure compiler tree shaking/dead code removal means that run time macros/eval is not available..

Is this the same for Clojure/JVM on GraalVM? i.e. are eval/run time macros disallowed/removed to attain small binaries and fast start up?

Yes

Reply on news.ycombinator.com