Hey folks. I'm the creator of jank. I didn't expect to be on HN today, but I appreciate the interest.<p>In short, jank is Clojure, but it's on LLVM and has seamless C++ interop. You still get full nREPL capabilities, can redefine anything on the fly, and we can actually JIT compile C++ code alongside your Clojure. The seamless C++ interop is first of its kind, for a lisp, and is done by JIT compiling C++ alongside the LLVM IR we generate for jank and then stitching them together into one IR module.<p>Note, jank isn't released yet. I'm targeting the end of this year for the first alpha release. I put out monthly development updates on the jank blog, with the next one coming out this week.
beautiful work. clojure is very nice. one of the most impactful talks I have ever seen was from Rich Hickey - simple made easy.<p>however my only gripe with clojure while it's easy to write and comprehend at first - it's difficult to read. & yet most our time we read code not write it. but then again it might be my lack of brain power.
I agree with you, but perhaps in my own way. Jumping into an arbitrary Clojure program can be tough, since the data shapes may not be defined anywhere. Hopefully the program uses spec or malli, but even then, unless they annotate every function with the shape it expects, you may be left needing to REPL in and poke around. However, REPLing in to check just a function or two may not be easy if the program requires some setup and doesn't use integrant or similar.<p>Once Clojure parity is achieved, I'm interested in static typing, pattern matching, value-based errors, and some other opt-in improvements that I think will greatly improve both readability and toolability (i.e. how well tooling can work with the code, based on what it knows of the code). Stay tuned. :)
My comment to code ratio is magnitudes higher in Clojure than in other languages, which helps a lot with this.<p>Also writing Clojure can be incredibly terse, resulting in quite high-effort when reading. Conversely, a lot of time I can condense hundreds of lines of equivalent python into 5 or 6 lines of Clojure. Having all of this functionality condensed into something you can fit in a tweet really helps for grokking larger parts of the dataflow or even larger system. So there are tradeoffs<p>Plus structural editing and the repl really help with the “reading” experience (reading in quotes because it’s much more interactive than reading)
> Conversely, a lot of time I can condense hundreds of lines of equivalent python into 5 or 6 lines of Clojure.<p>I'm curious if you have any example of this? Even if it's an hyperbole, I don't really see how.
In my (limited) experience with Clojure and other functional languages, this is usually true under situations where:<p>1. You’re mapping or reducing some dataset<p>2. Your iteration logic does not branch a lot<p>3. You can express your transformation logic using higher order functions (e.g. mapping a reduction operation across a multidimensional array)<p>Some domains have a log of this style of work—finance comes to mind—others do not. I suspect this is why I’ve personally seen a lot more of Clojure in finance circles than I have in other industries.
I’m a bit curious why you chose to implement this as a different language (even though it implements Clojure) instead of an alternative Clojure backend and/or C++ syntax extension.<p>Do you plan to make Windows support first-class? I think a lot of people looking at LLVM based languages are interested in alternatives to C++ for games.
> I’m a bit curious why you chose to implement this as a different language (even though it implements Clojure) instead of an alternative Clojure backend and/or C++ syntax extension.<p>jank is Clojure. However, the Clojure name is trademarked and using it requires permission which I don't have. Furthermore, I want to build upon the Clojure base to provide more, going forward. That may include static typing, value-based error handling, first class pattern matching, and so on. Those would be opt-in features on top of Clojure. All of these reasons lead me to not use Clojure in the name (like Clojure++, ClojureNative, etc).<p>> Do you plan to make Windows support first-class? I think a lot of people looking at LLVM based languages are interested in alternatives to C++ for games.<p>Indeed, a lot of game dev folks use Windows. Right now, jank's Windows support is limited. My initial audience is Clojure devs who want native access and lighter binaries. Once that launch has stabilized, I will focus on appealing to existing native devs who want to embed an interactive, functional language into their C++ applications. That will requires strengthening the Windows support, establishing stable native APIs, and writing the onboarding material for lisp, REPL-based editing, data-driven design, and so on. This is a much larger task, which is why I'm focusing on existing Clojure devs first.
Shouldn't it be an 'if' instead of 'when' in the first example?
I love this project. I've been a sponsor on GitHub since late last year.<p>But for the love of... please pick a different name.<p>Whatever reasons companies/teams will have for not letting someone use Jank at work, don't let the name be one of them.
You're in luck ;)<p><a href="https://jank-lang.org/blog/2025-04-01-jank-has-been-renamed/" rel="nofollow">https://jank-lang.org/blog/2025-04-01-jank-has-been-renamed/</a>
I love the name Jank. I would use it just for the name alone.
What's the objection to the name? I don't get it.
What's the demonym for Jank devs? Janker?
Yes but pronounced in the Nordic and Central European fashion (“yanker”)
Jankobian?
Still deciding. Maybe jankster.
Jankobite? Ehhh<p>I love this project, and frankly I can't wait until I see Zig code stitched into and interoperating in a lisp via C transpilation, but I really do agree with the top commenter if you can't get Clojure trademark approval.<p>Anyways, keep up the amazing work, I wish I could have seen your janky talk at Strangeloop on another timeline.
I suppose jank-yanker is off the table.
The cute form would be Jankiye
When there's a book, whoever does the illustrations should be a jankee doodle.<p>... Right, I'll show myself out.
I remember Clapp a Common Lisp in C++ using LLVM. Clapp was promising but progress has been very slow. Since Clojure is similar to CL, one wonder if Jank will experiment similar problems. Might I ask the author of Jank whether he knows about Clapp and if so, how will this project try to avoid getting stagnated?<p>Edited: Here is a post in HN from 2014 about Clapp. <a href="https://news.ycombinator.com/item?id=8367404">https://news.ycombinator.com/item?id=8367404</a><p>In that post and comments we read that Clapp was 100x slower that sbcl, and the author of Clapp claimed: "LLVM is a great library for implementing C and C++ but more work needs to be done to support Lisp features like closures and first-class functions. We are working on that now".<p>I hope Clapp's author work in the last 11 years could help today efforts. Surely, the LLVM of today is not that of 11 years ago. Anyway, IMHO, sharing some knowledge could be productive for any project that is about C++, Lisp or Clojure using LLVM.<p>If I recall correctly, compiling Clapp takes a full day, that gives not a good vibe.<p>On the happy path, I think that Julia transpile to LLVM, but Julia is the result of many men working years at it. Honestly, I don't think that one single programmer to be able to create such a big project as a performant clojure in C++ will the ability to compile code quickly. Getting sbcl speed and compilation speed would be an extraordinary feat!<p>In Go there were great sacrifices to get fast compilation, and the problems to include generics, trying to avoid blows up compilation because some type checking is NP-complete.<p>Also perhaps ECL, a lisp in C, can gives us some hints about how to get better performance and compilation speed.<p>Perhaps I am just too old to be open to new dreams, anyway I hope the best to this project and I thank to Clojurists Together for supporting this project. It must be very intellectual rewarding to work in a project whose aim is to extend and improve your favorite computer language. But the journey will be no an easy one, that's for sure.
> Might I ask the author of Jank whether he knows about Clapp and if so, how will this project try to avoid getting stagnated?<p>I'm aware of Clasp and have spoken with drmeister about it in the early days of jank. Ultimately, jank and Clasp differ greatly, not only in that jank is Clojure and Clasp is Common Lisp, but also in their approach to C++ interop.<p>> If I recall correctly, compiling Clapp takes a full day, that gives not a good vibe.<p>I'm not sure about Clasp's compile times, but C++ is slow to compile, in general. The jank compiler itself builds from nothing in about 1 minute on my machine. We've yet to see how the jank compiler will handle large Clojure project, but I do expect it to be slower than Clojure JVM.<p>> In that post and comments we read that Clapp was 100x slower that sbcl<p>That's an old post, so I'd expect that Clasp is faster now. I can say that jank is not 100x slower than Clojure JVM, in my benchmarks.<p>> Perhaps I am just too old to be open to new dreams, anyway I hope the best to this project and I thank to Clojurists Together for supporting this project. It must be very intellectual rewarding to work in a project whose aim is to extend and improve your favorite computer language. But the journey will be no an easy one, that's for sure.<p>Thanks for the interest and kind words. It's not easy, but it's doable!
Clasp, not Clapp, and it's still getting releases. 2.7.0 was released in January, and 2.8.0 is pending.<p><a href="https://github.com/clasp-developers/clasp">https://github.com/clasp-developers/clasp</a>
I am once again calling for someone to make something that's "basically clojure" but with whitespace instead of parens.<p>Parens don't matter, but giving values names causing indentation is something I simply cannot abide as a terminal intermediary value name giving person.<p>EDIT: oh and also something with "proper" multiline comments. Thanks!
I'm interested in exploring this as a potential dialect of jank. In the simplest approach, it's just a lexer change. However, there are implications around how macros will work, since macros generate s-expressions in Clojure, but they'd need to generate whitespace blocks if we want the homoiconicity to spread throughout.<p>If you're interested in funding this work, or helping with the designs, please reach out. In the meantime, make sure you check out Rhombus. <a href="https://rhombus-lang.org/" rel="nofollow">https://rhombus-lang.org/</a>
Right, it's hard to disconnect some of Clojure's niceties from the macro work (though I think Clojure's macros tend to do less inner inspection than macros you'll see in other lisp variants)<p>The link to Rhombus is very interested, I hadn't heard of this and it looks very well developed. Will mess around with it.
This exists. <a href="https://yamlscript.org/blog/2025-06-24/how-does-ys-work/" rel="nofollow">https://yamlscript.org/blog/2025-06-24/how-does-ys-work/</a><p><a href="https://yamlscript.org/about/" rel="nofollow">https://yamlscript.org/about/</a> - YAMLScript (or YS) A graal pre-compiled Clojure environment, like Babashka, but uses a different, looser syntax (yaml based). Can run from command line.<p>Like a nicer Python?
Since this appears to be the marquee feature (compared to the well regarded Clojure) it would be good to see some benchmarks comparing the JVM to LLVM versions.<p><i>This allows jank to offer the same benefits of REPL-based development while being able to seamlessly reach into the native world and compete seriously with JVM's performance.</i>
I have blog posts with various benchmarks and optimizations, but ultimately all of my time is being spent actually developing the language right now. The fluidity of the implementation also means that the benchmarks from last year aren't really applicable anymore.<p>Performance measurement and optimization is something I thoroughly enjoy and look forward to being able to focus on once jank hits parity with Clojure and is stable enough to warrant performance as a priority.
I'm especially excited about the error reporting in jank. Fingers crossed they will live up to the blog post showcasing them. Most people I convince to give Clojure a shot tell me that they are utterly confused about its error messages.
How does programming with Clojure targeting multiple platforms (JVM, JS, CLR, LLVM, ...) work?<p>Are there Clojure libraries that don't use JVM(/JS/...)-specific stuff that works on any Clojure platform/dialect? Can such libraries be used on Jank out of the box? Or do library authors have to do something explicit in their libraries to enable their use in specific platforms/dialects?
> Are there Clojure libraries that don't use JVM(/JS/...)-specific stuff that works on any Clojure platform/dialect? Can such libraries be used on Jank out of the box?<p>Correct. Any Clojure code which doesn't use interop will generally work with Clojure, ClojureScript, Clojure CLR, jank, etc. There are some exceptions, where different dialects don't fully implement a Clojure feature, but this is generally the case.<p>> Or do library authors have to do something explicit in their libraries to enable their use in specific platforms/dialects?<p>Clojure also supports reader macros to enable forms for specific dialects. This is basically like an #ifdef in the C world, where library devs can check if the code is currently being compiled for Clojure, ClojureScript, jank, and so on. This allows you to have a public function, for example, which internally just uses a reader conditional to do the correct thing. For example:<p><pre><code> (defn sleep [ms]
#?(:clj (Thread/sleep ms)
:jank (let [s (/ ms 1000)
ns (* (mod ms 1000) 1000000)
t (cpp/timespec. (cpp/long. s) (cpp/long. ns))]
(cpp/nanosleep (cpp/& t) cpp/nullptr))))
</code></pre>
That's using the currently working C and C++ interop to call the POSIX C function. The same could be done for the C++ version. This function can now be used in both Clojure and jank with no difference to the consumer.
I feel like I’ve been coding jank already for most of my life.
Aside from the lack of JVM, what's holding back Jank from being a drop in Clojure replacement?
Great work! Also, the error messages are neat!
Good luck, jeaye.