I wouldn’t write Zig off yet. The faster compilation time is a giant moat. Depending on how LLM usage evolves it could be what ends up mattering.

I'm not writing Zig off myself. I would prefer if it succeeded. But the outlook is: not good, in my eyes.

Pre-2022, Zig was doing decently, but not particularly well. It didn't have Rust level of enthusiasts and ambassadors (love them or hate them, they did succeed in driving considerable Rust adoption), it didn't have a major corpo backing it, it had too much API instability to be truly relied on. Picking a stupid fight with Bun/Anthropic and doubling down on it isn't helping with any of that.

I also don't think compilation time makes for a good moat for agentic AI coding? Like, sure, less time wasted = better. But LLMs don't perceive time as humans do. They don't have the human "40 minutes of compile time = a hard forced context switch" quirk. The state of an LLM agent is as "stale" after a 40 minute build as it is after a 40 second build - no attention penalty for getting distracted.

There is a hard "wall clock time" iteration speed penalty, but I expect LLM coding to be more agentic, not less. In which case a single sub-agent stalling might not matter much? The orchestrator AI would just keep doing other things, and come back to the stalled sub-agent when it's ready. Once again: long stalls hurt the worst if they route through human attention. The less human attention there is in the system the cheaper they are.

A day or two ago someone posted about abandoning Haskell because compilation times had become a bottleneck with Agents. FWIW

HN discussion: https://news.ycombinator.com/item?id=48859673

1 minute skim of that surfaces aviaviavi's comment on moving to Python not Rust:

  Main factors were (roughly in order):
  - None of us are experts in Rust, and we're all solid at Python.
  - Rust felt like an under-correction for what we wanted (get all friction in front of the LLM out of the way).
  - Our high-performance stuff is not being migrated at this time (Scarf Gateway), so we're just talking about basic CRUD backends here. Basically any language will work

also, the fact that you can compile to any target from any target

I write a lot of Rust and work on some large-ish code bases. I’ve also done Zig work and work in other languages with fast compile times.

I don’t think this is a huge moat any more. Structuring Rust codebases in a modular way to keep incremental compile times down is common. The biggest complaint about it is from people who simply don’t like the structure and want to put everything into one big package, but that’s a stylistic choice.

You write Better C and the first thing I think about is D-lang.

you write D-lang and all I can think of is too much nonsense you have to tell a team (an LLM?) to avoid the temptation to use.

Fall into it. I am rewriting all my projects in D-lang. It is really that good. Particularly when compared to Zig and Rust.

A typical comment on Hackernews nowadays:

I used to think that there's a a room for better C -> Some unrelated complains about Rust and Go -> C has footguns, but they don't matter that much because I choose to not write my code myself anymore -> Therefore there's no room for better C.

What makes go so awful to write? My impression was that Rust was hard, at least until you understand the borrow checker, and go was pretty easy. (This is my impression from outside, that is, I don't actually use either language.)

Not OP, but normally people complain because its boring, but these days, have an LLM generate all the template coding, the json mappings or whatever people dont like. Personally, with all the compromised NPM and PiP packages, when i PoC / vibe code something, i tend to use Golang very few external packages (native sqlite) and thats it. Also really nice to be able to package up the App and all related files into 1 binary.

> And, on the other end, C's warts, footguns and ancient quirks also matter less if you have an LLM plow through it.

'plow through it's?? An LLM can definitedly fall into these traps!

Happened to me a few months ago, I couldn't believe that an LLM would generate a use-after-free in not-so-complex code but it did.. Newer LLM seems better now but buyer beware!

You still need an expert human to drive an LLM. And even then, with C, you need to be very careful. LLM’s generate lots of code. Code that has no obvious errors in it. The kind humans aren’t good at picking up on their own. You need other tooling in place to support human experts to prevent this kind of stuff as you would in a non-LLM contribution.

> And, on the other end, C's warts, footguns and ancient quirks also matter less if you have an LLM plow through it.

Warts and ancient quirks, I can kind of see, but in what way have LLMs solved the footguns?

Mostly, by having enough diligence and attention to avoid a lot of the common ones.

By now, if we're pitting a top of the line coding LLM against a B-tier programmer throwing something together in a hurry, I would expect the latter to shot more foot, and not by a narrow margin. Even those who know better don't always do better - for a human, "fucks given" is a painfully finite resource.

"Rust - that it's frankly a bitch to write, nearing Go levels of awful"

Go, awful? That's wild. I find Go to be maybe the most pleasant language I've ever used. It's just delightful for its niche (web services, system tools, things of that nature), I've never seen anything better.