8 ms·

The Jank programming language

423 points by akkad33 1y ago

axblount 1y ago
Aside from the lack of JVM, what's holding back Jank from being a drop in Clojure replacement?
- Jeaye 1y ago
  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 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      > 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 1y ago
        In my (limited) experience with Clojure and other functional languages, this is usually true under situations where: 1. You’re mapping or reducing some dataset 2. Your iteration logic does not branch a lot 3. You can express your transformation logic using higher order functions (e.g. mapping a reduction operation across a multidimensional array) Some domains have a log of this style of work—finance comes to mind—others do not. I suspect this is why I’ve personally seen a lot more of Clojure in finance circles than I have in other industries.
      - barrell 1y ago
        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)
  - Jeaye 1y ago
    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 1y ago
      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
      - Jeaye 1y ago
        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 https://github.com/carp-lang/Carp I don't see why there can't be a Carp mode in jank, with bridges in place to connect the Clojurey world from the Carpy world. This would allow jank users to develop interactively to start with, figure out their shapes, use the REPL, etc. Then, if they want, they can lock down some parts of the code for both performance and correctness gains.
        narnarpapadaddy 1y ago
        FWIW, (I have one Clojure project I inherited at work that my team maintains) I love this direction.
      - 1y ago
  - beders 1y ago
    You need a REPL to truly read Clojure code. Could be a weakness or could be a strength. In my day to day work I consider a strength since I’m working at the REPL the whole day anyways
  - lisbbb 1y ago
    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.
- binary132 1y ago
  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 1y ago
    > I’m a bit curious why you chose to implement this as a different language (even though it implements Clojure) instead of an alternative Clojure backend and/or C++ syntax extension. jank is Clojure. However, the Clojure name is trademarked and using it requires permission which I don't have. Furthermore, I want to build upon the Clojure base to provide more, going forward. That may include static typing, value-based error handling, first class pattern matching, and so on. Those would be opt-in features on top of Clojure. All of these reasons lead me to not use Clojure in the name (like Clojure++, ClojureNative, etc). > Do you plan to make Windows support first-class? I think a lot of people looking at LLVM based languages are interested in alternatives to C++ for games. Indeed, a lot of game dev folks use Windows. Right now, jank's Windows support is limited. My initial audience is Clojure devs who want native access and lighter binaries. Once that launch has stabilized, I will focus on appealing to existing native devs who want to embed an interactive, functional language into their C++ applications. That will requires strengthening the Windows support, establishing stable native APIs, and writing the onboarding material for lisp, REPL-based editing, data-driven design, and so on. This is a much larger task, which is why I'm focusing on existing Clojure devs first.
    - neutronicus 1y ago
      I commented to this effect on Reddit, but my interest is entirely conditional on ability to embed Jank into a pre-existing C++ application as a shared library. Ideally without controlling the code of the main application (e.g. to implement a plug-in).
      - Jeaye 1y ago
        Yep, this will be an important use case and will be officially supported. For the first alpha release this year, I'm focusing on Clojure devs, but support for existing native devs will come once things stabilize.
- twism 1y ago
  Shouldn't it be an 'if' instead of 'when' in the first example?
  - Jeaye 1y ago
    Yes it should. Thanks for the keen eye and taking the time to point that out.
- no_wizard 1y ago
  Why call it jank? It is a negative associated word in most contexts that’s why I’m curious about it
  - amelius 1y ago
    I guess it stands out. "Git" is similar. "Rust" isn't a very positive word either. Perhaps it's a new trend. Maybe the answer is "all the good names have been taken" and/or they are simply lazy.
    - graemep 1y ago
      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.
  - barrenko 1y ago
    I view "jank" similarly to "cracked", not necessarily negative.
  - bgro 1y ago
    Yep I won’t use anything with a negative self deprecating name like this. Because some tech bro will use it as a a basis to disqualify my entire resume or sabotage an interview after solving the leetcode trivia troll questions and whatever other video game battles they add to the interview process in the future. Project manager fires the entire team except 1 intern to finish the project with 1000 points of stories in 1 sprint? Heh or did you just figure out jank wasn’t capable of doing the job what did you expect? Hotfix to fix a bug with the stage environment because the SREs set it up wrong? No bro it’s jank it’s that jank thing. Source: ctrl F “jank” in the message analytics and copilot says all matches are in the stage environment and that jank is also a tech thing. It also bright up every engineers profile that lists jank as a skill. Time to pick a scape goat.
    - athorax 1y ago
