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.

(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!)