I think they mean the video thumbnail, which may or may not be AI-generated.

I don't think it is, considering they highlighted it in a post about human craft [1]. I read somewhere it was illustrated by felipemelo.net, but can't find the reference anymore

[1]: https://bsky.app/profile/cultrepo.bsky.social/post/3mjhubrh3...

It'll be interesting to learn whether it was AI-generated. It certainly SEEMS like it is. It has a few "tells":

- two belts and two Clojure logo belt buckles

- same code repeated on the steps (odd artistic choice if made by the artist)

- the seemingly out-of-place scarf, stylistically its color/pattern doesn't seem to fit

Either way, it seems like an homage to this Indiana Jones and the Temple of Doom poster:

https://www.slantmagazine.com/wp-content/uploads/2008/05/tem...

There’s nothing odd about two belts in this situation. One is the belt for the pants and the other is the utility belt holding the pouches. You need to be able to add and remove the utilities without having your pants fall.

The weird choice is having a belt and suspenders. That only works as a fashion choice, which makes little sense for an explorer.

the scarf matches the one Rich is wearing near the end of the documentary. the code matches what's on the Clojure source code, even if it's an odd choice. the two belts are in the draft, even if only one of them features the logo. the artist's instagram has a bunch of well colorized artwork. I believe it is really human made

Huh. I don’t doubt you, but I guess this is a sign pervasive AI/LLM generative artwork is messing with my brain’s pattern matching at a deep level.

That wouldn't be very interesting at all. It's just a thumbnail on a niche programming documentary

The BlueSky post has another interesting clue. The pencil sketch on the right. Seems possible a human artist drew the sketch, then had an AI model "colorize" it. And in so doing, maybe the AI model added the 3 genAI tells/artifacts I identified above.

Rich commented in one of the comments under the video pointing the same thing and he says it is not AI generated

At least the cult repo folks said on LinkedIn that it is not, which tbh is surprising.

https://www.linkedin.com/posts/emmalouisetracey_one-of-my-fa...

I'm working on the jank programming language!

https://github.com/jank-lang/jank

It's a native Clojure dialect which is also a C++ dialect, including a JIT compiler and nREPL server. I'm currently building out a custom IR so I can do optimization passes at the level of Clojure semantics, since LLVM will not be able to do them at the LLVM IR level.

You are hero! I just learned about this yesterday when I shared my Clojure editor: https://github.com/tlehman/hammock

I would love to know more about Jank, from what I read, it transpiles to C++ right?

As much as any C++ project would, yes. That includes either through the C ABI or through the various C++/Rust interop mechanisms.

jank is Clojure and will track upstream Clojure development. I'm working closely with the Clojure team and other dialect devs to ensure this remains the case. I am leading a cross-dialect clojure-test-suite to help ensure parity across all dialects: https://github.com/jank-lang/clojure-test-suite We have support or work ongoing for Clojure JVM, ClojureScript, Clojure CLR, babashka, Basilisp, and jank.

With that said, jank will do some trail blazing down other paths (see my other comments here about Carp), but they will be optional modes which people can enable which are specific to jank. Clojure compatibility will remain constant.

JIT compiling C++ is definitely the slowest thing we do. However, we're working on two different codegen modes.

1. C++

2. LLVM IR

The IR is much faster to compile, but its perf isn't nearly as good. This is meant to be a nice trade off, during iteration, so that you can use C++ codegen for your release artifact, but stick with IR when you're REPLing. The IR gen is still unstable right now, for the alpha, but we'll have both solidified this year.

Carp is great and I would love to include a mode of jank which is very much Carp-esque. If you're interested in working together on this, please let me know.

Most of my contributions were to the stdlib so my knowledge of the implementation of the type system is limited sadly.

Maybe Erik, the creator, would be interested. I know he was looking at rewriting Carp in cpp at some point.

We have a working nREPL server, but it's not yet merged into the jank repo. https://github.com/kylc/try-jank

There's a Clang bug getting in the way of the progress we want, so we'll need to work around. There's a lot I'm juggling, but this is high priority.

Thanks for the broken link report. That should be fixed now.

No full-lang static type system. jank has seamless C++ interop and all interop is statically typed, but as soon as things get back into Clojure land, it's all dynamically typed and hella polymorphic.

I will be exploring optional static typing modes for jank in the future, a la Carp. That will not be this year, though.

Please link to https://book.jank-lang.org/ for anything related to the jank alpha. I wasn't quite ready to announce the alpha, but I appreciate that folks are excited. :)

There's just a couple more compiler features I wanted to get merged, but everything should be in order for folks to follow the book and try jank out.

Hi! I'm excited about jank and so I'm excitedly reading through the book you just linked. I noticed some grammatical errors. Will you consider PRs to the `book` section of the code, or would you prefer feedback in some other format in order to better maintain your authorial voice?

Hi! I'm happy to accept grammatical PRs to the book. You could also report issues via Slack or Github issue. I will not be accepting larger PRs to the book, to maintain a consistent voice.

Cool! I'm still reading, but when I'm done I'll open a PR for the few small issues I've seen.

Thanks for your work on jank! I hope the Alpha brings you lots of new users, useful bug reports, and some contributors. :)

big kudos to all involved

This is superb. Thank you for making it and licensing it MIT. I think this is a contender to replace the lexer within jank. I'll do some benchmarking next year and we'll see!

Wow, that is a greate news!) Thanks for looking at it from this perspective! There are some benchmarks already available in the project - https://github.com/DotFox/edn.c/blob/main/bench/bench_integr...

you can run it locally with `make bench bench-clj bench-wasm`

Let me know if I can do anything to help you with support in jank.

It looks like the key missing part which would be needed for a lexer is source information (bare minimum: byte offset and size). I don't think edn.c can be used as a lexer without that, since error reporting requires accurate source information.

As a side note, I'm curious how much AI was used in the creation of edn.c. These days, I like to get a measure of that for every library I use.

It should be easy to add source info for every token, some of them already keep both (size and offset) I can create a branch for that.

> I'm curious how much AI was used in the creation of edn.c

A fair amount. This is my first big public project written in pure C. I did consult LLM about best practices for code organisation, memory management, difference in SIMD instructions between platforms, etc. All the things Clojure developer typically don't think about (luxury of a hosted language). Ultimately, the goal was to learn some part of C programming, working reader is a side effect of that.

> These days, I like to get a measure of that for every library I use.

Btw, I'm curious, what kind of measuring you are looking for?

Oooo that’d be nice.