Readit News logoReadit News
Jeaye · 2 months 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.

benreesman · 2 months 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 · a month ago
I hadn't heard of Carmack doing something similar, but I will take that company any day. Thanks for the kind words!
dzonga · 2 months 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.

Jeaye · 2 months 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. :)

barrell · 2 months 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)

beders · 2 months 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 · a month 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.
no_wizard · 2 months ago
Why call it jank? It is a negative associated word in most contexts that’s why I’m curious about it
amelius · 2 months 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.
Quarrelsome · a month ago
all code is somewhat jank though.

While jank is technically a negative term, its quite playful as opposed to scathing. My favourite usage was in MTG where large control decks that just slap together strong cards are referred to as "jank piles".

barrenko · 2 months ago
I view "jank" similarly to "cracked", not necessarily negative.
bgro · 2 months 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.

binary132 · 2 months 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 · 2 months 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.

twism · 2 months ago
Shouldn't it be an 'if' instead of 'when' in the first example?
Jeaye · 2 months ago
Yes it should. Thanks for the keen eye and taking the time to point that out.
zamalek · a month ago
I'm very excited about jank, and it's on my backlog.
densh · 2 months 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

[2]: https://dl.acm.org/doi/pdf/10.1145/3519939.3523440

Jeaye · a month 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!

densh · a month ago
Very cool project and I think you are doing it right. Best of luck with getting it off the ground!
catfacts · 2 months 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

In that post and comments we read that Clapp was 100x slower that sbcl, and the author of Clapp claimed: "LLVM is a great library for implementing C and C++ but more work needs to be done to support Lisp features like closures and first-class functions. We are working on that now".

I hope Clapp's author work in the last 11 years could help today efforts. Surely, the LLVM of today is not that of 11 years ago. Anyway, IMHO, sharing some knowledge could be productive for any project that is about C++, Lisp or Clojure using LLVM.

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

On the happy path, I think that Julia transpile to LLVM, but Julia is the result of many men working years at it. Honestly, I don't think that one single programmer to be able to create such a big project as a performant clojure in C++ will the ability to compile code quickly. Getting sbcl speed and compilation speed would be an extraordinary feat!

In Go there were great sacrifices to get fast compilation, and the problems to include generics, trying to avoid blows up compilation because some type checking is NP-complete.

Also perhaps ECL, a lisp in C, can gives us some hints about how to get better performance and compilation speed.

Perhaps I am just too old to be open to new dreams, anyway I hope the best to this project and I thank to Clojurists Together for supporting this project. It must be very intellectual rewarding to work in a project whose aim is to extend and improve your favorite computer language. But the journey will be no an easy one, that's for sure.

Jeaye · 2 months 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!

Jtsummers · 2 months 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

mgdev · 2 months 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.

didibus · 2 months ago
alanbernstein · 2 months ago
The "one letter danger" section is hilarious, but did you try to find any examples with a one-vowel difference?
bee_rider · 2 months ago
Grody
fud101 · 2 months ago
I love the name Jank. I would use it just for the name alone.
onionisafruit · 2 months ago
What's the demonym for Jank devs? Janker?
Jeaye · 2 months ago
Still deciding. Maybe jankster.
ForgotMyUUID · 2 months ago
The cute form would be Jankiye
eduction · 2 months ago
Yes but pronounced in the Nordic and Central European fashion (“yanker”)
dxdm · 2 months ago
Jankee seems like a perfectly janky demonym.
magicalhippo · 2 months ago
Jankobian?
gkhartman · 2 months ago
Jankbroni
AnimalMuppet · 2 months ago
When there's a book, whoever does the illustrations should be a jankee doodle.

... Right, I'll show myself out.

replwoacause · 2 months ago
Jankoffs

/s

intalentive · 2 months ago
What's the objection to the name? I don't get it.
hotpocket777 · 2 months ago
Has negative connotations

https://fluentslang.com/jank-meaning/

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

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

mgdev · 2 months ago
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-...

lewdwig · 2 months 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 · 2 months ago
I blame the jvm for this. Happy to see an implementation on llvm.
latexr · 2 months 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 · 2 months 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.
jhoechtl · 2 months ago
Related: The janet programming language https://janet-lang.org/
sideeffffect · 2 months 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 · 2 months 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 · 2 months 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).

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