- benreesman 1y ago
  I don't have anything terribly insightful to say other than that I really like this project. I loved using Clojure back during it's brief time in the sun, it was a great time, and jank has all the same awesome vibes. I haven't used it on anything serious yet, it seems like it would be great for like a `zig`-flavored approach to C++ builds for example. I'm doing a big C++ project ground up at the moment, I think I'm going to get jank into it and see if I can automate some stuff. The compilation strategy is very much what Carmack did in Trinity and whether you got your inspiration there or independently had a great idea, that's good company to be keeping. Keep it up!
  - Jeaye 1y ago
    I hadn't heard of Carmack doing something similar, but I will take that company any day. Thanks for the kind words!
- zamalek 1y ago
  I'm very excited about jank, and it's on my backlog.
mgdev 1y ago
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 1y ago
  What's the demonym for Jank devs? Janker?
  - ForgotMyUUID 1y ago
    The cute form would be Jankiye
  - Jeaye 1y ago
    Still deciding. Maybe jankster.
    - DetroitThrow 1y ago
      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.
      - deleted 1y ago
        [deleted]
    - onionisafruit 1y ago
      I suppose jank-yanker is off the table.
  - AnimalMuppet 1y ago
    When there's a book, whoever does the illustrations should be a jankee doodle. ... Right, I'll show myself out.
npalli 1y ago
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 1y ago
  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 1y ago
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 1y ago
  Yeah it’s pretty incredible how unhelpful the error messages are. A true feat. Still love clojure but wow
catfacts 1y ago
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 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 1y ago
  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
- Jeaye 1y ago
  > 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!
sideeffffect 1y ago
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 1y ago
  > Are there Clojure libraries that don't use JVM(/JS/...)-specific stuff that works on any Clojure platform/dialect? Can such libraries be used on Jank out of the box? Correct. Any Clojure code which doesn't use interop will generally work with Clojure, ClojureScript, Clojure CLR, jank, etc. There are some exceptions, where different dialects don't fully implement a Clojure feature, but this is generally the case. > Or do library authors have to do something explicit in their libraries to enable their use in specific platforms/dialects? Clojure also supports reader macros to enable forms for specific dialects. This is basically like an #ifdef in the C world, where library devs can check if the code is currently being compiled for Clojure, ClojureScript, jank, and so on. This allows you to have a public function, for example, which internally just uses a reader conditional to do the correct thing. For example: (defn sleep [ms] #?(:clj (Thread/sleep ms) :jank (let [s (/ ms 1000) ns (* (mod ms 1000) 1000000) t (cpp/timespec. (cpp/long. s) (cpp/long. ns))] (cpp/nanosleep (cpp/& t) cpp/nullptr)))) That's using the currently working C and C++ interop to call the POSIX C function. The same could be done for the C++ version. This function can now be used in both Clojure and jank with no difference to the consumer.
- simongray 1y ago
  > 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).
caim 1y ago
Great work! Also, the error messages are neat!
rtpg 1y ago
I am once again calling for someone to make something that's "basically clojure" but with whitespace instead of parens. Parens don't matter, but giving values names causing indentation is something I simply cannot abide as a terminal intermediary value name giving person. EDIT: oh and also something with "proper" multiline comments. Thanks!
- Jeaye 1y ago
  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/ https://rhombus-lang.org/
  - rtpg 1y ago
    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.
