Zig Creator Calls Spade a Spade, Anthropic Blows Smoke • Hacker News Board

Re: Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

#531

Post by dnautics » Mon, Jul 13, 2026, 3:03 PM UTC

petcat wrote: post #133

RetroTechie wrote: post #97

There's so much good stuff in this post. Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why? Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen. Battle-tested, mature code > fresh rewrite. Existing Zig codebase has seen X amount of battle-testing. Rust rewrite: 0 (except -I'm assuming- passing test su…

> Now if that's further migrated to safe Rust, put into production & gathered feedback from lots of users, yes then you have something. Obviously they have to start somewhere if they want to get to safe rust with a considerable degree of battle testing. So they decided to start with just a transliteration and go from there. I think the Zig people are really just concerned that maybe Zig itself is a DOA language becau…

> the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C

I don't think anyone who actually uses zig thinks "it doesn't offer enough over C". Removing #define alone would have been worth it.

Re: Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

#532

Post by redwood » Mon, Jul 13, 2026, 3:03 PM UTC

RetroTechie wrote: post #97

There's so much good stuff in this post. Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why? Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen. Battle-tested, mature code > fresh rewrite. Existing Zig codebase has seen X amount of battle-testing. Rust rewrite: 0 (except -I'm assuming- passing test su…

Of course the deeper points can be made that relatively few folks were actually using Bun. After all Bun was itself a faster horse compared to the dominant runtimes it was aiming too replace. Ironic, the way this whole meta conversation is playing out.

Re: Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

#533

Post by softwaredoug » Mon, Jul 13, 2026, 3:04 PM UTC

bergheim wrote: post #529

what I don't understand is, given the anthropic narrative, why on earth rewrite bun to rust, and not claude code to rust? why use typescript at all when the whole point is that languages don't matter anymore? I suppose it is solely because it would be a bad look on them to rewrite claude itself - it means they failed - but rewriting bun is a much better narrative - claude is fine! it's just his runtime we need fixing…

Probably because agents in typescript don't waste time reasoning about so many different problems that come up in a lower level language. They stay higher level, and don't waste context on thinking about borrow checking, like you would in Rust.

Re: Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

#534

Post by well_ackshually » Mon, Jul 13, 2026, 3:04 PM UTC

rafterydj wrote: post #278

well_ackshually wrote: post #66

Earlier quoted context omitted.

Forgetting the JVM when it provides absurdly good performance and more packages than pretty much all three of these languages combined is certainly a choice. Even Java and all its verbosity gets fixed by not having to write it manually. Kotlin is also a very viable option. Scala if you're a bit crazy.

Most of the people I've encountered that use Java are working on enterprise codebases that are a couple decades old at this point. And I'm totally unfamiliar, but I thought Kotlin was vaguely "Java for Android" - other than existing packages, are there other reasons to choose languages focused on the JVM?

Modern Java is definitely pretty good. But indeed, Java has solidified a lot around "old" style code: making your 50 years old CTO start using collectors and typing `var` instead of MyObject object = new MyObject(); can be a difficult thing. Modern Java is truly quite pleasant.

Kotlin is a fully JVM compatible language. Java is catching up to it in some points (Project Loom has made multithreading in Java almost as pleasant as coroutines in Kotlin), but the experience in writing DSLs, code with lambdas, the brevity afforded by Kotlin makes it more pleasant than java. It's also the default recommended language for Spring/Spring Boot now, that is probably the largest JVM API backend project that ends up being used by default.

The benefits you get are:

* Probably the most stable platform you're ever going to get: the JVM is rock solid and does not require tuning honestly, unless you're trying to get a free few percents of performance. Your shitty SaaS startup doesn't need to do that.

* Probably the most performant JIT in the world. Python isn't nearly close, and Go is, well, not jitted, but offers similar-ish performance. Except that you get a good GC with the JVM. Or rather multiple GCs depending on what you really want: throughput/low pauses/etc.

* The packages are truly a massive thing. The APIs aren't always perfect, but behind python & js, it's probably the most fully fledged option.

* Publishing modules doesn't suck.

* Having to carry a jar around does suck a bit, but fat jars solve the problem, and if you're serious in your work, you can just GraalVM it and you have an AOT compiled executable that works great.

Negatives:

* It's java, man. It's still the same verbose beast. Doing low allocation work is a bit hard. Kotlin makes it better. Kotlin also has kotlin multiplatform with a large and growing API surface, and is probably one of the most pleasant multiplatform options, allowing you to delegate to any platform code you want.

* You're never getting a tiny 5MB executable. If startup time is an issue, work hard on GraalVM.

Re: Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

#535

Post by metoobruh » Mon, Jul 13, 2026, 3:05 PM UTC

Tadpole9181 wrote: post #506

cyber_kinetist wrote: post #489

Earlier quoted context omitted.

