Remix.run Logo
nesarkvechnep 7 hours ago

Development of Zig feels so wholesome.

SwellJoe 6 hours ago | parent | next [-]

The thing about Zig in these times is that it proves that software development as a craft is not dead or replaced by LLMs.

Even though I use LLMs every day, and have to admit they're remarkably good at many classes of problem, I don't want a programming language built by an LLM. Every line of code in a programming language, every decision, every trade off, matters. A vibe-designed/vibe-coded programming language would be a disaster. I don't know how else to put it, and I've never seen any model produce code that would convince me otherwise (even Fable, which is, in fact, a notable improvement over the prior best models). The models don't want anything. They don't have meaningful opinions. They don't know what comfortable vs. uncomfortable feels like in a language (or in a GUI or CLI interface at sufficient levels of complexity).

You can't get a language like Zig out of an LLM without simply copying Zig, and even then it would be a copy that is worse. (I mean, I'm assuming "copy with an LLM" means, "have an LLM write the spec and another build the language to the spec", not literally `cp` the source tree.)

ChrisGreenHeur 6 hours ago | parent [-]

Sure a human would write the language spec and the llm implement it

SwellJoe 4 hours ago | parent | next [-]

I think this makes two incorrect assumptions:

1. That a human, even a brilliant human with a lot of experience, can sit down and one-shot a language spec for a new language that is actually good.

2. That an agent can produce code that is good enough for a programming language that intends to last for decades without exhaustive human review.

We might advance to the point where 2 is true, we're not there yet. We'll never make a better human that can one-shot a good programming language. It takes iteration, with a human in the loop. Zig has taken ten years to get to this point, and is still occasionally experiencing major refactors.

If you want to argue an LLM could potentially accelerate development by some amount, I would agree with you. How much it could accelerate it is debatable. And, I understand why the Zig folks have decided not to accelerate in that way. There is a cost to it. You lose the junior programmer pipeline, as your "good first bug" list gets chewed up by people using LLMs. You still have to exhaustively review the code for a critical path like a compiler and AI code is hard to review; it doesn't have a point to it. The model doesn't want anything, so it's not always clear where it's going. Code without clear intention, like prose without clear intention, is hard to read and hard to review. It's verbose and often makes weird assumptions.

If I, for some reason, needed to implement a tiny DSL for something, I would 100% do it with an LLM. If I, for some reason, were tasked with building the best programming language to replace C, I would not hand it to an LLM (though I would get help from an LLM, because I don't know how to build a programming language beyond the tiniest toy interpreter or compiler, I'd need to read and understand every line of code, and use it daily, for it to turn out good).

linguae 24 minutes ago | parent | prev | next [-]

I’ve been thinking about this over the past few days. There was an exciting keynote at PLDI 2026 by MIT professor Saman Amarasinghe where he talked about the intersection between compilers and machine learning, including LLMs. One of the works discussed during the keynote was the use of Claude Code by his colleague Martin Rinard to implement a compiler known as a credible compiler that outputs both compiled code and a proof that the output code correctly matches the input.

https://youtu.be/Fc3cW0nqAQ0

hansvm 4 hours ago | parent | prev | next [-]

For complicated problems, you can't just write the language spec. You need to iteratively develop it, which itself requires some intermediate state/language describing what you know so far. That intermediate state being the end programming language in consideration isn't mandatory per se, but iteratively refining, replacing, and reworking solutions using code as a drafting board is very common in the industry. That's doubly true for languages, where the social pressures in how it "feels" or is actually used are paramount. If you move away from iterative coding drafts, you still need some sort of interactive product to work on to actually develop the spec.

Plus, current-gen agents/LLMs can't implement a non-trivial language spec without significant hand-holding.

foltik 5 hours ago | parent | prev [-]

Such a spec would never survive contact with reality. Maybe a human could stumble their way through iterating on it with the help of an LLM, but with current models you’re going to end up with nothing but a steaming pile of garbage. Not Zig.

edoceo 7 hours ago | parent | prev [-]

It's kinda fun to build with too. Making a bootloader, doing some UEFI things. Much easier (for me) than when trying with C. But also, new&shiny and learning is fun - increases my bias.