jank

How much does this overlap / complements something like jank ? [1] How much "production ready" / "battle tested" would this be ? (Not to start a flame war, I'm genuinely curious about the differences.) [1] https://github.com/jank-lang/jank

The problem is using the build system. Using Nix flakes could help alleviate a lot of concerns, I wrapped a target meant for debian. After wrapping it with a flake, it worked on NixOS. But since I'm building it declaratively and not imperatively, it could target any distribution, even mac. I've done this with Bitwig, https://github.com/ArikRahman/Nixwig and Jank lang (https://github.com/jank-lang/jank) in this PR: https://github.com/NixOS/nixpkgs/pull/523741

The first three paragraphs here are on point! jank's IR passes will not worry much about things like load/store optimization, register allocation, inlining C++ functions, etc. These are in LLVM's domain. We just worry about the Clojure side of things. Polymorphic math is intense, but we do our best to avoid the extra work by unboxing whenever possible. > A future optimisation might be to specialise for unboxed types: far more potential speed improvement over pointer tagging, and IMO quite amenable to analysis with the Jank IR All of these math functions are templates with four specific categories: 1. Object and object 2. Primitive and primitive 3. Primitive and object 4. Object and primitive We handle the difference between typed objects (like integer_ref) and type-erased objects (object_ref) as well. This template then gets inlined, whic

The thread is locked so I cant add it there, but if you wanted to jank-lang could be added to your prior-art section: https://github.com/jank-lang/jank?tab=contributing-ov-file#a...

I'm working on the jank programming language! https://github.com/jank-lang/jank It's a native Clojure dialect which is also a C++ dialect, including a JIT compiler and nREPL server. I'm currently building out a custom IR so I can do optimization passes at the level of Clojure semantics, since LLVM will not be able to do them at the LLVM IR level.

Lisp didn’t really disappear, symbolic AI did. Lisp was ideal for reasoning systems, its homoiconic and meta-programmable nature is perfect for manipulating symbolic structures and logic. But when AI shifted toward numerical learning with neural networks, tensors, and GPU computation, Lisp’s strengths mattered less, and Python became the new glue for C/CUDA libraries like NumPy, PyTorch and TensorFlow. Still, nothing prevents Lisp from coming back. It would actually fit modern deep learning well if a "LispTorch" with a CUDA FFI existed. We would have macros for dynamic graph generation, functional composition of layers, symbolic inspection, interactive REPL exploration, automatic model rewriting etc. We almost had it once: Yann LeCun’s SN (the first CNN) was built on a C core with a Lisp interpreter on top to define, develop and inspect t

Ok so jank is Clojure but with C++/LLVM runtime rather than JVM. So already all of its types are C++ types, that presumably makes things a lot easier. Basically it just uses libclang / CppInterOp to get the corresponding LLVM types and then emits a function call. https://github.com/jank-lang/jank/blob/interop/compiler%2Bru...

I expect that jank will be migrating from C++ to Rust, at some point. https://github.com/jank-lang/jank

>If someone could give me the ergonomics of Clojure, but without the JVM and the ability to easily target 1/ native (incl easy bidirectional C iterop), 2/ wasm, and 3/ support both in aot and runtime + JIT modes, I would switch in a heartbeat. Might want to look at Jank (https://jank-lang.org/, https://github.com/jank-lang/jank). It's still in it's early stages but it's basically all you're hoping for!

Transducers, in Clojure, are implemented in Clojure, rather than in Java. In jank, the Clojure source for transducers is exactly the same. For example: https://github.com/jank-lang/jank/blob/a14f4d7c7e8097d5ab588...

I definitely asked for it. I'm using Cling for JIT compiling my native Clojure dialect: https://github.com/jank-lang/jank Without Cling, this sort of thing wouldn't be feasible in C++. Not in the way which Clojure dialects work. The runtime is a library and the generated code is just using that library.

I'm using Cling for JIT compiling my native Clojure dialect: https://github.com/jank-lang/jank Trying to bring C++ into the Clojure world and Clojure/interactive programming into the C++ world.

There will be a lot of room for this, once I build out more of the features. In particular, there will be a lot of Clojure libraries which need to gain jank support. Clojure doesn't require "porting", so to speak, since it has a special .cljc file which can use reader conditionals to check the host that it's in (clj, cljs, cljr, jank, etc). So anywhere those libs are using Java interop, we'd need to wrap it to use native interop instead. On the compiler and tooling itself, I have some open issues here: https://github.com/jank-lang/jank/issues The vast majority of it is heavy C++ work, though. Outside of that, the biggest gains will come from time spent on packaging, distribution, and testing on various platforms. And if none of that sounds interesting or applicable, don't worry. Just be sure to join the Slack channel and hang out with us.

Unless I'm reading it wrong, it sounds from the license[1] like programs made with Jank that you want to distribute must have their source available. If the intention is that distributions of the _Jank compiler itself_ are the only things that need source available, I think it'd be good to spell that out. [1]: https://github.com/jeaye/jank/blob/main/LICENSE