11–20 of 83 posts
It's extremely interesting, but it has a to be noted that, even though the main page claims 100% compatibility with Clojure, the status page lowers the claim down to 42%, while the GitHub page states you can't even build it.
It states that it's not very buildable i.e. that the build process is very fragile. Building it with nix definitely works, I just tried it.
They are basically trying to make my new dream language.
The only thing I am worried about is compile time. It seems many projects using LLVM have trouble with that. See Julia with its LLVM JIT, though they did manage to improve it somewhat. I guess it is simply to early to tell, lets hope for the best.
Exciting idea, I love Clojure, but every time I tried Clojure, I found myself butting heads with the Java ecosystem, and I always wished it had its own ecosystem and interpreter/compiler. I will caveat that that's just because I've never spent long in the Java ecosystem, so it's not a criticism of the current Clojure + Java ecosystem, more my own lack of experience.
Not sure interop with C/C++ would be somehow easier.
If they could pull off easy integration with the C and C++ world that would be an absolute killer feature. They are basically trying to make my new dream language. The only thing I am worried about is compile time. It seems many projects using LLVM have trouble with that. See Julia with its LLVM JIT, though they did manage to improve it somewhat. I guess it is simply to early to tell, lets hope for the best.
I’m very interested in runtime performance as well, though, and how it compares to vanilla JVM-based Clojure.
I'll be curious to see what the performance comparisons of typical Clojure programs will be. Persistent data structures tend to benefit a lot from highly optimised garbage collectors like those packaged with the JVM. And Clojure's highly dynamic style probably benefits a lot from JIT techniques too. Still, it's a fascinating project, which I will watch closely.
Why would this be important? Well because they are relying on LLVM for optimization, and while that's good if you know type info (via annotations or lower tiered profiling), there's a lot of code to start using this and those optimizations can be fragile.
If you read the articles posted here in the past year on the Erlang JIT they mirrored this sentiment, earlier "advanced" JIT attempts built on classic static language techniques like LLVM prefers failed because they didn't have enough type information, whilst the "simple" JIT that mainly removed overheads and concerned more with local types was showing good promise without too much engineering headache.
> Where jank differs from Clojure is that its host is C++ on top of an LLVM-based JIT.
So this is similar in kind to pypy? (or maybe hy on pypy..).
Exciting idea, I love Clojure, but every time I tried Clojure, I found myself butting heads with the Java ecosystem, and I always wished it had its own ecosystem and interpreter/compiler. I will caveat that that's just because I've never spent long in the Java ecosystem, so it's not a criticism of the current Clojure + Java ecosystem, more my own lack of experience.