I don't have anything terribly insightful to say other than that I really like this project. I loved using Clojure back during it's brief time in the sun, it was a great time, and jank has all the same awesome vibes. I haven't used it on anything serious yet, it seems like it would be great for like a `zig`-flavored approach to C++ builds for example. I'm doing a big C++ project ground up at the moment, I think I'm going to get jank into it and see if I can automate some stuff.

The compilation strategy is very much what Carmack did in Trinity and whether you got your inspiration there or independently had a great idea, that's good company to be keeping.

Keep it up!

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.

Why call it jank? It is a negative associated word in most contexts that’s why I’m curious about it

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.

Shouldn't it be an 'if' instead of 'when' in the first example?

I'm very excited about jank, and it's on my backlog.

> Don't try to provide backwards compatible subset of JVM APIs.

Yeah, jank doesn't much with JVM APIs or the JVM at all. We have our own implementation of the compiler and runtime. It has similarities to Clojure's design, only because the object model somewhat demands that.

> Don't implement your own GC, just use mmtk [1].

Yep, already the plan. Currently using Boehm, but MMTK is the next upgrade.

> Don't underestimate complexity and importance of multi-threading and concurrency.

Clojure aids this in having STM, immutable data structures, etc. However, there are some key synchronization points and I do need to audit all of them. jank doesn't have multi-threading support yet, but we will _not_ go the way of Python. jank is Clojure and Clojurists expect sane multi-threading.

> Don't spend too much time benchmarking and optimizing single threaded performance against JVM as performance baseline.

This year, not much optimization has been done at all. I did some necessary benchmarking early on, to aid in some design decisions, but I follow this mantra:

1. Make it work

2. Make it correct

3. Make it fast

I'm currently on step 2 for most of jank. Thanks for sharing the advice!

> Might I ask the author of Jank whether he knows about Clapp and if so, how will this project try to avoid getting stagnated?

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.

> If I recall correctly, compiling Clapp takes a full day, that gives not a good vibe.

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.

> In that post and comments we read that Clapp was 100x slower that sbcl

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.

> 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.

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.

https://github.com/clasp-developers/clasp

You're in luck ;)

https://jank-lang.org/blog/2025-04-01-jank-has-been-renamed/

I love the name Jank. I would use it just for the name alone.

What's the demonym for Jank devs? Janker?

What's the objection to the name? I don't get it.

I worked for a while in a big traditional corporation. My team was a bit like a little enclave inside the larger organisation. They knew us because we had our top shirt buttons undone and wore brown shoes instead of black. When we interacted with the traditional suits the worst we got were chuckles and eye rolls as we said names like "Python", "GIMP" and "Cockroach" instead of the things they knew about like SAS and Oracle. We never met any resistance due to naming or anything like that. But I still ended up leaving before too long because it was too difficult and slow to make real change and progress.

So if you work for somewhere even worse than that, just leave!

I blame the jvm for this. Happy to see an implementation on llvm.

> 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))))

> How does programming with Clojure targeting multiple platforms (JVM, JS, CLR, LLVM, ...) work?

Each variant has its own file extension, e.g. .clj for JVM and .cljs for JS.

In case you're writing code that needs to work on multiple platforms, you put it in a .cljc file. Any of the code in these files that still needs to be different due to the platform choice is differentiated inline using a reader macro, which results in the different platform compilers getting a (slightly) different abstract syntax tree, so it is not too dissimilar from writing cross-platform code in other languages (just more convenient due to the Lisp style).

Yeah it’s pretty incredible how unhelpful the error messages are. A true feat. Still love clojure but wow

jank will lean heavily into leiningen, though it will have deps.edn support. I think that the process of doing this is much simpler than whatever Clojure CLI devs are doing these days:

    lein new jank hello-world
    cd hello-world
    lein run
    lein test
    lein package

Welcome home.

Clojure is still going and, in terms of dialects, still growing. According to the 2024 Stack Overflow survey, Clojure is the third highest paying job by language. https://survey.stackoverflow.co/2024/technology#top-paying-t...

had a bunch of projects (long lived infra projects) until a few years ago and nowadays i mainly use it for scripting (with babashka). changed job to a startup a few weeks ago, so some more clojure getting in there!

plenty of jobs don't mandate languages on everything.

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.

> There exists a much smaller subset of jank that is capable of compiling itself.

If your fitness test is compiler SLOC, there does indeed exist better designs. However, each of those will sacrifice performance and robustness in favor of that simplicity and concision.

I don't want to implement jank in jank. I don't think jank will ever be self-hosting. Why? Multiple reasons.

Firstly, jank isn't a systems language and in order to perform the tricks necessary for a fast runtime, I need a systems language like C++. I want jank to be the fastest Clojure around and that will require more than just a 5000 line small self-hosted compiler.

Secondly, jank has two audiences. The first audience is existing Clojure devs. A self-hosted jank would work well for them. However, the second, larger, audience is existing native devs. For them, jank needs to have an idiomatic native interface in order to embed it into their programs. The Clojure side of jank is not designed to create C++ APIs; it's designed to consume them. However, the C++ side of jank _is_ a C++ API and is designed to be a library.

Thirdly, jank's seamless interop is unprecedented for a lisp. This requires the bleeding edge (literally unreleased LLVM main, as of writing) of Clang and LLVM in order to be possible. This is necessary both for full JIT capabilities as well as the ability to seamlessly reach into C++ to use any value, function, or type, from jank, even when that requires JIT template instantiation. The typical small compiler approach of compiling to C and using TCC will not allow me to achieve this. Again, different fitness test.

> The current approach is likely going to just bog the author down, dealing with accidental complexity from c++ and llvm especially.

It sounds to me like you're designing another language, not jank. With all of this said, of course jank's design and code could be improved. I'd be able to point out more issues in jank's code than anyone, I'd wager, since I've introduced most of them. But the bulk of your point, of having less C++ and more jank, would lead to a smaller, slower, and less robust language. I will pay the cost of C++ in order to build the language I want.

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.

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.

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. https://rhombus-lang.org/

Are you sure you want that? It's possible to use whitespace and conventions to denote s-expr. For example, have each line implicitly start with a ( and use \n for ). More complicated schemes involving counting indentation also available. Anything you like that parses to a tree really.

The price will tend to be that working out what the code parses to gets much more difficult for the programmer. The parser won't care. Guessing what the programmer might have meant for error messages gets harder. Copying code around in a file will tend to change the meaning.

Worth noting that dear python, whitespace enthusiast, still has spurious : scattered around to give slightly better behaviour on syntactically invalid input, and they managed to compromise the semantics of lambda to keep the whitespace magic working.

An alternative you might like is colouring parens light grey (or dark, whatever mostly matches the editor background) and have the editor insert them for you.

This exists. https://yamlscript.org/blog/2025-06-24/how-does-ys-work/

https://yamlscript.org/about/ - YAMLScript (or YS) A graal pre-compiled Clojure environment, like Babashka, but uses a different, looser syntax (yaml based). Can run from command line.

Like a nicer Python?

This comes up all the time. I used to dismiss lisps and schemes as well because of parens until I've messed with Racket. My advice to you is to stop worrying and embrace parens. The REPL helps.

jank has a GC, just like Clojure. jank is Clojure.

The seamless C++ interop allows for stack-allocated C++ objects, as well as manual memory management, but the default is that everything is tracked by the GC.