- chromalchemy 1y ago
  This exists. https://yamlscript.org/blog/2025-06-24/how-does-ys-work/ https://yamlscript.org/blog/2025-06-24/how-does-ys-work/ https://yamlscript.org/about/ https://yamlscript.org/about/ - YAMLScript (or YS) A graal pre-compiled Clojure environment, like Babashka, but uses a different, looser syntax (yaml based). Can run from command line. Like a nicer Python?
  - rtpg 1y ago
    I do not believe I want to write my code in something that goes through a YAML parser.
- 1y ago
jankjankjank 1y ago
I feel like I’ve been coding jank already for most of my life.
- Jeaye 1y ago
  Welcome home.
xqb64 1y ago
Good luck, jeaye.
jhoechtl 1y ago
Related: The janet programming language https://janet-lang.org/ https://janet-lang.org/
padjo 1y ago
Was a little surprised to discover this was a real language and not an esoteric or joke language.
lewdwig 1y ago
I love Clojure, I really do, but it feels to me like what I once thought was its unstoppable march ground to a halt and then it kinda fell out of the nerd consciousness. I’m hopeful jank might be the shot in at arm Clojure needs to get going again.
- JonChesterfield 1y ago
  I blame the jvm for this. Happy to see an implementation on llvm.
  - latexr 1y ago
    Anecdotally, the JVM is exactly why I never gave Clojure a shot, despite being otherwise immensely interested. I remember reading about Jank a while back on HN and got excited for it. Though I wonder if it’ll be too late to recapture my interest by the time it’s ready. Hopefully not.
  - 3036e4 1y ago
    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.
Lyngbakr 1y ago
What is jank's tooling like? Clojure's felt very much like an afterthought, unfortunately. I do like having a decent set of tools right out of the box. I think Gleam was smart in this respect.
- Jeaye 1y ago
  jank will lean heavily into leiningen, though it will have deps.edn support. I think that the process of doing this is much simpler than whatever Clojure CLI devs are doing these days: lein new jank hello-world cd hello-world lein run lein test lein package Going forward, we'll see about a leaner version of lein. Maybe we can fork lein and compile it in jank or maybe we'll need to make our own. For now, default lein will be the recommendation.
densh 1y ago
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 https://github.com/mmtk/mmtk-core [2]: https://dl.acm.org/doi/pdf/10.1145/3519939.3523440 https://dl.acm.org/doi/pdf/10.1145/3519939.3523440
- Jeaye 1y ago
  > 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!
jcmontx 1y ago
how does memory management work? malloc and such?
- Jeaye 1y ago
  jank has a GC, just like Clojure. jank is Clojure. The seamless C++ interop allows for stack-allocated C++ objects, as well as manual memory management, but the default is that everything is tracked by the GC.
norir 1y ago
Having scanned the source, I believe there is a better design for this language. There exists a much smaller subset of jank that is capable of compiling itself. I am quite sure that you could write a bootstrap compiler in clojure (but restricted to the same subset) that translates to clojure (or some other language you prefer targeting). My guess, from experience writing small compilers, is it should be doable in ~5000 lines or even less. Once you had that, you could then write a backend that translates to c. This gives you a native compiler for this small subset of jank. Applied to its own source code, you get a native compiler binary for free and cut the cord from clojure. Now you have a native compiler and a very small, tight language. Because it is so small, it is easy both to check correctness and optimize. You can add new backends relatively easily. For the repl, you can compile functions into their own hash-addressed shared libraries using a c compiler and dlopen them. TCC is very fast for this purpose even if the generated code isn't quite as good as optimized gcc or clang. All of the future vision could be implemented on top of this foundation. The current approach is likely going to just bog the author down, dealing with accidental complexity from c++ and llvm especially. It is also better to have fewer features implemented completely and correctly than more features incompletely or incorrectly implemented.
- Jeaye 1y ago
  > 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.
lisbbb 1y ago
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.
- Jeaye 1y ago
  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-technologies https://survey.stackoverflow.co/2024/technology#top-paying-t...
  - lisbbb 1y ago
    While interesting, I wasn't able to capitalize on it and ultimately dropped it, despite my enjoyment of using it.
