51–60 of 83 posts
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?
Yes, naming things is hard, but, "jank"? Yikes. "Jank" describes undesirable, problematic, glitchy UX. I genuinely thought that the title was denigrating Clojure on LLVM. Maybe it's intended to be funny or ironic, and if it catches on it won't matter, but it sure seems like a footgun.
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.
The reason julia has so much compiler latency is not that we have a slow compiler, it’s that we compile a LOT of code.
Julia is very very (runtime) performance oriented, and so we do everything we can to speed up execution time. This means that we have very aggressive code specialization, inlining, and unrolling heuristics, and people take heavy advantage of them. It’s a very normal thing in julia to try and write very high level generic code that performs like low level optimized code by taking advantage of versions code generation techniques.
In addition to all of that, we end up recompiling a lot of code that was already compiled before because we have very strict heuristics to make sure that when a method body is altered, all downstream dependants of that method get invalidated and must be recompiled, and sometimes the heuristics overeager.
Julia compile times have been dropping rapidly over the past couple years mostly because people have put a lot of work into avoiding invalidations, and being smarter about how compile-time code generation is approached. Almost none of that improvement has to do with LLVM, it all happens well before we hand things off to LLVM.
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.
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…
not "jank aims to be..." No, "jank IS"
this is... ridiculously uncool and misleading.
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.
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…
Earlier 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…
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.
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.
Love this. As a Lisper I’m always intrigued by Clojure but as someone with no knowLedge of or desire to learn to JVM I stayed away since I figured eventually I’d hit JVM questions/issues I frankly didn’t feel like dealing with. Is it really 100 percent compatible with Clojure or is that just aspirational. Also, is it the case that lots of libraries/workflows outside the core language in Clojure assume Java integratio…
Basic Java interop is pretty simple (and concise!). But unless you're specifically needing a Java library, you won't even do this much. You _can_, but it tends to be more for performance optimization in my experience.
In other words, don't be scared of JVM. I would say it's kind of like Elixir/Erlang. You can do real things with Elixir without knowing hardly anything about Erlang. Of course, later on you can do more awesome things if you know how and when to leverage the Erlang VM. Same probably goes for Clojure/JVM.
Earlier 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…
Can you explain the type checking a bit more? Is this occurring within the JIT for compilation efficacy or is the goal here that you would get gradual type inference across a codebase facilitated by some kind of LSP?
During AOT compilation, though, jank does whole program analysis and uses the type information to box/unbox, monomorphize, compute at compile-time, etc. I'll be publishing documentation on each of these designs (the type system, the JIT, the interop support) on the website as things move forward. Stay tuned. :)
Earlier quoted context omitted.
Why not use something like https://github.com/ruricolist/cloture (a Clojure "adapter" that runs on Common Lisp) if you want that?
That seems very abandoned.
https://github.com/clasp-developers/clasp/
> Clasp is a new Common Lisp implementation that seamlessly interoperates with C++ libraries and programs using LLVM for compilation to native code. This allows Clasp to take advantage of a vast array of preexisting libraries and programs, such as out of the scientific computing ecosystem. Embedding them in a Common Lisp environment allows you to make use of rapid prototyping, incremental development, and other capabilities that make it a powerful language.