(2) does not completely cancel things out as compile won't recompile everything - only the things that have been changed. That being said, I had a couple of problems with AOT solving which cancelled out that 3 second benefit for the next few years. :)

Interesting, I hadn't considered that

We're thinking of AOT'ing the frontend compiler pipeline, based on shadow-cljs. I don't foresee any caching problems there For the backend, we'll have to try and see if there are issues. Alex Miller has written encouraging words here: https://ask.clojure.org/index.php/11656/could-an-aot-compilation-cache-speed-library-loading-times?show=11666#c11666

When you compile CLJS, most of the time is spent doing actual compilation/optimization. And AOT'ing things will only speed up namespace loading.

Yes, loading namespaces is 3s or more on an M1 for us

A significant chunk of the 16s from process start to the compile assets being ready-to-use

I just timed it: • compile takes 4s with an empty classes/ • on subsequent runs it takes 1s So it's faster but not 100% free

Ah, alright. In my projects, UI compilation takes ~30 seconds usually, so I wouldn't bother with 3 seconds at all. :)

This is what I've done for 2+ years: • make the -Dclojure.compile.path= dynamic, it's target/<Lein profiles or clojure aliases><hash of classpath> • only compile, programatically, namespaces that are detected as 3rd party dependencies (e.g. clj-http.core -> yes, my.project.core -> no) This way there aren't staleness or other issues. I don't necessarily recommend implementing any of this yourself, unless you intend to create a fully reusable tool / workflow.

There's still room for issues, e.g. when some third-party dependency does anything non-pure at namespace load time, apart from just defining new things.

I haven't encountered that. Anyway I'd consider that a bug that would make me at the very least report the issue. And make me reconsider the quality of the lib :)

Right, of course. But just a single incident like this negates all the gains you could possibly get from AOT, at least when you're a solo developer on a project.

It depends, because I use the same AOT setup in all projects. And I think I'd be happy to encounter a problematic side-effect - would be a net gain for the lib, and maybe for me / my project in some indirect way

I guess it also depends on how many times you restart your repl and need to reload everything from scratch, if you set it up for long runs (like even days) then some extra seconds should be nothing

For my own part I just don't bother to care about dev startup time and just don't restart my repl more than a couple times a week at the most.

though it is quite an art form to get everything right so the repl doesn't need to be restarted

For the most part I consider AOT a release-only activity, at which point you get every ounce out of it you can including direct linking, stripping metadata, etc.

That's a good point @U0739PUFQ. It's also a common hangup. I wrote an article about it a little while back that may help some people though! https://srasu.srht.site/var-evaluation.html

Apart from what is described in that article, in my experience I think the problem is that I need to constantly keep an eye and be very aware of where the state is, which is manageable in my own projects code but as soon as I bring other people libraries (specially java ones) then as soon as I get some non obvious error I tend to want to restart the repl, just to discard something being in an inconsistent state. I find easier to accomplish in projects I tend to touch every day since I tend to have most of it on my head and put effort to tweak my flow so I don't need to restart the repl, but maybe not so easy in a multi person project. What varies on each project is how confident I am that the state can't get into inconsistent states by messing with it

but 100% I prefer to put my time in tweaking so I don't have to restart my repl, than into making it easier and faster to restart

Tools.namespace + hook in intellij to refresh in save?

Yes, I was wondering about a hook in IntelliJ. But it just occurred to me that Cursive has a "run last test" command which I have already bound to a keychord (and another keychord runs the test under the cursor), so really I am good to go, I just have to set up tests as needed. Thx!

You might be working under different circumstances, but I like to work with the REPL, and eval a form, and the eval'd form instantly becomes effective in, say, my Swing app or web server. For times when I wish to shut down the app, reload "changed" namespaces, and restart the app, I like to combine Sierra's "Component" (which is competent in the area of shutdown/startup sequences) and this little library https://github.com/ciderale/quick-reset, last commit 9 years ago!, whose README cites Sierra's "reloaded" essay.

Shameless plug (though is it still shameless when you're not charging anything...?) of https://github.com/gnl/playback/, which has some middleware that you can configure to call reload/refresh functions when loading stuff in the REPL. Have only used that functionality in a ClojureScript context so far, but it should work just fine in Clojure. You might find it useful (and do let me know how it goes if you try it.)

You can also mix tools.namespace with hawk https://github.com/wkf/hawk

Thanks all! The nice thing about ^Q, the keychord I have bound to "Re-run last test" is that wherever I happen to finish my editing, Bam, I just hit ^Q. Evalling forms in a comment is great for small, ad hoc tasks, but after hacking here and there across a project it is great to have a keychord save, recompile and re-run. Thx again. 🙏

Yes. This is usually done with babashka.process/shell

(require '[babashka.process :refer [shell]])
(shell "qutebrowser") ;; or whatever

Thanks! Is shell a choice or is this code working as is?

babashka.process is a built-in library, if that's what you're asking

Why do you think it's wrong? What is the expected behavior and what behavior are you seeing?

btw, you're nesting the second libspec in the require form under the first

your require vector includes the other

(require '[babashka.process :refer [shell]]
         '[hiccup2.core :as h])
;; vs
(require '[babashka.process :refer [shell] ;; note this one is not closed here
           '[hiccup2.core :as h]])

(require 
  '[babashka.process :refer [shell]] 
  '[hiccup2.core :as h])

Great thanks! How can I get the hiccup printed as html?

(h/html [:div ...]))

Thanks a lot!