It is a matter of implementation and tooling, not language.
Anyone is free to create a native AOT compiler for Clojure.
In fact many attempted to do so, but have given up due to the effort it means bringing a full eco-system up to speed to what Clojure already enjoys in JVM, .NET and JS runtimes, libraries and tooling.
Specially in quality of generated native code and GC implementations.
Obviously not if you are comparing it to the OCaml bytecode compiler, now doing a full AOT compilation to native code depends pretty much how those 3rd party libraries are delivered and optimization levels being used.
Not really, Java always had AOT compilers to native code, they just happened to be commercial and we all know how modern developers love to pay for their tools.
Java bytecode is what we mean when we say 'compile'. AOT is 'ahead of time' with regard to clojure, since it compiles to bytecode at run-time normally.
I'd love a Java AOT compiler that produces native binaries with no additional dependencies. (I'd even be okay if, as a side effect, some Java features were not supported, making it technically not-Java.)
For small tools and utilities, the JVM requirement is quite onerous, especially when one does not know if the end user has Java installed, or if they do, what version.
Alas, the company I work for will not budget for a Java AOT compiler, and for my hobby programming, the commercial Java AOT compilers are far too expensive to justify.
I'll just keep hoping a good and free (or inexpensive) Java AOT compiler becomes available some day. I would even donate money and/or code if a serious project started.
Yes, the fact being that there are a few commercial native AOT compilers for Java and all FOSS alternatives for AOT compilation fail to get any community support.
The free AOT compilers have atrocious compile times (far, far worse than even Rust or Scala) and don't support all of the features so library support is extremely fragile. A lot of extremely popular Java libraries make extensive use of runtime reflection and none of the AOT compilers handle it well without a lot of extremely error prone manual configuration.
I actually like Java and the JVM but if AOT compilation and efficient memory usage is what you want Java is definitely not the language to use.
if you mean clojure AOT, it precompiles clojure to jvm bytecode. Usually the term JIT in this context is used to describe the native code generated by the VM on the flight, not the on the flight VM bytecode generation performed by a higher level language like clojure.
Well, you could already AOT compile with NGEN, even though it isn't an optimizing compiler and requires dynamic linking.
Or Mono.
But I am with you, when Java and .NET came out, in both cases I thought it was a missing opportunity not having a full set AOT/JIT options similar to other languages.
You could get them, but NGEN required the framework to be present anyway and on Java's case the only good AOT compilers have always been commercial.
So I would remember Turbo Pascal, Delphi, Eiffel and many others with some envy.
Anyone is free to create a native AOT compiler for Clojure.
In fact many attempted to do so, but have given up due to the effort it means bringing a full eco-system up to speed to what Clojure already enjoys in JVM, .NET and JS runtimes, libraries and tooling.
Specially in quality of generated native code and GC implementations.
reply