Hey folks. I'm the creator of jank. I didn't expect to be on HN today, but I appreciate the interest.
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.
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.
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.
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. :)
What’s your take on Hickey’s talk titled “Maybe Not” which fundamentally criticizes static types? Is there a middle ground where some form of static typing makes sense in a Clojure-esque world?
My comment to code ratio is magnitudes higher in Clojure than in other languages, which helps a lot with this.
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
Plus structural editing and the repl really help with the “reading” experience (reading in quotes because it’s much more interactive than reading)
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.
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.
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).
> 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.
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.
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.
Anyways, keep up the amazing work, I wish I could have seen your janky talk at Strangeloop on another timeline.
How does programming with Clojure targeting multiple platforms (JVM, JS, CLR, LLVM, ...) work?
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?
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.
> Or do library authors have to do something explicit in their libraries to enable their use in specific platforms/dialects?
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:
(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))))
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 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?
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".
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.
If I recall correctly, compiling Clapp takes a full day, that gives not a good vibe.
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!
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.
Also perhaps ECL, a lisp in C, can gives us some hints about how to get better performance and compilation speed.
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.
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.
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 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.
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.
Once all of the necessary features are implemented, the only thing in the way will be JVM interop. If you have any "pure Clojure" code (i.e. no interop), it should also be valid jank code.
Hey folks. I'm the creator of jank. I didn't expect to be on HN today, but I appreciate the interest.
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.
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.
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.
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. :)
What’s your take on Hickey’s talk titled “Maybe Not” which fundamentally criticizes static types? Is there a middle ground where some form of static typing makes sense in a Clojure-esque world?
https://youtu.be/YR5WdGrpoug?si=4mI8doBX6jj6PJkk
My comment to code ratio is magnitudes higher in Clojure than in other languages, which helps a lot with this.
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
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.
I'm curious if you have any example of this? Even if it's an hyperbole, I don't really see how.
Shouldn't it be an 'if' instead of 'when' in the first example?
Yes it should. Thanks for the keen eye and taking the time to point that out.
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.
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.
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).
> 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.
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.
I love this project. I've been a sponsor on GitHub since late last year.
But for the love of... please pick a different name.
Whatever reasons companies/teams will have for not letting someone use Jank at work, don't let the name be one of them.
What's the objection to the name? I don't get it.
You're in luck ;)
https://jank-lang.org/blog/2025-04-01-jank-has-been-renamed/
What's the demonym for Jank devs? Janker?
Still deciding. Maybe jankster.
I suppose jank-yanker is off the table.
Jankobite? Ehhh
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.
Anyways, keep up the amazing work, I wish I could have seen your janky talk at Strangeloop on another timeline.
The cute form would be Jankiye
How does programming with Clojure targeting multiple platforms (JVM, JS, CLR, LLVM, ...) work?
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?
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.
> Or do library authors have to do something explicit in their libraries to enable their use in specific platforms/dialects?
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:
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 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?
Edited: Here is a post in HN from 2014 about Clapp. https://news.ycombinator.com/item?id=8367404
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".
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.
If I recall correctly, compiling Clapp takes a full day, that gives not a good vibe.
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!
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.
Also perhaps ECL, a lisp in C, can gives us some hints about how to get better performance and compilation speed.
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.
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.
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 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.
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.
Yeah it’s pretty incredible how unhelpful the error messages are. A true feat. Still love clojure but wow
Great work! Also, the error messages are neat!
Aside from the lack of JVM, what's holding back Jank from being a drop in Clojure replacement?
Once all of the necessary features are implemented, the only thing in the way will be JVM interop. If you have any "pure Clojure" code (i.e. no interop), it should also be valid jank code.