Re: Proposal to turn off AOT in clojure-build-system

[Carlo Zancanaro <carlo@zancanaro.id.au>]

As someone who has worked as a professional Clojure programmer, I would
like to add my voice in support of this:

On Mon, Feb 19 2024, Ryan Sundberg wrote:
> ... In my experience using AOT is the exception rather than the rule;
> it is a nice optimization when practical for release engineering, but
> typically the juice is not worth the squeeze.

That is: the norm in the Clojure community is *not* using AOT, so there
isn't any specific statement against it. It's just assumed that you
won't use AOT unless you have a reason to do so.

Reading the clojure.org page about compilation[1] with this in mind, we
see four possible (although admittedly not exhaustive) reasons to
provide AOT compilation:
 - to deliver your application without source
 - to speed up application startup
 - to generated named classes
 - to create an application that does not need runtime bytecode
   generation and custom classloaders

I'm not convinced any of these apply across the board in Guix.
Potentially for some libraries and applications it does, and so should
be applied in those specific cases.

The next statement on the page, after those reasons to use AOT is: "The
Clojure compilation model preserves as much as possible the dynamic
nature of Clojure, in spite of the code-reloading limitations of Java."
Or, to read it another way: AOT compiled Clojure is not as dynamic as
on-the-fly compiled Clojure. This isn't a bug in Clojure, this is how it
is designed to function.

It could be argued that it is a bug in the individual libraries to not
work with AOT, but I think it's inappropriate for Guix to attempt to
impose "AOT is the right way to do things" on Clojure libraries. That is
not the norm in that community.

As a personal datapoint: I spent three and a half years working on
mission-critical Clojure libraries and applications, and I have never
used AOT compilation in production.

Carlo

[1]: https://clojure.org/reference/compilation