The Jank programming language(jank-lang.org)
jank-lang.org
The Jank programming language
https://jank-lang.org/
136 comments
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!
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!
I hadn't heard of Carmack doing something similar, but I will take that company any day. Thanks for the kind words!
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.
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. :)
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
https://youtu.be/YR5WdGrpoug?si=4mI8doBX6jj6PJkk
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.
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.
FWIW, (I have one Clojure project I inherited at work that my team maintains) I love this direction.
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.
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.
I think they were ideas being experimented for Spec2, but I think that's a bit on a hiatus.
I need to watch this video, but I'd argue that the debate is over on typing. You can make all the theoretical ideas you want, but JS and Python have added typing, it has been received enthusiastically and it has been beneficial. Real world results out rank any philosophical views.
That doesn't mean they're appropriate for all programming languages (it is nice in Python when knocking up a quick and dirty script to not bother with types) but for general purpose languages, types add too much value.
That doesn't mean they're appropriate for all programming languages (it is nice in Python when knocking up a quick and dirty script to not bother with types) but for general purpose languages, types add too much value.
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.
They might not give much execution benefit and they may indeed complicate program evolution, but they DO aid readability, document-ability and refactoring!
I don't think static types (or lack thereof) complicate (or simplify) program evolution over time, bad architecture does.
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.
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.
Alexis King wrote a partial rebuttal to Maybe Not: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ...
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...
Well, at least I know how to form an argument that is not ad hominem. Remind me who you are next time 'KingMob' so I don't waste my time chatting with you again.
I'd personally say typing or not is a style choice, but your criticism here seems to be that Hickey doesn't have a visual neuroscience Master's degree which seems a bit arbitrary.
If your argument is you are an expert but Hickey is not, criticising him on his language design skills seems like a logical mistake. He's one of the foremost language designers of the current era. "Maybe Not" is a speech by an expert talking in his field of expertise.
If your argument is that his confidence is unfounded, again, he's an expert talking in his area. He can reasonably take a confident attitude in that, even if he has unfounded confidence in other fields he isn't an expert in. Lots of experts do that, it is a well founded stereotype of smart people.
He doesn't need to be an expert in implementing types to judge whether they are a good language feature.
If your argument is you are an expert but Hickey is not, criticising him on his language design skills seems like a logical mistake. He's one of the foremost language designers of the current era. "Maybe Not" is a speech by an expert talking in his field of expertise.
If your argument is that his confidence is unfounded, again, he's an expert talking in his area. He can reasonably take a confident attitude in that, even if he has unfounded confidence in other fields he isn't an expert in. Lots of experts do that, it is a well founded stereotype of smart people.
He doesn't need to be an expert in implementing types to judge whether they are a good language feature.
The point of my story that you're missing is that Hickey's confidence in giving a talk shouldn't be confused with knowing what he's talking about.
> "Maybe Not" is a speech by an expert talking in his field of expertise.
Writing a dynamically-typed language does not mean he's an expert in types.
> He doesn't need to be an expert in implementing types to judge whether they are a good language feature.
Hah! Love it.
Asimov: "There is a cult of ignorance in the United States, and there has always been. The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"
> "Maybe Not" is a speech by an expert talking in his field of expertise.
Writing a dynamically-typed language does not mean he's an expert in types.
> He doesn't need to be an expert in implementing types to judge whether they are a good language feature.
Hah! Love it.
Asimov: "There is a cult of ignorance in the United States, and there has always been. The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"
> Writing a dynamically-typed language does not mean he's an expert in types.
That isn't a reasonable criticism here. To take it to the extreme, it wouldn't be accepted that someone has to be an expert in homeopathy before deciding they want to disregard the approach. It is up to experts to proactively demonstrate the worth of their domain - he's a language design expert and he's saying that he doesn't think the people formalising the type system have proven it generally powerful for designing new languages.
He's not claiming to be an expert in types, in "Maybe Not" he's specifically arguing that in programming languages they are an attempt to solve a problem where we should be looking for a stronger approach. And in this case, that approach is open schemas.
That isn't a reasonable criticism here. To take it to the extreme, it wouldn't be accepted that someone has to be an expert in homeopathy before deciding they want to disregard the approach. It is up to experts to proactively demonstrate the worth of their domain - he's a language design expert and he's saying that he doesn't think the people formalising the type system have proven it generally powerful for designing new languages.
He's not claiming to be an expert in types, in "Maybe Not" he's specifically arguing that in programming languages they are an attempt to solve a problem where we should be looking for a stronger approach. And in this case, that approach is open schemas.
Homeopathy can be quickly disproved, because its core tenets violate basic physics. Expertise is not actually needed.
Whereas type systems are complex enough that "a monad is just a monoid in the category of endofunctors, what's the problem?" is a recurring in-joke.
That suggests expertise is warranted.
Whereas type systems are complex enough that "a monad is just a monoid in the category of endofunctors, what's the problem?" is a recurring in-joke.
That suggests expertise is warranted.
> Whereas type systems are complex enough... [t]hat suggests expertise is warranted
Well no hang on. Homeopathy is very complex; quackery typically is. You can't use complexity as a defence here [0].
You justified rejecting homeopathy by saying that it can be dismissed with expertise in an unrelated field; so you have to accept that a non-expert can dismiss a field based on general knowledge in other domains. Which is almost exactly what Rich was doing in Maybe Not; except he is actually a domain expert in the area he was talking from. It was a long talk about how he, with his official world-renowned language designer hat on, is not convinced types can demonstrate the strongest advantage in programming and isn't including them in his language [1].
Now that is a very easy opinion to disagree with and I doubt Rich is even particularly dogmatic about the idea, but it is an expert opinion being delivered by an expert who is supremely qualified in his field.
[0] And, as an aside, I'm not going to pursue it but you're attempting to justify dismissing a medical belief based on knowledge in an unrelated field - physics.
[1] Although, as he is proud to point out, if you want a new language feature in Clojure you can add it in a library - as Ambrose has with Typed Clojure.
Well no hang on. Homeopathy is very complex; quackery typically is. You can't use complexity as a defence here [0].
You justified rejecting homeopathy by saying that it can be dismissed with expertise in an unrelated field; so you have to accept that a non-expert can dismiss a field based on general knowledge in other domains. Which is almost exactly what Rich was doing in Maybe Not; except he is actually a domain expert in the area he was talking from. It was a long talk about how he, with his official world-renowned language designer hat on, is not convinced types can demonstrate the strongest advantage in programming and isn't including them in his language [1].
Now that is a very easy opinion to disagree with and I doubt Rich is even particularly dogmatic about the idea, but it is an expert opinion being delivered by an expert who is supremely qualified in his field.
[0] And, as an aside, I'm not going to pursue it but you're attempting to justify dismissing a medical belief based on knowledge in an unrelated field - physics.
[1] Although, as he is proud to point out, if you want a new language feature in Clojure you can add it in a library - as Ambrose has with Typed Clojure.
> Homeopathy is very complex
But it's not complex at all; a better word is "elaborate". And it doesn't matter how elaborate a system spun from incorrect premises is, if the premises fall, the whole thing does, and homeopathy's premises are easily dismissed.
Very basic tenets of homeopathy involve things like excessive dilution to the point that mere molecules of an active ingredient remain, but which somehow attach "memories" to water molecules to achieve their effects.
Atomic physics points out that this is nonsense. And medical knowledge is under-girded by physics, obviously, so it's not unrelated.
----
We can keep torturing the analogy if you like, but at the end of the day, Hickey's experience is not in static typing. His original background was in C++/Java, which have much simpler type systems, unlike Haskell/ML/Rust/Scala/Swift/etc.
Many people in the static typing world seem to think his criticism is just not that deep or subtle. Unnamed union types exist, existed at the time of Maybe Not, and just represent a different set of tradeoffs than named wrapper ones like Maybe. (Mostly around being explicit.)
It plays well at the conj, but most Clojurians are also inexperienced with modern type systems.
But it's not complex at all; a better word is "elaborate". And it doesn't matter how elaborate a system spun from incorrect premises is, if the premises fall, the whole thing does, and homeopathy's premises are easily dismissed.
Very basic tenets of homeopathy involve things like excessive dilution to the point that mere molecules of an active ingredient remain, but which somehow attach "memories" to water molecules to achieve their effects.
Atomic physics points out that this is nonsense. And medical knowledge is under-girded by physics, obviously, so it's not unrelated.
----
We can keep torturing the analogy if you like, but at the end of the day, Hickey's experience is not in static typing. His original background was in C++/Java, which have much simpler type systems, unlike Haskell/ML/Rust/Scala/Swift/etc.
Many people in the static typing world seem to think his criticism is just not that deep or subtle. Unnamed union types exist, existed at the time of Maybe Not, and just represent a different set of tradeoffs than named wrapper ones like Maybe. (Mostly around being explicit.)
It plays well at the conj, but most Clojurians are also inexperienced with modern type systems.
Being an expert in type theory or language design is not particularly relevant either. The most relevant expert would be the lowly maintenance developer.
This "rebuttal" is a mix of subtle ad hominem attacks and strawman arguments. Not recommended.
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!
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!
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.
> pattern matching, value-based errors
I did not know these were in the cards, that makes jank even more exciting!
I did not know these were in the cards, that makes jank even more exciting!
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)
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.
I'm curious if you have any example of this? Even if it's an hyperbole, I don't really see how.
In my (limited) experience with Clojure and other functional languages, this is usually true under situations where:
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.
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.
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)
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)
I find 95% Clojure has the right tools to write very terse code. But in some cases the functional transducer/piped paradigm can't be contorted to the problem.
Usually these are problems where you need to run along a list and check neighboring elements. You can use amap or map-indexed but it's just not ergonomic or Clojure-y (vs for instance the imperative C++ iterator model)
The best short example I can think of is Fibbonacci
https://4clojure.oxal.org/#/problem/26/solutions
I find all the solutions hard to read. They're all ugly. Their performance characteristics are hard to know at a glance
Usually these are problems where you need to run along a list and check neighboring elements. You can use amap or map-indexed but it's just not ergonomic or Clojure-y (vs for instance the imperative C++ iterator model)
The best short example I can think of is Fibbonacci
https://4clojure.oxal.org/#/problem/26/solutions
I find all the solutions hard to read. They're all ugly. Their performance characteristics are hard to know at a glance
Personally, I would normally reach for loop to check neighboring elements very ergonomically.
EDIT: those Fibonacci functions are insane, even I don’t understand most of them. They’re far from the Clojure I would advocate for, most likely written for funsies with a very specific technical constraint in mind
(loop [[a b c & more] coll] (recur (apply list b c more)))
(partition 3 1 coll)
(->> coll cycle rest (map xform) (map f coll))
EDIT: those Fibonacci functions are insane, even I don’t understand most of them. They’re far from the Clojure I would advocate for, most likely written for funsies with a very specific technical constraint in mind
Yeah, I guess partition to me always looks like a dangerous tool - for instance I have a sequence of numbers and I want to do a 5 point rolling average
You could do `(partition 5 1 coll)` and then average each element in the resulting seq.. It's very easy to reason about. But I'm guessing the performance will be abysmal? You're getting a lazy list and each time you access a 5 neighbor set.. you're rerunning down you coll building the 5 unit subsets? Maybe if you start with an Array type it'll be okay, but you're always coercing to seq and to me it's hard
Taking the first 5 elements, recurring on a list with the top element dropped is probably better, but I find the code hard to read. Maybe it's a familiarity issue..
You could do `(partition 5 1 coll)` and then average each element in the resulting seq.. It's very easy to reason about. But I'm guessing the performance will be abysmal? You're getting a lazy list and each time you access a 5 neighbor set.. you're rerunning down you coll building the 5 unit subsets? Maybe if you start with an Array type it'll be okay, but you're always coercing to seq and to me it's hard
Taking the first 5 elements, recurring on a list with the top element dropped is probably better, but I find the code hard to read. Maybe it's a familiarity issue..
Yeah like I said I reach for loop first and foremost. This is what it would look like with comments if it were actually something complicated (although the comments are quite trivial here):
(loop [coll [1 2 3 4 5 6 7 8 9] memo []]
(if (< (count coll) 5) memo ;; Stop once there are less than 5 items
(->> (take 5 coll) ;; Take the first 5 days
(reduce +) ;; Sum them
(* 0.20) ;; Divide by 5
(conj memo) ;; Append to the end of the memo
(recur (rest coll)) ;; Recur for remaining elements
,,,))))
(loop [[a b c d e :as coll] [1 2 3 4 5 6 7 8 9] memo []]
(if-not e memo
(recur (rest coll) (conj memo (/ (+ a b c d e) 5))))))
(loop [[a b c d e :as coll] [1 2 3 4 5 6 7 8 9] memo []]
(if-not c memo
(recur (rest coll) (conj memo (/ (+ a b c d e)
(cond e 5 d 4 c 3))))))))Thank you for the detailed response! Really thought provoking. It wouldn't occur to me to write code like this. It seems like it'd be harder to parse than an imperative index-based solution, but I'm not sure. Do you find it easy to immediately grok? I'm figuring it's just familiarity
- What's the nested loop in the first solution that you've avoided? The `reduce`? the `count`?
- `conj` feels very Lispy (I mean in contrast to Clojure, not C++) .. Isn't it going to have to run down the list every time to add an item?
My outstanding concerns are what I think are the constant coercion to lists/vectors. You also in effect know the result's size, but your runtime/compiler doesn't know that. So you aren't preallocating `memo` and it feels .. wrong haha
Just curious to hear your thoughts :)
Its probably impossible to keep everything so nicely abstract and composable, but I wish it was smoother to just work with arrays, with random access. The current way of dealing with array is always a bit unwieldy in Clojure. And everything coerced to lists. Working with vectors, with mapv filterv etc is helpful, but they don't have random access so it's not always the solution you want.
- What's the nested loop in the first solution that you've avoided? The `reduce`? the `count`?
- `conj` feels very Lispy (I mean in contrast to Clojure, not C++) .. Isn't it going to have to run down the list every time to add an item?
My outstanding concerns are what I think are the constant coercion to lists/vectors. You also in effect know the result's size, but your runtime/compiler doesn't know that. So you aren't preallocating `memo` and it feels .. wrong haha
Just curious to hear your thoughts :)
Its probably impossible to keep everything so nicely abstract and composable, but I wish it was smoother to just work with arrays, with random access. The current way of dealing with array is always a bit unwieldy in Clojure. And everything coerced to lists. Working with vectors, with mapv filterv etc is helpful, but they don't have random access so it's not always the solution you want.
> It seems like it'd be harder to parse than an imperative index-based solution, but I'm not sure. Do you find it easy to immediately grok?
These examples are incredibly easy to grok. It takes me a lot longer to grok any index based solution ;-) Especially handling nils, missing indices, checking bounds... you quickly get buried in obvious issues that aren't a concern in clojure.
If it's more complicated, I use comments like the first example. I would say that when grokking more complicated loops, you definitely read it slower on a per character basis, but as I've stated elsewhere I don't think you're grokking the functionality any slower.
> What's the nested loop in the first solution that you've avoided? The `reduce`? the `count`?
Correct, reduce is a loop
> `conj` feels very Lispy (I mean in contrast to Clojure, not C++) .. Isn't it going to have to run down the list every time to add an item?
No, vectors are closer to hash-maps than lists. There are two main sequential collections in clojure, lists and vectors. Lists are O(n) to append, vectors are O(1). Lists ore O(1) to prepend, I'm not actually sure the perf characteristics of prepending to a vector.
> My outstanding concerns are what I think are the constant coercion to lists/vectors.
There is only one coercion from a vector to a list in the code (the first time `rest` is called on the input vector). That's if your input was a vector to begin with. Chances are it will be a list. Also, I'm not sure it's even technically coercion in the computer science sense.
> You also in effect know the result's size, but your runtime/compiler doesn't know that. So you aren't preallocating `memo` and it feels .. wrong
This is not a concern in JavaScript (it always preallocates a bunch of memory for every vector IIRC) and I'm not sure the Java implications, but given the performance people get out of clojure I'm sure it's not an issue ;-)
> The current way of dealing with array is always a bit unwieldy in Clojure. And everything coerced to lists. Working with vectors, with mapv filterv etc is helpful, but they don't have random access so it's not always the solution you want.
I can count on one hand the number of times I use nth in my project. To me it's crazy that people build solutions based on random access XD
That being said random access in O(1) on vectors, including those returned from filterv and mapv (technically O(log32n))
These examples are incredibly easy to grok. It takes me a lot longer to grok any index based solution ;-) Especially handling nils, missing indices, checking bounds... you quickly get buried in obvious issues that aren't a concern in clojure.
If it's more complicated, I use comments like the first example. I would say that when grokking more complicated loops, you definitely read it slower on a per character basis, but as I've stated elsewhere I don't think you're grokking the functionality any slower.
> What's the nested loop in the first solution that you've avoided? The `reduce`? the `count`?
Correct, reduce is a loop
> `conj` feels very Lispy (I mean in contrast to Clojure, not C++) .. Isn't it going to have to run down the list every time to add an item?
No, vectors are closer to hash-maps than lists. There are two main sequential collections in clojure, lists and vectors. Lists are O(n) to append, vectors are O(1). Lists ore O(1) to prepend, I'm not actually sure the perf characteristics of prepending to a vector.
> My outstanding concerns are what I think are the constant coercion to lists/vectors.
There is only one coercion from a vector to a list in the code (the first time `rest` is called on the input vector). That's if your input was a vector to begin with. Chances are it will be a list. Also, I'm not sure it's even technically coercion in the computer science sense.
> You also in effect know the result's size, but your runtime/compiler doesn't know that. So you aren't preallocating `memo` and it feels .. wrong
This is not a concern in JavaScript (it always preallocates a bunch of memory for every vector IIRC) and I'm not sure the Java implications, but given the performance people get out of clojure I'm sure it's not an issue ;-)
> The current way of dealing with array is always a bit unwieldy in Clojure. And everything coerced to lists. Working with vectors, with mapv filterv etc is helpful, but they don't have random access so it's not always the solution you want.
I can count on one hand the number of times I use nth in my project. To me it's crazy that people build solutions based on random access XD
That being said random access in O(1) on vectors, including those returned from filterv and mapv (technically O(log32n))
Oh good point on the hashmapiness of vectors, I forgot about that. That would really change the calculus here.... buuuut
> There is only one coercion from a vector to a list in the code (the first time `rest` is called on the input vector)
So actually.. the whole thing is operating on linked lists.. Is that like a "yikes" moment..? No happy clever vectors? It does seem to still work fine in this case, b/c we pop from one list and append to another and the example is simple.. but generally you want the O() guarantees of vectors or arrays
I'm also a bit surprised reduce is going to give you so much overhead, and destructuring doesn't. It really hardcodes the function to a window size which is a shame.. Last I had to optimize a hot loop in Clojure I found all destructuring terrible for perf (but I think it had to do with type boxing)
> I can count on one hand the number of times I use nth in my project.
Random access is sometimes necessary, but like you say hash-like-vectors cover you here okay. I guess arrays are more about having contiguous memory access. It generally gives you much better cache locality and it will typically make a very sizeable performance difference in a hot loop
> There is only one coercion from a vector to a list in the code (the first time `rest` is called on the input vector)
So actually.. the whole thing is operating on linked lists.. Is that like a "yikes" moment..? No happy clever vectors? It does seem to still work fine in this case, b/c we pop from one list and append to another and the example is simple.. but generally you want the O() guarantees of vectors or arrays
I'm also a bit surprised reduce is going to give you so much overhead, and destructuring doesn't. It really hardcodes the function to a window size which is a shame.. Last I had to optimize a hot loop in Clojure I found all destructuring terrible for perf (but I think it had to do with type boxing)
> I can count on one hand the number of times I use nth in my project.
Random access is sometimes necessary, but like you say hash-like-vectors cover you here okay. I guess arrays are more about having contiguous memory access. It generally gives you much better cache locality and it will typically make a very sizeable performance difference in a hot loop
I thought another option would be to use a `partition-all` transducer (and conj'ing a result list that way), but it seems those don't support step sizes. Maybe that internally could be as efficient as running along iterators in an imperative style
https://ask.clojure.org/index.php/2422/transducer-for-partit...
https://ask.clojure.org/index.php/13187/there-currently-opti...
https://clojure.atlassian.net/browse/CLJ-2797
Hopefully gets added to the language some day..
https://ask.clojure.org/index.php/2422/transducer-for-partit...
https://ask.clojure.org/index.php/13187/there-currently-opti...
https://clojure.atlassian.net/browse/CLJ-2797
Hopefully gets added to the language some day..
Exactly. I would use loop or partition+map/reduce for that case. I almost never use map-indexed. In fact I almost never use indexing at all. Mostly, when I have a sequential collection (vector, list, or generic seq), I need to iterate over all the elements, and I’m doing that with map or reduce. IMO, map-indexed has a code-smell that indicates that you’re reaching for an imperative algorithm when perhaps a functional algorithm would be better. Surely, there are times when map-indexed is just what you need, which is why it’s there, but typically not in my experience.
I would agree that map-indexed + *nth* is a code smell. I use map-indexed all the time though, just when I need the index, not other elements in the list
Maybe I'm just too used to Python (and I only know some Clojure) but I don't have the same experience. Usually using generators and itertools will really help you shorten your code. I'm working in a data science adjacent field so a lot of code is just frameworks anyways but I don't feel limited in pure Python either.
If you come across a post or an example that shows those differences, I would be very interested!
If you come across a post or an example that shows those differences, I would be very interested!
Could you show an example or two between Elixir and Clojure?
This is not the best example, it's just the most recent example (what I was doing last night) that can fit in one screen:
Replacing this report function (12 lines) + one other function (6 lines) + execution code (18 lines) is now spread across 3 modules in Elixir, each over 100 lines. It's not entirely apples to oranges, but trying to provide as much context as possible.
This is all just to say that the high effort in reading it is normally a result of information density, not complexity or syntax. There are real advantages to being able to see your entire problem space on a single page.
(defn report [date]
(let [[d w m q y] (-> (comp tier* recall* (partial c/shift date :day))
(map [1 7 30 90 365]))]
(reduce (fn [memo {:keys [card code]}]
(cond-> memo
true (update code (fnil update [0 0 0 0 0 0 0 0 0 0]) (q card) inc)
(<= 4 (d card)) (update-in [code 6] inc)
(<= 4 (w card)) (update-in [code 7] inc)
(<= 4 (m card)) (update-in [code 8] inc)
(<= 4 (y card)) (update-in [code 9] inc)))
{}
(k/index :intels)))))
def report(facets, intels, day) do
[d, w, m, q, y] = for x <- [1, 7, 30, 90, 365], do: Date.shift(day, day: x)
Enum.reduce(intels, %{}, fn intel, acc ->
facet = Map.get(facets, intel.uuid, :zero)
[q0, q1, q2, q3, q4, q5, d4, w4, m4, y4] =
acc[intel.code] || [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
quarterly_tier = tier(facet, q)
Map.put(acc, intel.code, [
if(quarterly_tier == 0, do: q0 + 1, else: q0),
if(quarterly_tier == 1, do: q1 + 1, else: q1),
if(quarterly_tier == 2, do: q2 + 1, else: q2),
if(quarterly_tier == 3, do: q3 + 1, else: q3),
if(quarterly_tier == 4, do: q4 + 1, else: q4),
if(quarterly_tier == 5, do: q5 + 1, else: q5),
if(tier(facet, d) >= 4, do: d4 + 1, else: d4),
if(tier(facet, w) >= 4, do: w4 + 1, else: w4),
if(tier(facet, m) >= 4, do: m4 + 1, else: m4),
if(tier(facet, y) >= 4, do: y4 + 1, else: y4),
])
end)
end
Replacing this report function (12 lines) + one other function (6 lines) + execution code (18 lines) is now spread across 3 modules in Elixir, each over 100 lines. It's not entirely apples to oranges, but trying to provide as much context as possible.
This is all just to say that the high effort in reading it is normally a result of information density, not complexity or syntax. There are real advantages to being able to see your entire problem space on a single page.
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."
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
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.
Why call it jank? It is a negative associated word in most contexts that’s why I’m curious about it
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.
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.
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.
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".
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".
I view "jank" similarly to "cracked", not necessarily negative.
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.
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.
Is tech bro in the room with us right now?
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.
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.
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 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).
Ideally without controlling the code of the main application (e.g. to implement a plug-in).
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.
I'm very excited about jank, and it's on my backlog.
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.
[1]: https://github.com/mmtk/mmtk-core
[2]: https://dl.acm.org/doi/pdf/10.1145/3519939.3523440
- 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
> 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!
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!
Very cool project and I think you are doing it right. Best of luck with getting it off the ground!
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.
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.
> 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!
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
https://github.com/clasp-developers/clasp
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.
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.
You're in luck ;)
https://jank-lang.org/blog/2025-04-01-jank-has-been-renamed/
https://jank-lang.org/blog/2025-04-01-jank-has-been-renamed/
The "one letter danger" section is hilarious, but did you try to find any examples with a one-vowel difference?
Grody
I love the name Jank. I would use it just for the name alone.
What's the demonym for Jank devs? Janker?
Still deciding. Maybe jankster.
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.
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.
[deleted]
I suppose jank-yanker is off the table.
The cute form would be Jankiye
Yes but pronounced in the Nordic and Central European fashion (“yanker”)
Jankee seems like a perfectly janky demonym.
Jankobian?
Jankbroni
When there's a book, whoever does the illustrations should be a jankee doodle.
... Right, I'll show myself out.
... Right, I'll show myself out.
It can get adapted to a Broadway musical and named Damn Jankees
Jankoffs
/s
/s
What's the objection to the name? I don't get it.
Has negative connotations
https://fluentslang.com/jank-meaning/
https://fluentslang.com/jank-meaning/
Kind of like the name "Slack", which also keeps its product from being uses in enterprise settings? /s
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.
Janky - slang for something shit, crsp, cobbled together haphazardly...?
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!
So if you work for somewhere even worse than that, just leave!
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.
[0]: https://www.linkedin.com/pulse/building-cloud-choosing-lisp-...
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-...
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.
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.
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.
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 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.
I blame the jvm for this. Happy to see an implementation on llvm.
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.
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.
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.
Related: The janet programming language https://janet-lang.org/
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? 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:
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).
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).
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
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.
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
Was a little surprised to discover this was a real language and not an esoteric or joke language.
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.
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...
While interesting, I wasn't able to capitalize on it and ultimately dropped it, despite my enjoyment of using it.
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.
plenty of jobs don't mandate languages on everything.
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.
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.
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.
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.
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.
> 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.
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.
Great work! Also, the error messages are neat!
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!
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!
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/
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/
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.
The link to Rhombus is very interested, I hadn't heard of this and it looks very well developed. Will mess around with it.
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.
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?
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?
I do not believe I want to write my code in something that goes through a YAML parser.
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.
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.
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.
Good luck, jeaye.
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.