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.
benreesman
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!
Jeaye
I hadn't heard of Carmack doing something similar, but I will take that company any day. Thanks for the kind words!
dzonga
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.
Jeaye
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. :)
thethimble
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?
Rich has many great ideas and he founded Clojure. I respect him deeply. On typing, however, we do not agree entirely.
For a practical example of a Clojure-like language with a completely static type system (with affine typing), see Carp. https://github.com/carp-lang/Carp
I don't see why there can't be a Carp mode in jank, with bridges in place to connect the Clojurey world from the Carpy world. This would allow jank users to develop interactively to start with, figure out their shapes, use the REPL, etc. Then, if they want, they can lock down some parts of the code for both performance and correctness gains.
narnarpapadaddy
FWIW, (I have one Clojure project I inherited at work that my team maintains) I love this direction.
KingMob
Heh. Hickey once debated with me at length about visual neuroscience, a subject I have a master's degree in and he doesn't. At no point did this stop him from confidently asserting things.
I have to wonder if "Maybe Not" is similar, since he's not actually an expert in types, either afaik.
Been a while since I've watched/read it, but I remember the ideas in Maybe Not being quite interesting.
To me, the really important idea wasn't a criticism of static types in general.
Instead it was the idea that static typing in most (all?) mainstream implementations conflates concepts that should be separate, specifically the shape of the information that we have (e.g. what fields of what types), and whether a particular bit of information is available and required (e.g. nullability).
He contends that the former belongs in our usual "type definition", whereas the latter relates instead to a given context. For example, my PassportForm type always has a date-of-birth field in its _shape_, but whether it's statically required/present to exist depends on whether we're at a HTTP API boundary, an internal domain function boundary, writing into a database.
It sounded like that kind of "nullability masking" was intended as a feature of Spec, but I don't get the impression it was ever implemented.
didibus
I think they were ideas being experimented for Spec2, but I think that's a bit on a hiatus.
drob518
I don’t think Rich was criticizing static types as much as saying that they aren’t giving you as much benefit as you think they are and that they complicate program evolution over time.
If you need confidence in the operation of a function you make code testable. If you need it to execute in Repl you need to make code Replable and I am not joking.
nathell
If you can run it, then you can REPL it, no matter how deeply nested. Scope-capture (https://github.com/vvvvalvalval/scope-capture) has been probably the most important tool in my box. Hope jank supports it eventually.
Thanks for jank! It’s great to be reading about it, listening to you talking about it at conferences, and I can’t wait to try it out!
fithisux
Core spec is enough. Types do not tell the truth. Contracts do the data type casting and data testing. A ubiquitous combo in data engineering.
barrell
> pattern matching, value-based errors
I did not know these were in the cards, that makes jank even more exciting!
barrell
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)
NeutralForest
> 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.
d4mi3n
In my (limited) experience with Clojure and other functional languages, this is usually true under situations where:
1. You’re mapping or reducing some dataset
2. Your iteration logic does not branch a lot
3. You can express your transformation logic using higher order functions (e.g. mapping a reduction operation across a multidimensional array)
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.
barrell
Maybe hyperbole on the frequency, but not the condensation. I meant more along the lines of “most of the complicated code I write in Clojure is an order of magnitude more dense.” _Most_ of the code I write would be 1:1 or 1:2 with other languages, it I don’t think it’s the type of code OP was referring to.
The 1:20+ is definitely not hyperbole though. Using transducers to stream lazy reductions of nested sequences; using case, cond-> and condp->; anywhere where you can lean on the clojure.core library. I don’t know how to give specific examples without giving a whole blog post of context, but 4 or 5 examples from the past year spring to mind.
It’s also often the case that optimizing my clojure code results in a significant reduction of lines of code, whereas optimizing Python code always resulted in an explosion of LoC
Personally I find Python particularly egregious. No map/filter/reduce, black formatting, no safe nested property access. File length was genuinely one of the reasons I stopped using it. The ratio would not be so high with some languages, ie JavaScript
Even with Elixir though, many solutions require 5-10 times the amount of lines for the same thing thing in Clojure. I just converted two functions yesterday that were 6 & 12 lines respectively in Clojure, and they are both 2 pages in Elixir (and would have been much longer in Python)
That's great, and I agree, but nobody really cares is the problem. They don't care about brevity and LISP is a really hard sell outside of those who "get it."
beders
You need a REPL to truly read Clojure code.
Could be a weakness or could be a strength. In my day to day work I consider a strength since I’m working at the REPL the whole day anyways
lisbbb
It's not difficult to read once you get writing it. My problem was getting other developers on board with it, which, ultimately, I failed at.
no_wizard
Why call it jank? It is a negative associated word in most contexts that’s why I’m curious about it
amelius
I guess it stands out. "Git" is similar. "Rust" isn't a very positive word either. Perhaps it's a new trend. Maybe the answer is "all the good names have been taken" and/or they are simply lazy.
graemep
Neither is as negative. This sort of name is more like Gimp.
It is definitely a lot less negative than Nimrod (which is actually positive in origin - but Americans do not get biblical references) which changed its name.
You can also get away with a lot more if you are Linux Torvalds or Mozilla.
Quarrelsome
all code is somewhat jank though.
While jank is technically a negative term, its quite playful as opposed to scathing. My favourite usage was in MTG where large control decks that just slap together strong cards are referred to as "jank piles".
barrenko
I view "jank" similarly to "cracked", not necessarily negative.
bgro
Yep I won’t use anything with a negative self deprecating name like this. Because some tech bro will use it as a a basis to disqualify my entire resume or sabotage an interview after solving the leetcode trivia troll questions and whatever other video game battles they add to the interview process in the future.
Project manager fires the entire team except 1 intern to finish the project with 1000 points of stories in 1 sprint? Heh or did you just figure out jank wasn’t capable of doing the job what did you expect?
Hotfix to fix a bug with the stage environment because the SREs set it up wrong? No bro it’s jank it’s that jank thing. Source: ctrl F “jank” in the message analytics and copilot says all matches are in the stage environment and that jank is also a tech thing. It also bright up every engineers profile that lists jank as a skill. Time to pick a scape goat.
athorax
Is tech bro in the room with us right now?
binary132
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.
Jeaye
> 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.
neutronicus
I commented to this effect on Reddit, but my interest is entirely conditional on ability to embed Jank into a pre-existing C++ application as a shared library.
Ideally without controlling the code of the main application (e.g. to implement a plug-in).
Jeaye
Yep, this will be an important use case and will be officially supported. For the first alpha release this year, I'm focusing on Clojure devs, but support for existing native devs will come once things stabilize.
twism
Shouldn't it be an 'if' instead of 'when' in the first example?
Jeaye
Yes it should. Thanks for the keen eye and taking the time to point that out.
zamalek
I'm very excited about jank, and it's on my backlog.
densh
Hey, as someone who spent a few years reimplementing another language trying to decouple it from JVM (Scala JVM -> Scala Native), some pitfalls to avoid:
- Don't try to provide backwards compatible subset of JVM APIs. While this might seem tempting to support very important library X with just a bit of work, I'd rather see new APIs that are only possible with your language / runtime. Otherwise you might end up stuck in never-ending stream of requests to add one more JVM feature to get yet another library from the original JVM language running. Focus on providing your own unique APIs or bindings to native projects that might not be easy to do elsewhere.
- Don't implement your own GC, just use mmtk [1]. It takes a really long time to implement something competitive, and mmtk already has an extensible and pluggable GC design that gets some of the best performance available today [2] without much effort on your end.
- Don't underestimate complexity and importance of multi-threading and concurrency. Try to think of supporting some form of it early or you might get stuck single threaded world forever (see CPython). Maybe you don't do shared memory multi threading and then it could be quite easy to implement (as in erlang). No shared memory also means no shared heap, which makes GCs's life much easier.
- Don't spend too much time benchmarking and optimizing single threaded performance against JVM as performance baseline. If you don't have a compelling use case (usually due to unique libraries), the performance might not matter enough for users to migrate to your language. When you do optimize, I'd rather see fast startup, interactive environment (think V8), over slow startup but eventually efficient after super long warmup (like jvm).
I see that jank is already doing at least some of the things right based on the docs, so this message might be more of a dump of mistakes I've done previously in this space.
> 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!
densh
Very cool project and I think you are doing it right. Best of luck with getting it off the ground!
catfacts
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.
Jeaye
> 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!
Jtsummers
Clasp, not Clapp, and it's still getting releases. 2.7.0 was released in January, and 2.8.0 is pending.
The "one letter danger" section is hilarious, but did you try to find any examples with a one-vowel difference?
bee_rider
Grody
fud101
I love the name Jank. I would use it just for the name alone.
onionisafruit
What's the demonym for Jank devs? Janker?
Jeaye
Still deciding. Maybe jankster.
DetroitThrow
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.
onionisafruit
I suppose jank-yanker is off the table.
ForgotMyUUID
The cute form would be Jankiye
eduction
Yes but pronounced in the Nordic and Central European fashion (“yanker”)
dxdm
Jankee seems like a perfectly janky demonym.
magicalhippo
Jankobian?
gkhartman
Jankbroni
AnimalMuppet
When there's a book, whoever does the illustrations should be a jankee doodle.
... Right, I'll show myself out.
saghm
It can get adapted to a Broadway musical and named Damn Jankees
Kind of like the name "Slack", which also keeps its product from being uses in enterprise settings? /s
mgdev
My company had what was at the time one of the largest Slack enterprise contracts. You have no idea what internal corporate battles we had to face to get our higher-ups to take us seriously at every stage of adoption, and ultimately roll it out en masse. Slack succeeded in enterprise in spite of its name, not because of it. The actual product was phenomenal, relative to alternatives.
Cthulhu_
or "Git", which is a straight insult.
mgdev
Yes, when you have the notoriety, distribution, and reputation-for-insults that Linus does, you can get away with things like that, because you're selling into a culture that already understands the "joke".
an_aparallel
Janky - slang for something shit, crsp, cobbled together haphazardly...?
globular-toast
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!
mgdev
I know a little about getting large companies to use unknown and "risky" tech. I've done it a number of times (including one I'm especially proud[0] of, and that is relevant given the Clojure connection), and built more than one billion-dollar product doing so.
Names have incredible power, positive or negative, when something is in its infancy.
At the start, when it's just you, and maybe one other person, and maybe one more than that... and your entire effort is just a wisp of what it could one day be, all it takes is some random fly-by-night architect (or even project manager) walking by, hearing the name, and saying, "No way am I letting something called jank touch this project," and shutting it down. The ol' swoop-and-poop, but for incredibly understandable reasons: corporate drones are superstitious.
Now... if, as a matter of culture building, you're intentionally leaning into the "jank" name, that's different. Because names have incredible power. So if you're cobbling together a cadre of crack hackers, "jank" might be exactly what you need to telegraph exactly the ethos you want to manifest.
But if you're just looking for a memorable name to slap on something you hope will actually get traction in any production capacity, I'd just ask that Jeaye consider if the potential benefits outweigh the risks.
What you're describing is absolutely true, and I've seen it, but I agree with the commenter that it's a good litmus test for shit organizations. I have learned that it doesn't matter if the name is changed to something better, I will still be working for people that think with their ass, and therefore, half my life will be annoying.
Rust also has negative connotations, arguably worse connotations. Seems to do fine, and I wouldn't want it renamed because a PM is on a power trip.
> but for incredibly understandable reasons: corporate drones are superstitious
Understandable in the sense that I get why a child would do this, not an adult who is supposed to know what they're managing. Unfortunately, the business world pretends "Project Manager" can be slotted into any domain. Now my days are spent correcting the AI notetaker of a guy who is paid 6 figures.
mgdev
You are right, it is a good litmus test.
I suppose it depends on which battle you’re choosing to fight.
When I enter such orgs, I join to fix the org. And I want every tool at my disposal to do it.
I love turnarounds. But they require careful management of energy. So if I have an opportunity to convince someone to change a name now, it saves me a bunch of energy later.
FWIW, I learned this while getting both React and Clojure approved for internal use at a Fortune 100 co. Took me weeks. Both had problematic licensing issues, both of which could have been avoided if the authors had spent 10 extra minutes clarifying a few small things a few years before.
lewdwig
I love Clojure, I really do, but it feels to me like what I once thought was its unstoppable march ground to a halt and then it kinda fell out of the nerd consciousness. I’m hopeful jank might be the shot in at arm Clojure needs to get going again.
JonChesterfield
I blame the jvm for this. Happy to see an implementation on llvm.
latexr
Anecdotally, the JVM is exactly why I never gave Clojure a shot, despite being otherwise immensely interested.
I remember reading about Jank a while back on HN and got excited for it. Though I wonder if it’ll be too late to recapture my interest by the time it’s ready. Hopefully not.
3036e4
There is also Janet. Not quite Clojure, but heavily inspired and a nice language. And it has a pretty small, mostly ANSI C implementation, easy and fast to compile anywhere I tried, and can be embedded in applications with no LLVM dependency.
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?
Jeaye
> 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.
simongray
> 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).
Lyngbakr
What is jank's tooling like? Clojure's felt very much like an afterthought, unfortunately. I do like having a decent set of tools right out of the box. I think Gleam was smart in this respect.
Jeaye
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
Going forward, we'll see about a leaner version of lein. Maybe we can fork lein and compile it in jank or maybe we'll need to make our own. For now, default lein will be the recommendation.
defo10
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.
chamomeal
Yeah it’s pretty incredible how unhelpful the error messages are. A true feat. Still love clojure but wow
padjo
Was a little surprised to discover this was a real language and not an esoteric or joke language.
lisbbb
I was a Clojure fan back around 2011. I'm just curious how you make a living with these esoteric languages? I was able to build exactly two back-end services using Clojure as a PoC back then, which was 14 years ago, and then the whole Clojure thing basically died. I'm shocked to see any resurgence of it or LISP in 2025.
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.
jankjankjank
I feel like I’ve been coding jank already for most of my life.
Jeaye
Welcome home.
npalli
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.
Jeaye
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.
norir
Having scanned the source, I believe there is a better design for this language.
There exists a much smaller subset of jank that is capable of compiling itself. I am quite sure that you could write a bootstrap compiler in clojure (but restricted to the same subset) that translates to clojure (or some other language you prefer targeting). My guess, from experience writing small compilers, is it should be doable in ~5000 lines or even less.
Once you had that, you could then write a backend that translates to c. This gives you a native compiler for this small subset of jank. Applied to its own source code, you get a native compiler binary for free and cut the cord from clojure.
Now you have a native compiler and a very small, tight language. Because it is so small, it is easy both to check correctness and optimize. You can add new backends relatively easily. For the repl, you can compile functions into their own hash-addressed shared libraries using a c compiler and dlopen them. TCC is very fast for this purpose even if the generated code isn't quite as good as optimized gcc or clang.
All of the future vision could be implemented on top of this foundation. The current approach is likely going to just bog the author down, dealing with accidental complexity from c++ and llvm especially. It is also better to have fewer features implemented completely and correctly than more features incompletely or incorrectly implemented.
Jeaye
> 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.
axblount
Aside from the lack of JVM, what's holding back Jank from being a drop in Clojure replacement?
Jeaye
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.
caim
Great work! Also, the error messages are neat!
rtpg
I am once again calling for someone to make something that's "basically clojure" but with whitespace instead of parens.
Parens don't matter, but giving values names causing indentation is something I simply cannot abide as a terminal intermediary value name giving person.
EDIT: oh and also something with "proper" multiline comments. Thanks!
Jeaye
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/
rtpg
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)
The link to Rhombus is very interested, I hadn't heard of this and it looks very well developed. Will mess around with it.
JonChesterfield
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.
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?
rtpg
I do not believe I want to write my code in something that goes through a YAML parser.
petre
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.
rtpg
As an emacs user I'm often writing small snippets of elisp for my own needs, and for snippets it's fine. But I dislike what most lisp's scoping strategies do to "normal" indentation of code. Any function with even a single intermediate value, indented due to a `let`! It's noticably more symbols compared to my Python stuff.
On top of that, being unable to just slap in big docstrings in my code makes me sad. Docstrings are useful.
This isn't the end of the world, but it's something that bugs me.
jcmontx
how does memory management work? malloc and such?
Jeaye
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.
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.
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!
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.
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. :)
https://youtu.be/YR5WdGrpoug?si=4mI8doBX6jj6PJkk
For a practical example of a Clojure-like language with a completely static type system (with affine typing), see Carp. https://github.com/carp-lang/Carp
I don't see why there can't be a Carp mode in jank, with bridges in place to connect the Clojurey world from the Carpy world. This would allow jank users to develop interactively to start with, figure out their shapes, use the REPL, etc. Then, if they want, they can lock down some parts of the code for both performance and correctness gains.
I have to wonder if "Maybe Not" is similar, since he's not actually an expert in types, either afaik.
Alexis King wrote a partial rebuttal to Maybe Not: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...
To me, the really important idea wasn't a criticism of static types in general.
Instead it was the idea that static typing in most (all?) mainstream implementations conflates concepts that should be separate, specifically the shape of the information that we have (e.g. what fields of what types), and whether a particular bit of information is available and required (e.g. nullability).
He contends that the former belongs in our usual "type definition", whereas the latter relates instead to a given context. For example, my PassportForm type always has a date-of-birth field in its _shape_, but whether it's statically required/present to exist depends on whether we're at a HTTP API boundary, an internal domain function boundary, writing into a database.
It sounded like that kind of "nullability masking" was intended as a feature of Spec, but I don't get the impression it was ever implemented.
Thanks for jank! It’s great to be reading about it, listening to you talking about it at conferences, and I can’t wait to try it out!
I did not know these were in the cards, that makes jank even more exciting!
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 curious if you have any example of this? Even if it's an hyperbole, I don't really see how.
1. You’re mapping or reducing some dataset
2. Your iteration logic does not branch a lot
3. You can express your transformation logic using higher order functions (e.g. mapping a reduction operation across a multidimensional array)
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.
The 1:20+ is definitely not hyperbole though. Using transducers to stream lazy reductions of nested sequences; using case, cond-> and condp->; anywhere where you can lean on the clojure.core library. I don’t know how to give specific examples without giving a whole blog post of context, but 4 or 5 examples from the past year spring to mind.
It’s also often the case that optimizing my clojure code results in a significant reduction of lines of code, whereas optimizing Python code always resulted in an explosion of LoC
Personally I find Python particularly egregious. No map/filter/reduce, black formatting, no safe nested property access. File length was genuinely one of the reasons I stopped using it. The ratio would not be so high with some languages, ie JavaScript
Even with Elixir though, many solutions require 5-10 times the amount of lines for the same thing thing in Clojure. I just converted two functions yesterday that were 6 & 12 lines respectively in Clojure, and they are both 2 pages in Elixir (and would have been much longer in Python)
It is definitely a lot less negative than Nimrod (which is actually positive in origin - but Americans do not get biblical references) which changed its name.
You can also get away with a lot more if you are Linux Torvalds or Mozilla.
While jank is technically a negative term, its quite playful as opposed to scathing. My favourite usage was in MTG where large control decks that just slap together strong cards are referred to as "jank piles".
Project manager fires the entire team except 1 intern to finish the project with 1000 points of stories in 1 sprint? Heh or did you just figure out jank wasn’t capable of doing the job what did you expect?
Hotfix to fix a bug with the stage environment because the SREs set it up wrong? No bro it’s jank it’s that jank thing. Source: ctrl F “jank” in the message analytics and copilot says all matches are in the stage environment and that jank is also a tech thing. It also bright up every engineers profile that lists jank as a skill. Time to pick a scape goat.
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.
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.
Ideally without controlling the code of the main application (e.g. to implement a plug-in).
- Don't try to provide backwards compatible subset of JVM APIs. While this might seem tempting to support very important library X with just a bit of work, I'd rather see new APIs that are only possible with your language / runtime. Otherwise you might end up stuck in never-ending stream of requests to add one more JVM feature to get yet another library from the original JVM language running. Focus on providing your own unique APIs or bindings to native projects that might not be easy to do elsewhere.
- Don't implement your own GC, just use mmtk [1]. It takes a really long time to implement something competitive, and mmtk already has an extensible and pluggable GC design that gets some of the best performance available today [2] without much effort on your end.
- Don't underestimate complexity and importance of multi-threading and concurrency. Try to think of supporting some form of it early or you might get stuck single threaded world forever (see CPython). Maybe you don't do shared memory multi threading and then it could be quite easy to implement (as in erlang). No shared memory also means no shared heap, which makes GCs's life much easier.
- Don't spend too much time benchmarking and optimizing single threaded performance against JVM as performance baseline. If you don't have a compelling use case (usually due to unique libraries), the performance might not matter enough for users to migrate to your language. When you do optimize, I'd rather see fast startup, interactive environment (think V8), over slow startup but eventually efficient after super long warmup (like jvm).
I see that jank is already doing at least some of the things right based on the docs, so this message might be more of a dump of mistakes I've done previously in this space.
[1]: https://github.com/mmtk/mmtk-core
[2]: https://dl.acm.org/doi/pdf/10.1145/3519939.3523440
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!
Edited: Here is a post in HN from 2014 about Clapp. https://www.hackerneue.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.
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!
https://github.com/clasp-developers/clasp
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.
https://jank-lang.org/blog/2025-04-01-jank-has-been-renamed/
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.
... Right, I'll show myself out.
/s
https://fluentslang.com/jank-meaning/
So if you work for somewhere even worse than that, just leave!
Names have incredible power, positive or negative, when something is in its infancy.
At the start, when it's just you, and maybe one other person, and maybe one more than that... and your entire effort is just a wisp of what it could one day be, all it takes is some random fly-by-night architect (or even project manager) walking by, hearing the name, and saying, "No way am I letting something called jank touch this project," and shutting it down. The ol' swoop-and-poop, but for incredibly understandable reasons: corporate drones are superstitious.
Now... if, as a matter of culture building, you're intentionally leaning into the "jank" name, that's different. Because names have incredible power. So if you're cobbling together a cadre of crack hackers, "jank" might be exactly what you need to telegraph exactly the ethos you want to manifest.
But if you're just looking for a memorable name to slap on something you hope will actually get traction in any production capacity, I'd just ask that Jeaye consider if the potential benefits outweigh the risks.
[0]: https://www.linkedin.com/pulse/building-cloud-choosing-lisp-...
Rust also has negative connotations, arguably worse connotations. Seems to do fine, and I wouldn't want it renamed because a PM is on a power trip.
> but for incredibly understandable reasons: corporate drones are superstitious
Understandable in the sense that I get why a child would do this, not an adult who is supposed to know what they're managing. Unfortunately, the business world pretends "Project Manager" can be slotted into any domain. Now my days are spent correcting the AI notetaker of a guy who is paid 6 figures.
I suppose it depends on which battle you’re choosing to fight.
When I enter such orgs, I join to fix the org. And I want every tool at my disposal to do it.
I love turnarounds. But they require careful management of energy. So if I have an opportunity to convince someone to change a name now, it saves me a bunch of energy later.
FWIW, I learned this while getting both React and Clojure approved for internal use at a Fortune 100 co. Took me weeks. Both had problematic licensing issues, both of which could have been avoided if the authors had spent 10 extra minutes clarifying a few small things a few years before.
I remember reading about Jank a while back on HN and got excited for it. Though I wonder if it’ll be too late to recapture my interest by the time it’s ready. Hopefully not.
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?
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.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).
plenty of jobs don't mandate languages on everything.
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.
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. I am quite sure that you could write a bootstrap compiler in clojure (but restricted to the same subset) that translates to clojure (or some other language you prefer targeting). My guess, from experience writing small compilers, is it should be doable in ~5000 lines or even less.
Once you had that, you could then write a backend that translates to c. This gives you a native compiler for this small subset of jank. Applied to its own source code, you get a native compiler binary for free and cut the cord from clojure.
Now you have a native compiler and a very small, tight language. Because it is so small, it is easy both to check correctness and optimize. You can add new backends relatively easily. For the repl, you can compile functions into their own hash-addressed shared libraries using a c compiler and dlopen them. TCC is very fast for this purpose even if the generated code isn't quite as good as optimized gcc or clang.
All of the future vision could be implemented on top of this foundation. The current approach is likely going to just bog the author down, dealing with accidental complexity from c++ and llvm especially. It is also better to have fewer features implemented completely and correctly than more features incompletely or incorrectly implemented.
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.
Parens don't matter, but giving values names causing indentation is something I simply cannot abide as a terminal intermediary value name giving person.
EDIT: oh and also something with "proper" multiline comments. Thanks!
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/
The link to Rhombus is very interested, I hadn't heard of this and it looks very well developed. Will mess around with it.
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.
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?
On top of that, being unable to just slap in big docstrings in my code makes me sad. Docstrings are useful.
This isn't the end of the world, but it's something that bugs me.
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.