uaksom

You're missing the point: LLMs are dangerous in the wrong hands, i.e., the frontier labs. They have shown zero desire to act responsibly.

Changing core features every few months doesn't seem very consistent...

It does seem like they're trying to convince themselves. If you like Zig, that's a good enough reason to use it. Why waste time on language tribalism?

I have the same issue with "use the right tool" rhetoric. The right tool is the one that does the job and that you know best.

> I invite you to read the release notes and see for yourself the types of breaking changes we’re talking about.

I did, and I immediately found this in the latest release: https://ziglang.org/download/0.16.0/release-notes.html#IO-as...

That seems like it would require changing a lot of code. Calling it "production ready" is dishonest at best

Earendil did! https://lucumr.pocoo.org/2026/5/24/pi-oss/

(author here) If you run the parser under a debugger like lldb, then attempt to inspect the AST of a program, it appears as an array of u64. Not very useful, unless you work on special support for debuggers (such as a python script to unpack it in lldb). Compare that to a tree of pointers, you can "expand" nodes without any extra effort.

(author here) I agree that it's a lot of complexity, and I acknowledge this in the article: You can get quite far with just a bump allocator.

I didn't go into this at all, but the main benefit of this design is how well it interacts with CPU cache. This has almost no effect on the parser, because you're typically just writing the AST, not reading it. I believe that subsequent stages benefit much more from faster traversal.

(By the way, I am a huge fan of your work. Crafting interpreters was my introduction to programming languages!)

Using data races: https://www.ralfj.de/blog/2025/07/24/memory-safety.html

Thanks for the shoutout!

We did recently add an export for LLMs[1], but weren't quite confident in how the big models handled it. The biggest issue we kept running into was that it would prefer using older APIs over the latest ones. I tested it just now with ChatGPT, and it seems to be doing a lot better! The export is kept up-to-date with the latest contents of our docs, which update every release. Sometimes a bit more frequently, if we're doing drive-by doc fixes.

For convenience, here's a GPT pre-loaded with the file: https://chatgpt.com/g/g-674702fde5948191a810bdf73370b6eb-rer...

[1]: https://rerun.io/llms.txt

They don't, at least not yet. https://github.com/lunatic-solutions/lunatic/issues/150

It is WebAssembly based though, so it should be easier than trying to deal with dynamic libraries and Rust's ABI.

GC gives you a nice cushion, because it makes allocations fast. However, with a little bit of thought put into memory allocation (such as using arenas with bump allocation), you'd easily beat Go with Rust. The author of SWC did exactly that https://swc.rs/docs/benchmarks