How do Clojure Programmers Deal with Long Startup Times


#1

Originally published at: https://purelyfunctional.tv/article/how-do-clojure-programmers-deal-with-long-startup-times/
Clojure startup times suck. Let’s just be honest. How do Clojure programmers live with that? Maybe that’s the wrong way to think about it.


#2

Don’t forget about test-refresh when using lein. It monitors your code for file changes and then does a re-compile and re-run. It is almost identical to having a traditional REPL except that you use your favorite editor to change anything in a file. It then reloads the entire file, so you rarely have any outdated definitions like can happen with the standard REPL. Also, you don’t have to manually re-evaluate the changed forms.

Try it and you’ll be a convert too!


#3

Ah! I did forget. Thanks @cloojure!

Eric


#4

I’m migrating my build tools to Lumo, as a ClojureScript developer. I’m not able to convert all of them now. But since Lumo is trying to cover ClojureScript building, I see a chance.


#5

This is harder than you’ve made it sound. Like carrying eight objects home without a bag is simple: practice juggling for two decades, then walk out of the store juggling eight objects.

There are a dozen ways the repl workflow fails, due to values captured in closures, due to defonce semantics in clojure built-ins, due to AOT that is required to interop with java, due to stale compile targets, due to things you’ve evaluated in the repl that you’ve forgotten about, etc. You have to design your app around these concerns, memorize all of the clojure features that affect them, remember everything you’ve done in the repl, and keep a close eye on the compile. You can work a week with all tests passing, then get a different result when you restart the repl, and a third result when you rm -rf target.

It’s extremely hard, and unreliable to be always working on a transient system that is the accumulated state of the things you’ve done in the repl.


#6

Hi @Brian_Craft,

I agree that these things are not trivial, and I had no intention of making them seem so.

But they are similar to concerns you’d have in any programming language. The more you know about how the system works, the more productive you’ll be, the better feedback you get, and the more you’re able to stay in flow.

One thing I left out of the article is that I do run lein do clean, test a final time from the command line before checking in my code, because this can fail even when the REPL doesn’t. Thanks for reminding me.

Rock on!
Eric