Not just the API changes, the LLVM IR syntax can change drastically as well. E.g. not too long ago they switched from types pointer types to opaque pointers. `i32*` just becomes `ptr`. [1]
bumping only on major release is recipe for pain and misery. everyone project i'm familiar with bumps weekly against HEAD. much more manageable.
I'd target MLIR (like Mojo does).
1. It's a much easier/better target to work with.
2. It's a strict super-set of LLVM IR.
3. Much better optimizations are possible that are specific to your language.
Separately, I'd love to have a Clojure-friendly interface to MLIR—whether via Jank or something else.
That being said, what would be the benefits of a native clojure, you have common-lips and guile if you want native
But again, Jank is not clojure .. just clojure-like, or so it seem
People use the Clojure that is the right fit for the environment they need to operate in, so arguments about authenticity don't tend to come up. Clojure has always been positioned as a pragmatic Lisp and the situation very much reflects that.
The OG Clojure is the one for the JVM and for some people this will always be the only "real" one in some sense, because JVM interop is a huge deal - it gets you access to tons of high-performance Java libraries. If you're writing server-side Clojure that's hard to beat.
But the other clojures have strengths in their niches. If you're writing for the browser, JVM interop doesn't buy you anything but JS interop does, hence ClojureScript. If you're doing a lot of shell scripting you'll probably want babashka for fast startup times. If you're doing mobile+desktop GUI development with Flutter you'll use ClojureDart (if you use Clojure at all).
Jank is aiming for C++ and I'll be curious if there is an interop story there. But again if you're looking to interop with an existing C++ code base it's sort of academic to ask whether Jank is "real" clojure or not.
That's a big part of why Jank is interesting to me, because it can properly embrace the idea of runtime JIT using LLVM. The JVM may still have an edge with profile-guided optimization for the foreseeable future, but perhaps Jank can help close that gap and support even more advanced possibilities for data-intensive workloads, e.g. along the lines of https://www.lingo-db.com/
Already, jank is faster than native images in the benchmarking I've done. The largest benchmark, so far, was a ray tracer.
jank is Clojure. If it works on Clojure JVM and it works on ClojureScript, it should generally work on jank. Clojure doesn't have a language specification, but the community knows what a proper Clojure should feel like. Strong Clojure compatibility means anything outside of interop should just work. Naturally, interop on Clojure is very host-specific; Clojure JVM does one thing, ClojureScript does another, Clojure CLR does a third thing.
> That being said, what would be the benefits of a native clojure, you have common-lips and guile if you want native
At this point, we'd be discussing the benefits of Clojure over CL and Guile, which ends up being a different discussion. jank is for Clojure devs who want a native host and good native interop. It's also for native devs who want to introduce interactive programming and FP into their systems.
I looked at github and came away with the impression it's very much still a work in progress, but you seem to imply it's closer to being complete?
Does nrepl work well? Can I just load a relatively arbitrary cljc file?
This discussion made me check it out as I'd like to use it in conjunction with some C++ files/libs, but looking at the project left me really quite unsure as to it's current state.
The majority of this is captured here: https://jank-lang.org/progress/