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