- lucyjojo 1y ago
  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.

423 points by akkad33 1y ago

axblount 1y ago

Aside from the lack of JVM, what's holding back Jank from being a drop in Clojure replacement?

Jeaye 1y ago
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 1y ago

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 1y ago
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 1y ago
  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 1y ago
    > 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 1y ago
      In my (limited) experience with Clojure and other functional languages, this is usually true under situations where: 1. You’re mapping or reducing some dataset 2. Your iteration logic does not branch a lot 3. You can express your transformation logic using higher order functions (e.g. mapping a reduction operation across a multidimensional array) Some domains have a log of this style of work—finance comes to mind—others do not. I suspect this is why I’ve personally seen a lot more of Clojure in finance circles than I have in other industries.
    - barrell 1y ago
      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)
- Jeaye 1y ago
  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 1y ago
    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
    - Jeaye 1y ago
      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 https://github.com/carp-lang/Carp I don't see why there can't be a Carp mode in jank, with bridges in place to connect the Clojurey world from the Carpy world. This would allow jank users to develop interactively to start with, figure out their shapes, use the REPL, etc. Then, if they want, they can lock down some parts of the code for both performance and correctness gains.
      - narnarpapadaddy 1y ago
        FWIW, (I have one Clojure project I inherited at work that my team maintains) I love this direction.
    - 1y ago
- beders 1y ago
  You need a REPL to truly read Clojure code. Could be a weakness or could be a strength. In my day to day work I consider a strength since I’m working at the REPL the whole day anyways
- lisbbb 1y ago
  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.
binary132 1y ago
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 1y ago
  > I’m a bit curious why you chose to implement this as a different language (even though it implements Clojure) instead of an alternative Clojure backend and/or C++ syntax extension. jank is Clojure. However, the Clojure name is trademarked and using it requires permission which I don't have. Furthermore, I want to build upon the Clojure base to provide more, going forward. That may include static typing, value-based error handling, first class pattern matching, and so on. Those would be opt-in features on top of Clojure. All of these reasons lead me to not use Clojure in the name (like Clojure++, ClojureNative, etc). > Do you plan to make Windows support first-class? I think a lot of people looking at LLVM based languages are interested in alternatives to C++ for games. Indeed, a lot of game dev folks use Windows. Right now, jank's Windows support is limited. My initial audience is Clojure devs who want native access and lighter binaries. Once that launch has stabilized, I will focus on appealing to existing native devs who want to embed an interactive, functional language into their C++ applications. That will requires strengthening the Windows support, establishing stable native APIs, and writing the onboarding material for lisp, REPL-based editing, data-driven design, and so on. This is a much larger task, which is why I'm focusing on existing Clojure devs first.
  - neutronicus 1y ago
    I commented to this effect on Reddit, but my interest is entirely conditional on ability to embed Jank into a pre-existing C++ application as a shared library. Ideally without controlling the code of the main application (e.g. to implement a plug-in).
    - Jeaye 1y ago
      Yep, this will be an important use case and will be officially supported. For the first alpha release this year, I'm focusing on Clojure devs, but support for existing native devs will come once things stabilize.
twism 1y ago
Shouldn't it be an 'if' instead of 'when' in the first example?
- Jeaye 1y ago
  Yes it should. Thanks for the keen eye and taking the time to point that out.
no_wizard 1y ago
Why call it jank? It is a negative associated word in most contexts that’s why I’m curious about it
- amelius 1y ago
  I guess it stands out. "Git" is similar. "Rust" isn't a very positive word either. Perhaps it's a new trend. Maybe the answer is "all the good names have been taken" and/or they are simply lazy.
  - graemep 1y ago
    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.
- barrenko 1y ago
  I view "jank" similarly to "cracked", not necessarily negative.
