[HN Gopher] Jank Programming Language
___________________________________________________________________
Jank Programming Language
Author : akkad33
Score : 172 points
Date : 2025-07-06 16:56 UTC (3 days ago)
(HTM) web link (jank-lang.org)
(TXT) w3m dump (jank-lang.org)
| axblount wrote:
| Aside from the lack of JVM, what's holding back Jank from being a
| drop in Clojure replacement?
| Jeaye wrote:
| 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.
| Jeaye wrote:
| 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.
| dzonga wrote:
| 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.
| barrell wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| Jeaye wrote:
| 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 wrote:
| 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
| Jeaye wrote:
| 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.
| binary132 wrote:
| 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 wrote:
| > 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.
| twism wrote:
| Shouldn't it be an 'if' instead of 'when' in the first example?
| Jeaye wrote:
| Yes it should. Thanks for the keen eye and taking the time to
| point that out.
| mgdev wrote:
| 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.
| onionisafruit wrote:
| What's the demonym for Jank devs? Janker?
| ForgotMyUUID wrote:
| The cute form would be Jankiye
| Jeaye wrote:
| Still deciding. Maybe jankster.
| DetroitThrow wrote:
| 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 wrote:
| I suppose jank-yanker is off the table.
| didibus wrote:
| You're in luck ;)
|
| https://jank-lang.org/blog/2025-04-01-jank-has-been-renamed/
| intalentive wrote:
| What's the objection to the name? I don't get it.
| npalli wrote:
| 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 wrote:
| 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.
| defo10 wrote:
| 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 wrote:
| Yeah it's pretty incredible how unhelpful the error messages
| are. A true feat. Still love clojure but wow
| catfacts wrote:
| 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.
| Jtsummers wrote:
| [delayed]
| sideeffffect wrote:
| 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 wrote:
| > 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.
| caim wrote:
| Great work! Also, the error messages are neat!
___________________________________________________________________
(page generated 2025-07-09 23:00 UTC)