Rendered at 20:44:22 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
phforms 1 days ago [-]
As a more-or-less neutral observation (I still kind-of like the project): What I find curious - perhaps a sign of these times: After just 2-3 months in development (judging from the repo commits, obviously I have no insight into what came before), the developer already communicates Jolt as a feature-complete, polished (perhaps even mature) Clojure dialect with multiple Jolt-adapted libraries from JVM-Clojure, FFI, Fibers, already with a professional looking and marketing-focussed website, detailled documentation, nREPL support, etc. Things I wouldn’t expect so soon from a language developed (mostly?) by a single person in such an early release stage.
I don’t know how to get a feeling about the actual state of projects like this anymore, so I always remain a bit suspicious. In Clojure, there is the (Rich Hickey inspired) design philosophy of “hammock driven development”, where we don’t rush things, let them simmer while lying in the hammock, sleeping on them, taking a walk, etc. Makes me wonder if projects like this are too rushed these days without thinking things through, discussing design decisions and getting ideas from other people, letting them mature over time. This isn’t specifically about Jolt (I don’t know much about it or its creator), it just inspired the thought, especially when comparing it to projects like Jank which has been years in development, with lots of feedback from the community and Clojure core maintainers as input.
iLemming 4 hours ago [-]
> I don’t know much about it or its creator
The guy literally has published book(s) on Clojure - not some random, unknown, AI-wielding teenager from somewhere in Nebraska. I'm pretty sure they know what they're doing.
But of course, nothing is wrong with being suspicious about any new projects these days. Overall, I agree with your sentiment here.
yogthos 23 hours ago [-]
The reason it's possible to move fast here is due to the fact that I'm porting an existing language to a new runtime. All the hard work and hammock time has already been spent by the core Clojure team and the community. I'm not aiming to reinvent the wheel here. Furthermore, having worked with Clojure for nearly two decades now, I have a very good idea of what the language does, and what I need to implement on the host platform.
Once I had the basics bootstrapped, it was really a matter of getting tests passing, and then getting more and more libraries to run on it which allowed me to exercise their own tests. And that's what really made the whole thing possible. It's sort of the ideal scenario where you have very well specified inputs and outputs, and a ton of existing tests to ensure you are implementing the behaviors correctly.
The only other aspect here is performance, and that's addressed by having an extensive benchmark harness which compares with JVM timings. This allows me to see where performance gaps are, and focus on addressing them.
I would be careful in extending my experience of being able to port Clojure to Chez Scheme runtime to working with LLMs in general because in most cases you don't have such well defined parameters when you start.
iainctduncan 21 hours ago [-]
This is the germane point here. I'm not into LLM coding myself, but was talking about just this with my CS PhD supervisor yesterday, and porting language implementations is basically a perfect use case for them. He's been using them for porting examples from one language to another and was saying it was perfect - he already knows what he wants to see, understands both languages, and needs a syntax aware typist, essentially.
jwr 10 hours ago [-]
This. Good stable foundations allow for quick software development. Even if you use AI for coding, working with Clojure as an experienced developer produces extremely good results quickly because of the great foundations.
I love the expression "the hammock time has already been spent": it is actually very accurate and I'm very grateful to the Clojure team and community for spending that time!
mark_l_watson 22 hours ago [-]
Great work. It just simply worked for me.
rahen 23 hours ago [-]
Not slop, though. The main developer is Dmitri Sotnikov (yogthos), who's been around in the Clojure scene for a long time and knows what he's doing.
However, you're right to point out that the development is moving really fast.
I'm building a Clojure compiler for machine learning (https://github.com/sheaf-lang/sheaf), and after 9 months, it's still very far from being production-ready.
phforms 22 hours ago [-]
From what I’ve seen so far, I would also not dismiss it as slop, even though I’m generally against vibe-coding (but more for ethical and environmental reasons, not because the code is inherently bad/slop/whatever). Many people seem to have a hard time acknowledging that LLMs actually can produce good stuff, but it highly depends on the experience of the developer who guides them.
If a dev is competent and has enough experience actually writing code and making good design decisions, I see no reason to judge their work on the basis of what tools they used to get the job done. However, it may still put me off, since I find it hard to value LLM-written code the same way I value human-written code, even though it may be equally good or even better in quality.
lenkite 13 hours ago [-]
The website is clearly slop. I KNOW it has been generated because it has the bog-standard unique claude LLM card-mistake that humans who hand-code just DONT make.
iLemming 3 hours ago [-]
Ah, so you're saying my Mazda that's manufactured has little (or no) value because it wasn't hand-crafted like a Bugatti? I suppose I should be ashamed to even call it "a vehicle". What a shame - assembled by a bunch of stupid machines, god knows in what part of Japan.
davexunit 23 hours ago [-]
> Not slop, though.
What would you call 2k commits in 2 months by a single committer if not slop?
rahen 23 hours ago [-]
It definitely is vibe-coded, but yogthos is a competent programmer who has been working on public Clojure projects and repos since 2009, and has maintained a large Clojure framework since well before LLMs were a thing.
I don't think "2k commits in 2 months" is enough to dismiss as slop when it's being developed by a competent Clojure dev.
YorickPeterse 23 hours ago [-]
Competent or not, slop is still slop. The website in particular uses the exact same copy-paste layout/style produced by LLMs and used by pretty much every slop project out there.
One very quick "slop or not?" test is to see if em dashes are used in the source code where they literally never make sense. It's not a great test, but it's one that consistently turns out to be good enough. The results should speak for themselves: https://github.com/search?q=repo%3Ajolt-lang%2Fjolt+%E2%80%9...
danieltanfh95 14 hours ago [-]
Probably good to note that this person is building his own language: https://inko-lang.org/
yogthos 22 hours ago [-]
The website layout is the same one I used in projects like Luminus long before LLMs even existed https://luminusweb.com
If you have specific comments about the quality of the code then I'd be happy to discuss that. Attacking other people's work because they used tools you don't understand is just toxic trolling. And the fact that you judge code quality by the number of em dashes in the comments really speaks volumes.
Maybe spend a bit of time figuring out how to use new tools effectively instead of harping on what other people are doing.
It's very telling that whenever somebody starts braying about slop, they never have anything of substance to say. All the noise you add to discussions people are trying to have is the real slop.
didibus 17 hours ago [-]
If you consider all AI generated text or code slop, then sure, the project's code is AI generated.
But in my case I think there are levels. In this case, the author has the expertise needed to properly design the work and assess the quality of the output. And it seems they intend to maintain and evolve the library actively and long term.
Would I prefer a serious Clojure on chez that's all hand-written, for sure, but beggars can't be choosers.
broken-kebab 22 hours ago [-]
'Slop' is a word about quality, like in 'AI slop' - a low quality code generated with LLM. Did OP managed to achieve reasonable quality notwithstanding the speed? I don't know yet, but unless you can point to something sloppy in the repo, calling it slop may not be warranted.
andsoitis 19 hours ago [-]
> > Not slop, though.
> What would you call 2k commits in 2 months by a single committer if not slop?
Productivity. Slop is when you push a huge volume of garbage or mediocre stuff, no?
yogthos 23 hours ago [-]
If you have any actual constructive criticism of the code, then I'd love to hear them.
davexunit 22 hours ago [-]
Why would I read something you couldn't be bothered to write?
andsoitis 19 hours ago [-]
That's such a knee-jerk, unproductive, smug, uncritical retort. Why?
blks 15 hours ago [-]
Tbf, author didn’t really read or write it, why anyone else should
yogthos 8 hours ago [-]
I really love how people keep trotting out this straw man man that working with LLMs is just typing a prompt and then having LLM magically produce a working project. In practice, you obviously read the code to understand if it makes sense, and iterate on a solution just as you would when writing it by hand.
All you're doing here is exposing the fact that you have no clue how these tools actually work, or how to use them effectively.
cindyllm 18 hours ago [-]
[dead]
didibus 17 hours ago [-]
I'm a Jolt user and active Clojure user, and I'd say you're right in a sense.
The caveat is that this isn't typical AI slop. The author knows the subject deeply, designed the system themselves, has extensive Clojure test suites to validate against, and has basically been working on it 24/7.
Can you trust it like a compiler someone spent 7 years writing and knows line by line? Probably not. But it's closer to alpha software than useless slop. As more people use it, we'll find out how robust it is, and whatever issues exist can be fixed as they're found.
So ya, I agree you shouldn't be asked to review AI generated code the author didn't review themselves. I think the ask here is more to try it and see how complete and robust it actually is. And even that only makes sense because the author is a known expert who appears to be steering the model carefully.
yogthos 21 hours ago [-]
The real question is why you feel the need to comment on something you don't care to understand. Thanks for admitting you're just trolling and there's no point trying to engage with you.
It's really unfortunate that Hacker News has become an echo chamber of AI trash, but I suppose that's to be expected from people who have a vested interest in OpenAI and Anthropic, to the detriment of literally the entire world. I'm quite confident that YC is taking deliberate action to portray LLMs as a good thing much like Fox News.
iLemming 3 hours ago [-]
LLMs are not only OpenAI and Anthropic. Some of us liberally use local models as well. You can't just portray the entire chunk of innovation as "trash". It's like calling the invention of plastics as such. Even though it has brought tons of problems, there's just no way to uninvent things back into oblivion. It's illogical to ask people to stop talking about plastic, and encourage them to not use any - that's just dumb and pointless and won't make any problems magically disappear.
Au contraire - if anything, we should talk about LLMs more and we should find more ways to democratize this technology. Silencing and scolding people won't help fight OpenAI and Anthropic's hegemony.
davexunit 1 days ago [-]
You're right to be suspicious: it's slop.
iLemming 3 hours ago [-]
This is such a disingenuous, childish, immature and ignorant take - I can't even remain calm without getting angry.
Have you ever, kids, tried building anything useful? Anything practical, anything that actually works, anything beneficent? With or without AI?
Well, if you have in fact ever tried, perhaps you'd know that building reasonably complex software remains a difficult, challenging, unappreciated work. With or without the help of any tooling. AI-assistants included.
Maybe try building something good first. Earn your right to throw the first stone, come engaged, come prepared, ask questions.
What you're doing is a fucking slop. Human slop of ignorance. Worst kind.
davexunit 18 minutes ago [-]
Okay, I'm gonna go work on something good. Will return with questions.
23 hours ago [-]
davexunit 1 days ago [-]
This appears to be vibecoded but not disclosed as such. 2k commits from a single author starting from June 1st with really long commit messages and source code comments. The GitHub org has 19 additional projects that are all recently created.
Vibecoding means you don't pay much attention to the code, not the case here.
xedrac 19 hours ago [-]
I think the author has been very open about the use of LLMs. And while I am very wary of LLM slop, this is one use case where it makes complete sense to utilize them to the fullest. A Clojure implementation already exists for LLMs to reference, and tons of test cases to verify behavior. It doesn't get better than that for LLM usage.
smartmic 1 days ago [-]
Besides this and jank, there is also Janet; playing in the league of Lisp to standalone binaries. It’s also cool!
I spent a couple of days digging in to Janet and what surprised me was how even though at a surface level it resembles Clojure, under the hood its actually quite radically different.
It has a lot of very interesting ideas going on, though ultimately i didnt end up using it (i need my persistent datastructures and seq col abstractions)
It feels very minimal and scheme-y and very different from anything ive used before. Definitely worth exploring
phtrivier 1 days ago [-]
How much does this overlap / complements something like jank ? [1]
How much "production ready" / "battle tested" would this be ?
(Not to start a flame war, I'm genuinely curious about the differences.)
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.
phtrivier 24 hours ago [-]
Thanks, and thanks for the effort on jank !
Since you're here ;) : I read on the alpha doc that protocols and other part of the clojure object model are not done yet - is your goal to include them eventually, or is there a part of the lore of clojure that makes them not indispensable ?
Jeaye 23 hours ago [-]
Protocols, records, and the like will be implemented in jank. They haven't been prioritized for two reasons.
Over the past few years, I've been spending hammock time to find a solution to this to re-open the object model efficiently. I came up with a design this year which addresses the concerns raised in that blog post and opens up the object model, but jank today is still in a half-way state between the two systems.
Secondly, in the several years I've written Clojure professionally, I don't recall ever writing my own protocol, record, or struct. When I was first learning Clojure, I leaned on them more heavily, since I was coming from OOP land. But once I leaned into the pure Clojure data designs, the OOP side of things just stopped mattering. So, if I were to write just about anything in jank, I wouldn't intend on using these features. That alone has made them low priority for me.
But they'll be implemented. :) I'd estimate Q1 next year for me to tackle those.
yogthos 6 hours ago [-]
Prtotocols tend to be useful for the same reason as Java interfaces. For example, Ring uses a protocol to specify the contract for the adapter. So, then you can just implement it and seamlessly drop in wrapper Jetty or Undertow or whatever. https://github.com/ring-clojure/ring/tree/master/ring-core-p...
didibus 16 hours ago [-]
Jank is Clojure hosted on C++/LLVM, and Jolt is Clojure hosted on Chez Scheme.
Jank compiles to C++, C/C++ interrop is direct, you just import and use any C/C++ library directly as if you were coding in C/C++. There's no FFI, it feels the same as how you use Java from ClojureJVM.
Jolt compiles to Scheme, but doesn't yet have Scheme interrop, though it is planned. Scheme doesn't have a large ecosystem of libraries. So Jolt is almost more of a "pure Clojure" runtime. It mostly relies on using other Clojure libraries, and provides a subset of Java for common I/O and threading ops that you'd use interrop for in ClojureJVM to get most commonly used Clojure libs working (ring, reitit, integrant, malli, hiccup, etc.)
Jolt has a C FFI, but it's not very convenient, you have to declare each C function yourself, manually manage type conversions, memory, etc.
They can both take your Clojure code and make a compiled native single binary out of it. Jank also plans to allow Jank programs to be compiled into static or shared libraries such as .so files, so they can be embedded in or depended on from C++ and other native applications.
yogthos 6 hours ago [-]
Jolt actually does have both Scheme interop and FFI
and it is possible to make .so libraries with Jolt as well right now
yogthos 1 days ago [-]
I have a slightly different goal from Jank because my goal is to provide a runtime that supports existing Clojure libraries. I've spent the time to map out Java standard library APIs that popular libraries use and to create shims on top of Chez that allows them to run seamlessly. You can see a list of libraries that are fully tested and officially supported here. https://jolt-lang.github.io/docs/libraries.html
On top of that, I expose the API for creating shims in user space, so people can easily add their own for the libraries they want to use that might not be covered in the core. And I leverage this functionality myself to create libraries for JDBC layer or crypto that rely on doing FFI to shared system libraries that aren't part of the core runtime.
In terms of how production ready Jolt is, it's still fairly new obviously, so there will inevitably be bugs. However, it already passes full https://github.com/jank-lang/clojure-test-suite from Jank, and has its own conformance corpus https://github.com/jolt-lang/jolt/blob/main/test/chez/corpus... which is a superset of that. On top of that, I'm now able to run original test suites for the libraries I support and compare them with JVM outputs to ensure there aren't unintended divergences.
The other side of it is the benchmark harness which I use to ensure performance stays reasonably close to the JVM, in most cases it's within 1.x, and the worst case is around 6x right now. https://github.com/jolt-lang/jolt/tree/main/bench
So, Jolt basically aims to be a drop in JVM replacement for running existing Clojure code.
adz5a 7 hours ago [-]
But isn't it kind of a one way street? We can extract clojure code from the JVM but then we cannot use its ecosystem anymore, which kinda feels like a los.
Since we can use (n)REPL in all ecosystems (jvm, browser, node etc...), could we use it or a variation to have interop?
yogthos 6 hours ago [-]
It's not like JVM Clojure is going away, we just have a bigger toolbox now.
nucleogenesis 1 days ago [-]
What a wonderful excuse to dive back into Clojure! This looks fantastic. I wonder what neat stuff might be made in Clojure thanks to a C FFI that wasn’t doable on top of the JVM.
pjmlp 1 days ago [-]
Note that nowadays with Panama, there are more FFI opportunities in JVM implementations as well.
Although it is rather verbose, and it is easier to have a C header and run jextract on it, instead of the manual boilerplate.
Using FFI/FFM "vanilla" with java interop is also viable, and in my experience the SOTA models do just fine with it (with or without jextract).
pjmlp 1 days ago [-]
Great overview, thanks!
busterarm 1 days ago [-]
I've been diving back into Clojure just recently and this will be something I'll be trying to use immediatley.
JerboaScheme 5 hours ago [-]
Chez Scheme is highly underrated! Jolt is amazing work.
I also have been using it for Jerboa, a Gerbil Scheme compatible language.
https://jerboa.sh
8,820,174 lines of 100% vibe coded code.
nemoniac 8 hours ago [-]
Does it have tail-call optimization? I scanned the docs but don't see it mentioned.
Presumably basing Jolt on Chez removes the limitation of the JVM? It could be an interesting selling point.
yogthos 6 hours ago [-]
Yup, Jolt has TCO inherited from Scheme
pjmlp 1 days ago [-]
Nice to see further adoption from Chez Scheme.
Have to give it a try.
kccqzy 1 days ago [-]
I understand some don’t like having a JVM, but for running in the browser, what does Jolt on Gambit offer over plain ClojureScript?
yogthos 1 days ago [-]
Oh I would definitely recommend ClojureScript or Squint for running in the browser. Using Gambit to compile to Js was really just an illustration of how Jolt has a portable layer that can be compiled to a completely different Scheme backend. I don't really intend to compete with the existing frontend solutions because you really want to keep your dialect as light as possible to minimize the size and friction with the existing Js ecosystem.
yogthos 1 days ago [-]
Author here, glad to answer any questions about Jolt.
micro2588 1 days ago [-]
Awesome work, have you looked into using Racket's fork of Chez? It supports some additional extensions and architectures from base Chez that would seem to beneficial as a compiler target, at least that was the case a couple years ago.
yogthos 1 days ago [-]
Thanks, and I have good news on that front actually. I recently factored out a portable Scheme layer and got Jolt to compile against Gambit as a backend. And given that Racket is basically an extension of Chez, it should be trivial to build against it now.
Really cool, I see now that most all the the Racket extensions to Chez have been up-streamed which is positive for the health of both projects.
yogthos 1 days ago [-]
Indeed, it's a nice ecosystem to be part of. :)
iainctduncan 1 days ago [-]
Congrats, this is awesome! I have followed your writing and have your book, so was excited to see this was you.
I have one question, can one drop into Scheme the way one can call Java in clojure, or is one totally firewalled from the underlying Scheme implementation?
Great to see Gambit getting love too. Gambit and Chez are amazing achievements.
yogthos 1 days ago [-]
Hi, thanks, glad to hear you enjoy my other work! :)
And yes, you absolutely can drop both down to Scheme and do FFI to drive native libs as well
I actually leverage this myself in libraries, I ended up writing a Java time layer to support tick here, and I decided to make it a library since I wanted the core executable to stay self contained, and Chez doesn't provide timezone handling natively. So, time pulls in a shared system library and shims a Java style API over it that tick can use
Definitely excited with the progress so far. It's obviously still very fresh, and there are likely bugs and quirks abound, but I find it's already quite usable for my own personal projects.
saityi 23 hours ago [-]
It's neat!
How does this fit into the ecosystem compared to something like Babashka?
I tried running a cross-platform (JVM, CLR, JS) Clojure project I'm working on, but it failed trying to load the JVM's `System/in`. Does Jolt handle reader conditionals? Is the intention for it to always follow the `:clj` branch or are you planning a `:cljolt` or something?
saityi 20 hours ago [-]
I was able to fix the System/in issue (I didn't actually need that, just *in*) and load it with jolt. This is quite neat! I see now it just follows all of the `:clj` conditionals and covers everything you'd need.
yogthos 20 hours ago [-]
Glad you got it working, and yeah it is just standard reader conditionals. I've also look for .jolt files which get preference over .clj, so it's possible to add Jolt specific behavior which overrides existing behavior in a library.
And it's a bit different from Babashka in providing easy access to Scheme and native libraries. And the code compiles to a standalone native binary. So, you can make a native GTK app for example.
The other big difference is performance. Babashka is an interpreter, but Jolt compiles the code. So, performance is close to the JVM in most cases.
mark_l_watson 4 days ago [-]
I just saw this - works great to build small self contained apps. (I just tested on macOS, also supports Linux).
mark_l_watson 4 days ago [-]
Clojure hosted on Chez Scheme (same as Racket). So cool. I tried building a standalone executable for the Chess game in my Clojure book using "jolt build -m chess-game.cli -o chess_jolt" and it simply worked great.
I tried again with a datomic demo and it needed the source code to the open source version of datomic, so I need to do some work on that.
eggy 1 days ago [-]
Curious about the executable size and performance. Mark, you started me on AI with your, "Common LISP Modules: Artificial Intelligence in the Era of Neural Networks and Chaos Theory". I have never been able to fully leave Lisp behind. I'll have to try this on my linux box. What's your take on using jolt practically for work vs. learning? Thanks!
mark_l_watson 22 hours ago [-]
Thanks for the kind words.
I just built the Chess example in my Clojure book and the executable was a tiny 18M.
eggy 18 hours ago [-]
Thank you! How about performance? Do you see Jolt evolving into something more useable for real work, or is it too niche and not capable enough? I always loved Racket. How does Jolt compare? I'll give it a try this weekend.
1 days ago [-]
tosh 1 days ago [-]
it's good to have even more (and more slim!) ways to run Clojure
(not just JVM and JavaScript runtimes)
pmkary 1 days ago [-]
How many years have it been there? My memory reminds me of Jolt but I very hardly remember what was it, all I remember is that it was a LISP.
taolson 1 days ago [-]
You're probably thinking of Ian Piumarta's COLA project (Combined Object Lambda Architecture), which had parts named after cola soft-drinks (Coke was a lisp-like language, Pepsi was a Smalltalk-like language, and Jolt was an early implementation of Coke):
What does this have to do with Jolt, the Clojure compiler other than in name? Is there a port to Clojure or other connection?
Ohentis 1 days ago [-]
I think the name being the same is worth bringing up. Ideally you would avoid name collisions with big projects but admittedly it does happen all the time.
eggy 18 hours ago [-]
Yes, and people seem to leave context out of it nowadays, which usually makes it a moot point. When searching I would put "Jolt Chez" or "Jolt Clojure" to get relevant hits. There is a Jolt energy drink too, popular among techies, or it was...
pjmlp 1 days ago [-]
There are other collisions, like Jolt computer, Dr Dobbs Jolt awards.
However to be fair, none of it came to mind when I saw the title.
I don’t know how to get a feeling about the actual state of projects like this anymore, so I always remain a bit suspicious. In Clojure, there is the (Rich Hickey inspired) design philosophy of “hammock driven development”, where we don’t rush things, let them simmer while lying in the hammock, sleeping on them, taking a walk, etc. Makes me wonder if projects like this are too rushed these days without thinking things through, discussing design decisions and getting ideas from other people, letting them mature over time. This isn’t specifically about Jolt (I don’t know much about it or its creator), it just inspired the thought, especially when comparing it to projects like Jank which has been years in development, with lots of feedback from the community and Clojure core maintainers as input.
The guy literally has published book(s) on Clojure - not some random, unknown, AI-wielding teenager from somewhere in Nebraska. I'm pretty sure they know what they're doing.
But of course, nothing is wrong with being suspicious about any new projects these days. Overall, I agree with your sentiment here.
Once I had the basics bootstrapped, it was really a matter of getting tests passing, and then getting more and more libraries to run on it which allowed me to exercise their own tests. And that's what really made the whole thing possible. It's sort of the ideal scenario where you have very well specified inputs and outputs, and a ton of existing tests to ensure you are implementing the behaviors correctly.
The only other aspect here is performance, and that's addressed by having an extensive benchmark harness which compares with JVM timings. This allows me to see where performance gaps are, and focus on addressing them.
I would be careful in extending my experience of being able to port Clojure to Chez Scheme runtime to working with LLMs in general because in most cases you don't have such well defined parameters when you start.
I love the expression "the hammock time has already been spent": it is actually very accurate and I'm very grateful to the Clojure team and community for spending that time!
However, you're right to point out that the development is moving really fast.
I'm building a Clojure compiler for machine learning (https://github.com/sheaf-lang/sheaf), and after 9 months, it's still very far from being production-ready.
If a dev is competent and has enough experience actually writing code and making good design decisions, I see no reason to judge their work on the basis of what tools they used to get the job done. However, it may still put me off, since I find it hard to value LLM-written code the same way I value human-written code, even though it may be equally good or even better in quality.
What would you call 2k commits in 2 months by a single committer if not slop?
I don't think "2k commits in 2 months" is enough to dismiss as slop when it's being developed by a competent Clojure dev.
One very quick "slop or not?" test is to see if em dashes are used in the source code where they literally never make sense. It's not a great test, but it's one that consistently turns out to be good enough. The results should speak for themselves: https://github.com/search?q=repo%3Ajolt-lang%2Fjolt+%E2%80%9...
If you have specific comments about the quality of the code then I'd be happy to discuss that. Attacking other people's work because they used tools you don't understand is just toxic trolling. And the fact that you judge code quality by the number of em dashes in the comments really speaks volumes.
Maybe spend a bit of time figuring out how to use new tools effectively instead of harping on what other people are doing.
It's very telling that whenever somebody starts braying about slop, they never have anything of substance to say. All the noise you add to discussions people are trying to have is the real slop.
But in my case I think there are levels. In this case, the author has the expertise needed to properly design the work and assess the quality of the output. And it seems they intend to maintain and evolve the library actively and long term.
Would I prefer a serious Clojure on chez that's all hand-written, for sure, but beggars can't be choosers.
> What would you call 2k commits in 2 months by a single committer if not slop?
Productivity. Slop is when you push a huge volume of garbage or mediocre stuff, no?
All you're doing here is exposing the fact that you have no clue how these tools actually work, or how to use them effectively.
The caveat is that this isn't typical AI slop. The author knows the subject deeply, designed the system themselves, has extensive Clojure test suites to validate against, and has basically been working on it 24/7.
Can you trust it like a compiler someone spent 7 years writing and knows line by line? Probably not. But it's closer to alpha software than useless slop. As more people use it, we'll find out how robust it is, and whatever issues exist can be fixed as they're found.
So ya, I agree you shouldn't be asked to review AI generated code the author didn't review themselves. I think the ask here is more to try it and see how complete and robust it actually is. And even that only makes sense because the author is a known expert who appears to be steering the model carefully.
Au contraire - if anything, we should talk about LLMs more and we should find more ways to democratize this technology. Silencing and scolding people won't help fight OpenAI and Anthropic's hegemony.
Have you ever, kids, tried building anything useful? Anything practical, anything that actually works, anything beneficent? With or without AI?
Well, if you have in fact ever tried, perhaps you'd know that building reasonably complex software remains a difficult, challenging, unappreciated work. With or without the help of any tooling. AI-assistants included.
Maybe try building something good first. Earn your right to throw the first stone, come engaged, come prepared, ask questions.
What you're doing is a fucking slop. Human slop of ignorance. Worst kind.
edit: Yup, found a very long blog post that says it's made with LLMs near the end https://yogthos.net/posts/2026-07-02-jolt.html
https://janet-lang.org/
It has a lot of very interesting ideas going on, though ultimately i didnt end up using it (i need my persistent datastructures and seq col abstractions)
It feels very minimal and scheme-y and very different from anything ive used before. Definitely worth exploring
How much "production ready" / "battle tested" would this be ?
(Not to start a flame war, I'm genuinely curious about the differences.)
[1] https://github.com/jank-lang/jank
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.
Since you're here ;) : I read on the alpha doc that protocols and other part of the clojure object model are not done yet - is your goal to include them eventually, or is there a part of the lore of clojure that makes them not indispensable ?
Firstly, historically, jank had a closed object model for performance, which I have blogged about here: https://jank-lang.org/blog/2023-07-08-object-model/
Over the past few years, I've been spending hammock time to find a solution to this to re-open the object model efficiently. I came up with a design this year which addresses the concerns raised in that blog post and opens up the object model, but jank today is still in a half-way state between the two systems.
Secondly, in the several years I've written Clojure professionally, I don't recall ever writing my own protocol, record, or struct. When I was first learning Clojure, I leaned on them more heavily, since I was coming from OOP land. But once I leaned into the pure Clojure data designs, the OOP side of things just stopped mattering. So, if I were to write just about anything in jank, I wouldn't intend on using these features. That alone has made them low priority for me.
But they'll be implemented. :) I'd estimate Q1 next year for me to tackle those.
Jank compiles to C++, C/C++ interrop is direct, you just import and use any C/C++ library directly as if you were coding in C/C++. There's no FFI, it feels the same as how you use Java from ClojureJVM.
Jolt compiles to Scheme, but doesn't yet have Scheme interrop, though it is planned. Scheme doesn't have a large ecosystem of libraries. So Jolt is almost more of a "pure Clojure" runtime. It mostly relies on using other Clojure libraries, and provides a subset of Java for common I/O and threading ops that you'd use interrop for in ClojureJVM to get most commonly used Clojure libs working (ring, reitit, integrant, malli, hiccup, etc.)
Jolt has a C FFI, but it's not very convenient, you have to declare each C function yourself, manually manage type conversions, memory, etc.
They can both take your Clojure code and make a compiled native single binary out of it. Jank also plans to allow Jank programs to be compiled into static or shared libraries such as .so files, so they can be embedded in or depended on from C++ and other native applications.
https://jolt-lang.net/docs/host-interop.html
and it is possible to make .so libraries with Jolt as well right now
On top of that, I expose the API for creating shims in user space, so people can easily add their own for the libraries they want to use that might not be covered in the core. And I leverage this functionality myself to create libraries for JDBC layer or crypto that rely on doing FFI to shared system libraries that aren't part of the core runtime.
In terms of how production ready Jolt is, it's still fairly new obviously, so there will inevitably be bugs. However, it already passes full https://github.com/jank-lang/clojure-test-suite from Jank, and has its own conformance corpus https://github.com/jolt-lang/jolt/blob/main/test/chez/corpus... which is a superset of that. On top of that, I'm now able to run original test suites for the libraries I support and compare them with JVM outputs to ensure there aren't unintended divergences.
The other side of it is the benchmark harness which I use to ensure performance stays reasonably close to the JVM, in most cases it's within 1.x, and the worst case is around 6x right now. https://github.com/jolt-lang/jolt/tree/main/bench
So, Jolt basically aims to be a drop in JVM replacement for running existing Clojure code.
Although it is rather verbose, and it is easier to have a C header and run jextract on it, instead of the manual boilerplate.
No idea how well AI tooling would manage.
For example look at this arc from sqlite4clj https://github.com/andersmurphy/sqlite4clj/blob/master/src/s... it's very elegant.
(Also can plug my own libvips wrapper using coffi https://github.com/outskirtslabs/vips)
Using FFI/FFM "vanilla" with java interop is also viable, and in my experience the SOTA models do just fine with it (with or without jextract).
Presumably basing Jolt on Chez removes the limitation of the JVM? It could be an interesting selling point.
Have to give it a try.
I wrote up a post on how this works here https://yogthos.net/posts/2026-08-07-portable-jolt.html
I have one question, can one drop into Scheme the way one can call Java in clojure, or is one totally firewalled from the underlying Scheme implementation?
Great to see Gambit getting love too. Gambit and Chez are amazing achievements.
And yes, you absolutely can drop both down to Scheme and do FFI to drive native libs as well
https://jolt-lang.github.io/docs/host-interop.html
https://jolt-lang.github.io/docs/native-interop.html
I actually leverage this myself in libraries, I ended up writing a Java time layer to support tick here, and I decided to make it a library since I wanted the core executable to stay self contained, and Chez doesn't provide timezone handling natively. So, time pulls in a shared system library and shims a Java style API over it that tick can use
https://github.com/jolt-lang/time
And I'm doing FFI in Glimmer to provide a Reagent style reactive library on top of GTK
https://github.com/jolt-lang/glimmer
It ended up working pretty well for a project here https://github.com/yogthos/splat-painter
Definitely excited with the progress so far. It's obviously still very fresh, and there are likely bugs and quirks abound, but I find it's already quite usable for my own personal projects.
How does this fit into the ecosystem compared to something like Babashka?
I tried running a cross-platform (JVM, CLR, JS) Clojure project I'm working on, but it failed trying to load the JVM's `System/in`. Does Jolt handle reader conditionals? Is the intention for it to always follow the `:clj` branch or are you planning a `:cljolt` or something?
And it's a bit different from Babashka in providing easy access to Scheme and native libraries. And the code compiles to a standalone native binary. So, you can make a native GTK app for example.
The other big difference is performance. Babashka is an interpreter, but Jolt compiles the code. So, performance is close to the JVM in most cases.
I tried again with a datomic demo and it needed the source code to the open source version of datomic, so I need to do some work on that.
I just built the Chess example in my Clojure book and the executable was a tiny 18M.
(not just JVM and JavaScript runtimes)
https://www.piumarta.com/software/cola/
https://github.com/nooga/let-go
Fun fact. It also runs on plan9:
https://github.com/nooga/legmacs/issues/1
However to be fair, none of it came to mind when I saw the title.