Jeaye

You're welcome! It's work I'm happy to do.

Hey folks. I'm the jank creator.

jank is a full Clojure dialect with unprecedented C++ interop. Unlike the OG Lisp/C++ combo, Clasp, there is no bridge API necessary for registering C++ functions, types, or values. jank can seamlessly interop with any C++ by just including the headers. Interop includes template instantiations, overload resolution (implicit conversions, ADL, etc), exception throwing/catching, virtual function calls, and literally everything else.

jank _is C++_, since it compiles to C++ and uses the C++ type system. It ships with a Clang-powered JIT C++ compiler to make all of the REPL goodies work. jank also improves upon the C++ build ecosystem with Cargo-like tooling.

This means you can use jank to make C++ native applications, you can embed jank into your C++ applications, or you can even use jank to just write portable Clojure libraries that people use from other Clojure dialects.

We're still in alpha right now, so things are a bit unstable. We're targeting a more stable beta release in January. The best way you can help is to try jank out and report every friction point you have on Slack, Discord, or Github.

I've been working on jank for several years. It is not vibe-coded.

CLasp is the OG Lisp/C++ combo, but its interop is nowhere near seamless. Last I checked, Clasp requires that functions, types, and values must be registered, from C++, before being accessible in Lisp. This requires you to build a bridge between these two worlds, in C++ code. That's a huge seam.

In jank, you just require the C++ headers, like you would in C++, and then you access whatever you want from them, like you would in C++. jank's type system is the C++ type system. jank also compiles to C++. jank includes a Clang-based JIT C++ compiler to make all of this possible.

While we're here, has anyone seen any resources related to data-oriented design when GCs are involved? So much of data-oriented design is arena-focused, but that's not always possible, when the lifetime model of the code requires a GC (for whatever reason).

I feel like the DoD movement is a slow-moving, but big, change through how systems programming is done, but that there's still insufficient material for how to do this in different scenarios. I would really like to apply this more to my areas of work, which are also in C++, but there seems to be a gap between what they're presenting and how it can be applied.

More specifically, I'm using C++ to build a dynamic programming language runtime for a Clojure dialect. That runtime is required to be garbage collected, type-erased, and highly polymorphic. So I surely can't just SoA or AoS everything. Yes, I can pack my data, and I can avoid the GC whenever possible, both in compiler/runtime code and in generated code via escape analysis. But what about everything else, which is the 80% or more of the system? It could be that this runtime is too far at odds with DoD, but I generally see things as a gradient rather than black and white.

Do you have any recommended essential reading for this?

Ah, thanks for chiming in with your inspiring anecdote. I realize that perhaps I interpreted "working on" as pertaining to career work, rather than just investment of effort.

Your example of clowning shows something that requires real work and, as you laid out, hopefully does wonders to improving confidence, humility, humor, and charm. I wish you the best with that! And happy early birthday. :)

Would you mind sharing an example of "Working on something meaningful that pushes at the edge of my self actualization"? In my experience, work, even when meaningful, is quite separate from self actualization. I'm interested to hear how you're combining them.

I also rarely use multi-methods in Clojure. I just use maps and vectors and lists and keywords and strings and functions. Instead of multi-methods, I generally use a map of fns. When not writing open, extendable libraries, this is an even simpler choice which I find works well. Most of my Clojure work has been writing applications, so being able to extend in an open way is not a benefit. I'd prefer to keep everything centralized in one map.

Also, as I described above in the blog post, protocols/interfaces aren't needed to implement Clojure's object model either. They're just one approach. They're the nominal typing approach, in contrast with something like the structural typing approach, documented in the blog post. For that, we use C++20 concepts for structural typing predicates.

I am the creator of jank. I am also not interested in a flame war.

The key differentiator for jank is the seamless C++ interop, which is a problem not many people are willing to tackle, due to its scope and complexity. jank is a novel approach to this, providing incredible JIT and AOT support of arbitrary C++ libraries alongside your Clojure code, including a Cargo-inspired native build system for building your native deps along with your program (or finding them in the installed system).

For some people, there is another key differentiator, which is the amount of AI-generated code involved. My understanding is that Jolt and other newer dialects like Glojure have a lot of spunk and are exploring new ideas, given the velocity that AI-driven coding can provide. I don't see jank ever being categorized in that way.

Yes! This is exciting to see. Erin Catto is such a cool hacker. Thank you, Erin, for sharing your code with the open source community.

There wasn't anything about determinism in the announcement, but I'd really love to see some more about that, too. Trying to use Unity's built-in physics to make a networked billiards game is quite troubling, when none of the clients can happily agree on what happened.

I am researching for a talk on the philosophy of code, the similarities of engineering and art, and why we enjoy reading old code. This amazing work you folks have done may be an interesting tangent.

The biggest question I have for you is why you imagine we are so interested in reading these old scrolls. Surely some of it is to see whether or not, technically, we can. Surely some of it is to get a glimpse into the human expression inscribed on them. Are we looking to learn anything, or just to connect with our ancestors? I'd like to hear your take on it, both for why you think it's important and, if you know, why your colleagues feel similarly.