- bgro 1y ago
  Yep I won’t use anything with a negative self deprecating name like this. Because some tech bro will use it as a a basis to disqualify my entire resume or sabotage an interview after solving the leetcode trivia troll questions and whatever other video game battles they add to the interview process in the future. Project manager fires the entire team except 1 intern to finish the project with 1000 points of stories in 1 sprint? Heh or did you just figure out jank wasn’t capable of doing the job what did you expect? Hotfix to fix a bug with the stage environment because the SREs set it up wrong? No bro it’s jank it’s that jank thing. Source: ctrl F “jank” in the message analytics and copilot says all matches are in the stage environment and that jank is also a tech thing. It also bright up every engineers profile that lists jank as a skill. Time to pick a scape goat.
  - athorax 1y ago
benreesman 1y ago
I don't have anything terribly insightful to say other than that I really like this project. I loved using Clojure back during it's brief time in the sun, it was a great time, and jank has all the same awesome vibes. I haven't used it on anything serious yet, it seems like it would be great for like a `zig`-flavored approach to C++ builds for example. I'm doing a big C++ project ground up at the moment, I think I'm going to get jank into it and see if I can automate some stuff. The compilation strategy is very much what Carmack did in Trinity and whether you got your inspiration there or independently had a great idea, that's good company to be keeping. Keep it up!
- Jeaye 1y ago
  I hadn't heard of Carmack doing something similar, but I will take that company any day. Thanks for the kind words!
zamalek 1y ago
I'm very excited about jank, and it's on my backlog.

mgdev 1y ago

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 1y ago
What's the demonym for Jank devs? Janker?
- ForgotMyUUID 1y ago
  The cute form would be Jankiye
- Jeaye 1y ago
  Still deciding. Maybe jankster.
  - DetroitThrow 1y ago
    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.
    - deleted 1y ago
      [deleted]
  - onionisafruit 1y ago
    I suppose jank-yanker is off the table.
- AnimalMuppet 1y ago
  When there's a book, whoever does the illustrations should be a jankee doodle. ... Right, I'll show myself out.

npalli 1y ago

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 1y ago
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 1y ago

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 1y ago
Yeah it’s pretty incredible how unhelpful the error messages are. A true feat. Still love clojure but wow

catfacts 1y ago

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 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 1y ago
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
Jeaye 1y ago
> 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!

sideeffffect 1y ago

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 1y ago
> Are there Clojure libraries that don't use JVM(/JS/...)-specific stuff that works on any Clojure platform/dialect? Can such libraries be used on Jank out of the box? Correct. Any Clojure code which doesn't use interop will generally work with Clojure, ClojureScript, Clojure CLR, jank, etc. There are some exceptions, where different dialects don't fully implement a Clojure feature, but this is generally the case. > Or do library authors have to do something explicit in their libraries to enable their use in specific platforms/dialects? Clojure also supports reader macros to enable forms for specific dialects. This is basically like an #ifdef in the C world, where library devs can check if the code is currently being compiled for Clojure, ClojureScript, jank, and so on. This allows you to have a public function, for example, which internally just uses a reader conditional to do the correct thing. For example: (defn sleep [ms] #?(:clj (Thread/sleep ms) :jank (let [s (/ ms 1000) ns (* (mod ms 1000) 1000000) t (cpp/timespec. (cpp/long. s) (cpp/long. ns))] (cpp/nanosleep (cpp/& t) cpp/nullptr)))) That's using the currently working C and C++ interop to call the POSIX C function. The same could be done for the C++ version. This function can now be used in both Clojure and jank with no difference to the consumer.
simongray 1y ago
> 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).

caim 1y ago

Great work! Also, the error messages are neat!

rtpg 1y ago

I am once again calling for someone to make something that's "basically clojure" but with whitespace instead of parens. Parens don't matter, but giving values names causing indentation is something I simply cannot abide as a terminal intermediary value name giving person. EDIT: oh and also something with "proper" multiline comments. Thanks!

Jeaye 1y ago
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/ https://rhombus-lang.org/
- rtpg 1y ago
  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.