> We can gradually refactor it Is quite a hell of a statement, when memory management issues are highly nonlocal and need some careful design upfront in order for you to nail it. Unsafe isn't something that you can gradually clean up. Even one single flawed usage of unsafe (an ill-assumed invariant) can poison the whole program in scary ways, and might require a total refactor of your codebase to fix it.

You're not helping your case. So if I use Zig, I need to do all of that perfectly from day one and I don't get any help from static analysis to do it. Or else I've poisoned my whole program in scary ways and will require a total refactor where I still won't have any help and once again can't make a single mistake.

You're not helping your case.

> [what you just wrote]

So they gained nothing from a Rust rewrite, except introducing more bugs into their shit codebase.

Re: Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

#536

Post by dnautics » Mon, Jul 13, 2026, 3:06 PM UTC

Shorel wrote: post #267

ACCount37 wrote: post #180

Earlier quoted context omitted.

I used to think there's a good niche for "better C" - and that Zig was the one language angling for that. A language that can be used in the same contexts as C, to do the same things as C code, in very much the same way, but with some modern features, some stronger guarantees and some helpful syntactic sugar? A welcome thing for embedded development. On the other end, Rust to me felt like "better C++" - outside the e…

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.

Re: Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

#537

Post by gedy » Mon, Jul 13, 2026, 3:08 PM UTC

Lerc wrote: post #430

woodruffw wrote: post #28

I think like most people, I don’t have a problem with Andrew “calling a spade a spade,” even if I find his reasoning motivated. The bigger problem with the post is that it talks out of both ends of the mouth: it’s clearly meant as a personal attack, but also insists that it isn’t. When I read the post, my first thought was that I wouldn’t want to build things in Zig, because any technical decision I make, good or bad…

>When I read the post, my first thought was that I wouldn’t want to build things in Zig, because any technical decision I make, good or bad, might subject me to this kind of article from their BDFL. I think it is worse than that, the comments from people in threads about this suggest that this is an attitude that is creeping into the community. They may not be a majority, but if kinder souls decide to leave for a mor…

> They may not be a majority, but if kinder souls decide to leave for a more welcoming community

Given the context, you mean Rust? Nothing against Rust folks but I wouldn't really call it more welcoming community.

Re: Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

#538

Post by monsieurbanana » Mon, Jul 13, 2026, 3:09 PM UTC

guardiangod wrote: post #527

unknownfuture wrote: post #376

Earlier quoted context omitted.

That's absolutely not true. Differently languages have greater or lesser representation in the training sets. You see a similar bias toward specific libraries within a given ecosystem, so much so that I worry about AI created technical monocultures as AI generated code converges to specific languages, packages, etc. The LLM companies have truly astounding power to now steer the direction of the entire industry. It sh…

Rust does not have a bigger training set than say Python/JS/TypeScript/C++ .

Meta for example is spending a lot of effort and money into creating new curated programming training sets.

That means at least from their POV what's already available is not enough or not good enough, and if they're correct then the companies making the models can "artificially" inflate a language's representation.

Re: Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

#539

Post by jesseschalken » Mon, Jul 13, 2026, 3:09 PM UTC

empath75 wrote: post #385

budsniffer952 wrote: post #364

Earlier quoted context omitted.

> Jarred has written Bun with very bad engineering standards "You're holding it wrong." > Jarred has managed public relations very poorly (e.g. ghosting the Zig foundation) What obligation do you think he has here? Which direction should these good relations flow? I'm also an outsider here, and reading this post was kind of shocking. Can't believe someone would attack your open source code. It's everything normies ha…

I'm basically of the opinion that if agents can't write your programming language, that's a problem with your programming language.

So, no new programming languages until the end of time?

Re: Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

#540

Post by panarky » Mon, Jul 13, 2026, 3:10 PM UTC

mech998877 wrote: post #480

TeriyakiBomb wrote: post #244

Earlier quoted context omitted.

A drum I've been banging increasingly often recently is that having friction and time to work ideas over in your mind adds huge amounts of value. Vibe coded projects have this very specific, well, vibe to them where you can clearly see that the lack of time to digest has allowed the person to not challenge their own worst impulses. You can see it in the feature bloat, the lack of depth and polish in core features and…

I disagree with this, and I've been spending time thinking about it because some of my friends had a similar conversation. The friction itself does not add value. The time spent thinking on the problem does. Friction should be minimized beyond the absolute bare minimum. Programming is a discipline where your workstation is already streamlined, and it is easy to forget where the friction is. Programming is done in a w…

> The friction itself does not add value

Exactly. I don't have to write binary machine code directly, every zero and one artisanally crafted by hand, to have thought deeply for years about a how to solve a problem.

In fact, choosing the right level of abstraction is essential to my ability to solve the problem.

For most problems, the friction of writing binary code by hand is the wrong level.

And we're discovering that many important problems can be solved faster and with greater quality than can be achieved by dogmatically hand-writing every line of source code just for the friction.