The borrow checker will catch all kinds of bugs that AI-generated code will happily compile in Zig but will blow up as UB at runtime.
Zig's value prop is different and closer to a modern C: it fits in your head and maps fairly closely to assembly. There is no hidden control flow or hidden allocations, so you can tweak performance at a very low level. You're the pilot, not the compiler.
Rust trades the low-level clarity for compiler-enforced safety. If you're not a code artisan or don't care about being one, then please use Rust.
> The borrow checker will catch all kinds of bugs that AI-generated code will happily compile in Zig but will blow up as UB at runtime.
This has not been my experience; Claude does a great job of writing unit tests for the Zig code, and combined with Zig's fuzzing features and a Python-based integration testing suite, I have avoided hitting runtime UB so far. In exchange, I get much faster compile times, which are important for the agentic development loop.
LLMs are actually pretty good at finding potential memory corruption issues in unsafe langauges upfront, to a point where I wonder if it even still makes sense using Rust with its slow compile-edit-test loop in a fully automated code generation scenario.
Part of the reason the compile-edit-test loop is slower than in other languages is because Rust is doing a whole borrow checking phase other languages don't. I don't see why it'd be faster or more accurate to get an LLM to do the same static analysis as the Rust compiler. Although I'd be interested in an analysis of how much each would cost in dollars.
And the difference is more useful in the more common scenario of editing code and checking it. Though those days, language servers like rust-analyzer do essentially replace cargo check.
Taking the alacritty project and modifying the source files to pretend something happened:
I’ve shipped games written entirely in assembly. I now work on a large service you have heard of. I graduated manga cum laude. I’m not smart enough to write systems in C or Zig that don’t have bugs.
The question I ask myself is “would I write a game in Rust?” Zig seems like a better fit: you can be clever without being chided by the borrow checker. But as a “code artisan”, there’s an interesting challenge in making it work with Rust.
I might use Zig on a project if it was just me. I wouldn’t use it with the a team that I didn’t hand pick.
Smart people like Zig. Smart people like Rust. Smart people like LLMs. It’s a big Venn diagram. It be great if we could not bash each other.
So far claude has been fine to generated zig code. Dont have lots of issues. Tijy local models have more problems with zig, need additional instructions.
In general, what helps is to instruct ai to use test coverage to ensure the cover all edge cases with tests.
Can LLMs not write Zig code ? I'm not really understanding your explanation for why we can write other languages with LLM but not Zig here.
> Rust trades the low-level clarity for compiler-enforced safety. If you're not a code artisan or don't care about being one, then please use Rust.
Not really seeing the connection here. What do you mean by code artisan? Are you trying to gatekeep Zig because you think Zig is too difficult for LLMs?
You asked if there was "tangible benefit to end user or developer using ai assisted development". My answer is no, it can be done but has no benefits for this use case. Use Rust here, because its compiler acts as an AI safety net.
Being a code artisan is not gatekeeping. It means if you're used to being close to the metal and sometimes know better than the compiler, Zig is for you. If you're not, use Rust.
Nobody's writing Zig because they think they can beat the Rust compiler.
Comparisons to Rust usually stop at memory safety and overlook what no-hidden-control-flow buys you when it's applied consistently across the whole language.
The same mechanism that lets you control allocation (passing an allocator) extends to I/O. For instance, writing Zig, I know exactly when I'm handing control to the kernel and when I'm not. In the vast majority of languages, it's something you'd observe at runtime, whereas in Zig, it's simply the source code you compiled.
So the point of writing Zig over any other language isn't beating the compiler, it's understanding and controlling what your program does at any given moment.
With all due respect, that tickles my spidey senses. People claiming to know better than a compiler about low-level details of their code are most often either engaging in premature hyper-optimisation, or suffer a specific kind of greybeard hubris IMHO
The idea that humans can't solve a specific problem more efficiently than a generalised algorithm that has to work for all code ever written in the language is a lie that JS script kiddies tell themselves to justify remaining ignorant without feeling bad about it.
Sometimes, but measure the number of people like that against the massive number of people who blow their whole leg off by trying to second-guess the compiler. If I had a nickel for every “performance critical” (which it never is) weird bullshit thing I’ve seen people do to “defeat” (really: totally misunderstand) a compiler behavior, which instead resulted in severe bugs, I’d have a lot of nickels.
The overlap of situations where compiler-second-guessing truly being necessary and the programmers present are capable enough to implement it is narrow enough that I’m fine with most languages’ escape hatches being similarly narrow.
I mean, using Rust or Zig rather than typescript, go, Java or C# is often a premature optimization, depending on use case. Plenty of games where majority of code is C# or unrealscript. Most people I talk to are surprised that Java has monomorphisation at runtime.
Oh, humans can definitely do that, in some capacity, if they're attentive, slept enough, aren't hungry, or in emotional distress, for a limited amount of time.
A generalised algorithm can do this consistently, billions of times, which happens to be the amount of problems involved in building an application.
Which is why we don't write entire programs in raw assembly, but that doesn't mean it's actually difficult to do better than a compiler. You focus your efforts on where benchmarking and profiling tell you your bottlenecks are in your hot paths. If you actually engage in this in a regular basis, you will recognise that despite the myth-building and fear around writing low-level code, compilers do "stupid" inefficient stuff all the time, and it's not hard to do better than them with the specific context of your project in mind.
This reads as rather dismissive and not so humble. Compilers generating suboptimal and sometimes broken code very slowly is the norm, not the exception. Whether or not it's worth worrying about is indeed a development tradeoff but not one that should be so casually dismissed.
> Being a code artisan is not gatekeeping. It means if you're used to being close to the metal and often know better than the compiler, Zig is for you. If you're not, use Rust.
You are saying that if you are not a code artisan (who by definition can't use LLM) likeyou then they should not use Zig. Honestly, I don't care. I'm not a code artisan, if Zig can help me ship faster and better with LLMs, my job is done and that's what I get paid for.
> Codex CLI taking over 15 minutes to recompile on my fairly high-end machine. Zig's incremental compilation optimizations are amazing, giving near-instant recompiles measured in ms instead of minutes.
So there is a benefit here mentioned by the non-arisans which is what I wanted to know but you wouldn't know if you don't use ai assisted delivery.
> A modern compiler will try to autovectorize your code, so you don't really know what the assembly will be.
Looking at what the compiler actually did is an ancient tradition. I’ve even done it with Java. Seeing five virtual calls with bounds checking all over get turned into a single load instruction has to be seen to be believed.
it's also my opinion. Which makes me wonder : isn't there an opportunity to create a variant of rust that would make absolutely zero compromise on UB and safety at the detriment of user experience ( which we don't care about now, with AI generating the code) ?
Like programming in a kind of super strict IL. Or the opposite : super poweful, super abstract language, yet extremely strict.
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.
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.
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.
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.
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.
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...
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.
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.
I am almost certain that, on a daily basis, you use dozens (or hundreds) of things that:
1. Were produced via plastic injection molding.
2. Were machined by CNC.
3. Have PCBs that were fabricated by machine, milled by machine, and populated via pick-and-place machine.
4. Were laser engraved, or silk screened, or printed.
5. For food/foodstuffs: were processed in an automated factory.
When you use all of these things, do you complain about using/consuming something that someone "couldn't be bothered to hand craft"?
If you don't see/anticipate the utility in a thing (like I don't have any interest in wicker baskets, hand crafted or not), why complain about that thing, instead of just moving along? I'd get it if you wanted to provide constructive feedback, but you can't do that if you're not willing to read the code.
Harboring (and expressing) negative sentiment for things that you opt to not be involved in sounds like a recipe for misery, as there's an infinite number of things to actively dislike if you go looking for them: movies/music that aren't to your tastes, mediocre restaurants, cities you wouldn't want to live in, etc.
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.
It makes me wonder if these same people take issue with task delegation in software development: is it also problematic when a staff engineer delegates tasks across teams, or a senior engineer mentors a junior developer?
It's such a stifling, self-limiting belief that it's actually saddening :(.
It's also a hypocritical belief: the machine they used to type out these thoughts were assembled in a factory, using CNC, pick-and-place, laser engraving, plastic injection molding, etc. With the exception of a few things (ex: the silicon itself) all of these things could be hand crafted - it would just make the price of computer impractical. Commoditization is a good thing, and automation is necessary for that.
I can only imagine that what is actually happening is that these people are attached to the craft of software development, and AI represents a threat to that, just as CNC milling has displaced manual machinists. But then everyone would be better off if they found an appropriate place to vent that frustration (a therapist? a friend? like-minded forum dedicated to AI complaints?), rather than projecting onto (and leveling complaints at) people using AI.
If said staff engineer would then claim junior’s work as his own, then yes. But for an entirely different reason, as well as this whole analogy doesn’t work here.
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.
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.
'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.
Four day old repo with 92K lines added per day, okay...
There is basically no evidence of human competence in this repo. This is yet another "rewrite in Rust with Claude" project that brings nothing to the table, but devalues expert work by mimicking competence without the expertise.
This was common back then. The PDP-8 had eight primary instructions, although one of them was multi-purpose. This helped keep the hardware simple when we didn't have ICs.
RISC isn't about having a small ISA but about a regular, orthogonal instruction set.
I was initially surprised because this is not a good use case for Scheme. The current C implementation is clean and efficient, and I'd rather use Scheme to replace some messy Python code with its dependency hell.
And then I saw this: "As mentioned above, some code has been automatically translated from C to Scheme, using generative AI. This is not creative work, and as such, the authors of Goodev cannot claim copyright for it."
Somehow I wish those tokens would had been more usefully spent on porting code where a sound language could actually make a difference.
Not very far off, the IBM 1130 was very much built around its punch-card reader.
I've written a backprop in Fortran IV for the 1130 and while it works, it was tedious.
Add ten more years, and the IBM 801 could have been a CPU architecture good enough to scale all the way to the present day without emulation, unlike the 360.
The Linux VM host and guest components are all custom, as well as the daemon that manages machines. It currently uses LXC as the runtime but that's being replaced as well. For containers we run a standard Docker engine inside a special machine.
In the early days of machine learning (before the first AI winter), networks like this were often implemented and trained in hardware: https://en.wikipedia.org/wiki/ADALINE
That was the first thing that came to mind when I read "the smallest brain you can build". Nowadays, that "small brain" would likely be built on a breadboard using op-amps instead.
Amazing and anachronistic to see something like that from 1960. And then it makes me wonder why there wasn't more progress on neural nets being used for many things prior to the 21st century. (I haven't read the history of the AI winters but I have heard of them)
The first AI winter was largely triggered by Minsky in a book he published in 1969, which mathematically proved that single-layer perceptrons couldn't solve non-linear problems. Favorite quote: "Our intuitive judgment is that the extension [to multilayer systems] is sterile."
Yet we had the computational power to run backpropagation in the 1960s and small Transformers in the 1970s (I'm the author of both):
What was missing wasn't the raw processing power, but the ideas and algorithms themselves. Because funding and research were completely discouraged during the AI winter, neural networks research was left dormant and we lost two decades.
I wonder had we invented transformer architecture back in the 70's or 80's, if the pace of hardware innovation would have naturally slowed AI progression, and given humans decades to slowly adapt, rather than the current tidal wave (that seems to grow in size daily) bearing down on us.
> why there wasn't more progress on neural nets being used for many things prior to the 21st century
They were simply too computationally expensive to train for the limited things they could do. It wasn’t until we had the ability to train large neural networks on commodity hardware that things really took off.
The quasi-mythical memristor would be choice for bread boarding a brain. However I suppose you could train a model and then manually place fixed resistors to build the network
The borrow checker will catch all kinds of bugs that AI-generated code will happily compile in Zig but will blow up as UB at runtime.
Zig's value prop is different and closer to a modern C: it fits in your head and maps fairly closely to assembly. There is no hidden control flow or hidden allocations, so you can tweak performance at a very low level. You're the pilot, not the compiler.
Rust trades the low-level clarity for compiler-enforced safety. If you're not a code artisan or don't care about being one, then please use Rust.