chromalchemy 1y ago
This exists. https://yamlscript.org/blog/2025-06-24/how-does-ys-work/ https://yamlscript.org/blog/2025-06-24/how-does-ys-work/ https://yamlscript.org/about/ https://yamlscript.org/about/ - YAMLScript (or YS) A graal pre-compiled Clojure environment, like Babashka, but uses a different, looser syntax (yaml based). Can run from command line. Like a nicer Python?
- rtpg 1y ago
  I do not believe I want to write my code in something that goes through a YAML parser.
1y ago

jankjankjank 1y ago

I feel like I’ve been coding jank already for most of my life.

Jeaye 1y ago
Welcome home.

xqb64 1y ago

Good luck, jeaye.

jhoechtl 1y ago

Related: The janet programming language https://janet-lang.org/ https://janet-lang.org/

padjo 1y ago

Was a little surprised to discover this was a real language and not an esoteric or joke language.

lewdwig 1y ago

I love Clojure, I really do, but it feels to me like what I once thought was its unstoppable march ground to a halt and then it kinda fell out of the nerd consciousness. I’m hopeful jank might be the shot in at arm Clojure needs to get going again.

JonChesterfield 1y ago
I blame the jvm for this. Happy to see an implementation on llvm.
- latexr 1y ago
  Anecdotally, the JVM is exactly why I never gave Clojure a shot, despite being otherwise immensely interested. I remember reading about Jank a while back on HN and got excited for it. Though I wonder if it’ll be too late to recapture my interest by the time it’s ready. Hopefully not.
- 3036e4 1y ago
  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.

Lyngbakr 1y ago

What is jank's tooling like? Clojure's felt very much like an afterthought, unfortunately. I do like having a decent set of tools right out of the box. I think Gleam was smart in this respect.

Jeaye 1y ago
jank will lean heavily into leiningen, though it will have deps.edn support. I think that the process of doing this is much simpler than whatever Clojure CLI devs are doing these days: lein new jank hello-world cd hello-world lein run lein test lein package Going forward, we'll see about a leaner version of lein. Maybe we can fork lein and compile it in jank or maybe we'll need to make our own. For now, default lein will be the recommendation.

densh 1y ago

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 https://github.com/mmtk/mmtk-core [2]: https://dl.acm.org/doi/pdf/10.1145/3519939.3523440 https://dl.acm.org/doi/pdf/10.1145/3519939.3523440

Jeaye 1y ago
> 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!

jcmontx 1y ago

how does memory management work? malloc and such?

Jeaye 1y ago
jank has a GC, just like Clojure. jank is Clojure. The seamless C++ interop allows for stack-allocated C++ objects, as well as manual memory management, but the default is that everything is tracked by the GC.

norir 1y ago

Having scanned the source, I believe there is a better design for this language. There exists a much smaller subset of jank that is capable of compiling itself. I am quite sure that you could write a bootstrap compiler in clojure (but restricted to the same subset) that translates to clojure (or some other language you prefer targeting). My guess, from experience writing small compilers, is it should be doable in ~5000 lines or even less. Once you had that, you could then write a backend that translates to c. This gives you a native compiler for this small subset of jank. Applied to its own source code, you get a native compiler binary for free and cut the cord from clojure. Now you have a native compiler and a very small, tight language. Because it is so small, it is easy both to check correctness and optimize. You can add new backends relatively easily. For the repl, you can compile functions into their own hash-addressed shared libraries using a c compiler and dlopen them. TCC is very fast for this purpose even if the generated code isn't quite as good as optimized gcc or clang. All of the future vision could be implemented on top of this foundation. The current approach is likely going to just bog the author down, dealing with accidental complexity from c++ and llvm especially. It is also better to have fewer features implemented completely and correctly than more features incompletely or incorrectly implemented.

Jeaye 1y ago
> 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.

lisbbb 1y ago

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.

Jeaye 1y ago
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-technologies https://survey.stackoverflow.co/2024/technology#top-paying-t...
- lisbbb 1y ago
  While interesting, I wasn't able to capitalize on it and ultimately dropped it, despite my enjoyment of using it.
lucyjojo 1y ago
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.