Hacker News Reader

Comment by amelius | Hacker News Reader

> The fascinating thing to me about Clojure is that it's so vocally a "practical" language

I tried Clojure, but the startup times were too large to the point where it became impractical. Especially for small scripts.

View on HN

If you read the history, you'll see that small scripts was never a use case targeted by Rich Hickey. It was focused on information systems programming, where a few seconds of startup time is a blip on the full running time of the application.

That said, slow startup times are only true of Clojure JVM. ClojureScript and Clojure babashka, for example, both start fast enough for small scripts.

Also, seems the JVM is slowly improving in startup time department. I was surprised to see that a hello world is now down to 800ms start time on my 2011 laptop with Java 14. It was 3s before with Java 8 on the same laptop.

For comparison, ClojureScript hello world was 550ms, and babashka hello world was 36ms. Python hello world was 68ms and Ruby was 111ms.

> Also, seems the JVM is slowly improving in startup time department.

It's not the JVM that makes Clojure JVM slow to start up, try comparing hello world in Java vs hello world in Clojure.

It's true that Java hello world will be faster than Clojure JVM hello world. That said, a big Java application with lots of classes to load, and lots of static initializers (which would approach the same number as what Clojure requires to be loaded and initialized) would take as much time as it does for Clojure.

So when people say that part of the slow startup is Clojure's fault, they mean more that it is implemented in a way that the JVM isn't very fast at starting. But if you look at Clojure implemented on other runtimes, like ClojureScript, the startup times are much faster, because the NodeJS runtime is much faster to start and initialize everything than the JVM is.

In effect, if the JVM improves startup times, so will Clojure JVM's startup times be improved. That's why I see this drastic difference between a Clojure hello world on Java 8 vs Java 14.

If you don't do aot compilation that might affect startup time negatively as Clojure will need to read and evaluate your code during startup.

And now with things like GraalVM and Babashka you can write programs and scripts that starts in a matter of milliseconds.

When have you tried Clojure?

Startup time was also a deterrent for me initially, but that was ~7-8years. I annoyed the heck out of me. I was doing Rails back then and that was too much too.

Nowadays however the situation is a lot better.

For scripts, you definitely should check out https://github.com/borkdude/babashka !

Startup time still annoys me, but I've learnt an practiced development enough that I'm leaving my REPLs open for days on end.

I use very few simple tricks to speed things up a bit:

I work Clojure cli tools (`deps.edn`) instead of `lein`.

Run `(compile 'my.main.namespace)` occasionally, when I add some bigger library to my project as recommended here: https://clojure.org/guides/dev_startup_time

And I think that's it.

You can further reduce this overhead if you are just using the the Socket REPL, but I think the best support for that (which allows evaluation interruption for example) is the Chlorine plugin for the Atom editor. I usually just accept the overhead of nREPL though.

Have you tried Babashka?

Startup time for Clojure itself has become pretty fast. My guess is you were using something like lein or boot which involves more than just starting up Clojure.

Either way, for scripting uses there are tools like babashka or lumo with sub second startup times.

You can create a graalvm native image for your Clojure app. You have to jump through some hoops to build it though.

Reply on news.ycombinator.com