The only reason Clojure is viable for production use is because it relies on the really good JVM GCs. How will Jank try to solve the the GC problem?
Python, Ruby, Go all seem to do ok with much worse GCs than Java.
The Jank Language: LLVM Hosted Clojure
61–70 of 83 posts
Re: The Jank Language: LLVM Hosted Clojure
#62Interesting project! I have been wondering why there isn’t a LISP on top of LLVM yet (except Common Lisp port, Clasp). Good that someone started to work on this.
ECL and Chicken Scheme both build with whatever C compiler you're using.
Re: The Jank Language: LLVM Hosted Clojure
#63It'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.
Everything on the landing page talks about jank's goals and aspirations. 100% Clojure compatibility is a big one. The progress page starts with this disclaimer: > jank is under heavy development. It's safest to assume that any feature advertised is partially developed or in the planning stages. There is no sales pitch here; just a lot of work and some big plans. All development happens on Github, so watch the repo th…
Honestly I don’t think compatibility with “pure Clojure” is that useful. Almost everything has a couple of native calls hidden away.
Re: The Jank Language: LLVM Hosted Clojure
#64Earlier quoted context omitted.
The landing page explicitly says "jank is 100% compatible with Clojure." not "jank aims to be..." No, "jank IS" this is... ridiculously uncool and misleading.
Thanks for the feedback. The usage of "jank" here refers to its design; the concept of jank. This is different from its current implementation. jank is designed to be many things, as the landing page shows, and the implementation is catching up with that.
No matter how you spin it, this makes the landing page very misleading.
Nobody cares about the "design" of a language when there is no implementation that fully realizes the design. Otherwise, anyone can say "my language is 100% compatible with clojure, but oh, yeah, the clojure compatibility part isn't fully implemented yet".
If your landing page said "jank's goal is to be 100% compatible with clojure", or "jank is designed to be 100% compatible with clojure (when fully implemented)" that would be fine. Right now the statement is just false, because right now, the language isn't 100% compatible with clojure.
I really think you should change the wording -- and I say that as someone genuinely interested in the project. I hope you achieve 100% clojure compatibility, that would be really cool. With the way things are worded now the first impression you are giving people is that the language implementation is way more complete than it is, which I believe will be a big negative for you in the long run.
Re: The Jank Language: LLVM Hosted Clojure
#65See also babashka, a native Clojure implementation for scripting. https://github.com/babashka/babashka
babashka is great for scripting, but it is basically is a Clojure interpreter written in AOT compiled Graal-compatible Clojure.
Because is is AOT compiled is starts fast, but its much slower than JVM-Clojure for long running tasks.
A natively compilable Clojure would be great for other use cases, especially if it can be made more memory-efficient (Clojure is a memory hog)
Re: The Jank Language: LLVM Hosted Clojure
#66Really cool! The repl is great for development, but static binaries are great for deployment, this may give us both.
Re: The Jank Language: LLVM Hosted Clojure
#67The only reason Clojure is viable for production use is because it relies on the really good JVM GCs. How will Jank try to solve the the GC problem?
Python, Ruby, Go all seem to do ok with much worse GCs than Java.
The difference is Clojure's persistent data structures. You don't add an element to an array, you create a new copy of the array with the element attached, and the old array is accessible.
Internally this is done with structural sharing, so it's way faster than copy on write, but it's still potentially allocating a half dozen objects for what would usually be a trivial operation that does not involve allocation.
On the plus side, Clojure in theory has some pretty nice guarantees that older objects can't point to newer objects. From memory Haskell takes advantage of these guarantees to accelerate its version of eden. There may be a way to get a fast GC that's not nearly as complex as the full JVM GC.
Re: The Jank Language: LLVM Hosted Clojure
#68Earlier quoted context omitted.
Python, Ruby, Go all seem to do ok with much worse GCs than Java.
The difference is Clojure's persistent data structures. You don't add an element to an array, you create a new copy of the array with the element attached, and the old array is accessible. Internally this is done with structural sharing, so it's way faster than copy on write, but it's still potentially allocating a half dozen objects for what would usually be a trivial operation that does not involve allocation. On t…
Does Clojure really compete closely in overall performance with other immutable-first languages like OCaml/Standard ML?
Re: The Jank Language: LLVM Hosted Clojure
#69Earlier quoted context omitted.
The difference is Clojure's persistent data structures. You don't add an element to an array, you create a new copy of the array with the element attached, and the old array is accessible. Internally this is done with structural sharing, so it's way faster than copy on write, but it's still potentially allocating a half dozen objects for what would usually be a trivial operation that does not involve allocation. On t…
Does Clojure really compete closely in overall performance with other immutable-first languages like OCaml/Standard ML?
This is all a bit of a distraction though.
> The only reason Clojure is viable for production use is because it relies on the really good JVM GCs. How will Jank try to solve the the GC problem?
I think this original statement is wrong because people are fine with poor performance (see Python, Ruby) if the language (ecosystem) is effective. And Clojure is effective (IMO) moreso because of the JVM ecosystem not the JVM's performance.
Re: The Jank Language: LLVM Hosted Clojure
#70Earlier quoted context omitted.
Everything on the landing page talks about jank's goals and aspirations. 100% Clojure compatibility is a big one. The progress page starts with this disclaimer: > jank is under heavy development. It's safest to assume that any feature advertised is partially developed or in the planning stages. There is no sales pitch here; just a lot of work and some big plans. All development happens on Github, so watch the repo th…
Honestly I don’t think compatibility with “pure Clojure” is that useful. Almost everything has a couple of native calls hidden away.
Most libraries I tend to use are generally pure Clojure, with some reader conditionals at the edges. jank will also support reader conditionals, so those libraries can grow to support C++ interop where needed.