Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig Creator Calls Spade a Spade, Anthropic Blows Smoke

raymyers.org

Post reply on HN
Print view View original

391–400 of 862 posts

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

#391

Post by Aurornis »

jraph wrote: post #292
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…

If you don't intend to write misleading stuff that makes Zig look bad when you leave and if you avoid ghosting the Zig foundation in scheduled meetings you had with them, I suppose you should be good.

> If you don't intend to write misleading stuff that makes Zig look bad

What misleading stuff? Makes Zig look bad how?

The posts I read were appreciative to Zig.

The only “misleading” piece of either blog post that I recall was the Andrew Kelley claim that Bun wasn’t fuzzing, which was easily refuted by pointing to their fuzzing work.

If there’s something more then I’d like to see it, but every time I ask nobody can point to anything other specific.

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

#392

Post by deaton »

mbesto wrote: post #344
manphone wrote: post #208

Earlier quoted context omitted.

It’s the same reason why everyone doesn’t wanna read LLM generated blog posts. The agreement used to be generally that you would spend more time writing than I would have to spend reading and when the agreement changes the quality changes as well.

You can't unilaterally say all AI blogs are low quality. That's bullshit. > would spend more time writing than I would have to spend reading To your point however, the reason people don't like AI generated blogs is because there is a explicit recognition that the author of the blog lacked effort . There is a visceral response for the reader about the social contract "if you didn't spend as much time as I did why shou…

> You can't unilaterally say all AI blogs are low quality. That's bullshit.

I can and I will say that, if not only for the fact that, in the eyes of many people, AI and the botched launch of the past few years has incurred a great amount of distrust. But, going further, the vast majority of AI-generated blog posts are lower quality, because they lack human thought and effort behind them. I'm not saying AI is completely incapable of writing what a human can, but we can't relate to how it "thinks", if you can call it that, and if someone is going to put enough effort into curating an AI's output and coaching it to make it output something that is really of a high quality... they just put in all of the human effort it would have taken for them to write it themselves.

I also don't think this should be construed to mean that human-written posts are universally good. AI slop is just the latest and most farmable iteration of a long history of badly written and poorly thought out content on the internet. In some ways the average AI blog is probably more coherent than any flat earth blog.

I also think that that visceral disgust at consuming AI generated work points to something else. We are all still trying to grapple with the ethical boundaries of what is okay and what isn't okay to do with AI, but I think most people feel deceived when they find out they're watching an AI video, or reading an AI blog post, and rather than assuming people are wrong to feel that way, we should consider that their feelings on the matter do matter. Nobody wants to be fed algorithmically optimized fake slop by YouTube, and that's okay.

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

#393

Post by lunar_mycroft »

herrkanin wrote: post #117
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…

> How is that better than the Zig codebase you started with? In contrast with the Zig codebase, you now have clear well-scoped unsafe boundaries you can iteratively fix one by one. This was not the case before.

Except that writing safe rust often requires designing the architecture around rust's ownership model, meaning a file by file, line by line translation doesn't necessarily leave you much closer to safe rust than you were at the start.

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

#394

Post by Thanemate »

vlaaad wrote: post #3

Did we read the same Anthropic and Andrew Kelly's posts? Anthropic is not in the programming language market; their post about rewriting Bun in Rust is full of technical details that led to improving the end product for their users. Zig's response is a sour opinion piece full of personal attacks. For context, I'm using Codex and have no interest in either Zig or Rust, so just observing this drama from the sidelines.

The moment technical decisions are influenced by LLM compatibility and LLM performance, they basically are.

Remember the days where teams would adopt technologies based on how familiar the members are with them? "Now that the AI is here" and is the one writing code, to the point where Linkedin devs flex how it's been months since they touched source code, teams adopt technologies based on how familiar AI is with them.

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

#395

Post by Keyframe »

15155 wrote: post #337
Keyframe wrote: post #327

Sarcasm hat on - You know what, if LLMs were so infallible at coding and engineers useless for hands-on, then why even bother with anything except asm or even skip the mnemonics completely and go straight for the binary? Why even bother with abstract code when abstraction is now your LLM.

Because underneath the code you have more than one architecture to support.

if LLM is your abstraction - you give it a task to produce multiple targets. EASY PEASY, next!

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

#396

Post by FeepingCreature »

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…

> Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?

I'm gonna offer an alternate theory. Because AI-generated projects are so cheap, there's no need to amortize them by advertising and creating a community. It works for you, you don't change your workflow, so there's no need to expand it. In this model, most AI-generated projects are done within days, not abandoned.

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

#397

Post by quirkot »

sph wrote: post #356
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…

Yes, there is a widespread belief in tech that 'removing friction' is a good direction to aim for. But you can have too little friction that completely ruins a product and the user experience. In game design friction very important; remove all friction and you don't even have a game any more, you might as well show the You Win screen. My favourite metaphor for it is sex: there is no sex without friction. What LLM hav…

In terms of removing friction, I think of moving a boulder. Wheels = good. Ice slide = bad

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

#398

Post by lolinder »

simjnd wrote: post #204
cognitiveinline wrote: post #94

Earlier quoted context omitted.

>very actual technical substance Did we read the same article? I mean it wasn't talking about a specific line of code, but it had deep architecture details, rational for memory safety and bugs, agentic coding patterns for scale. It was full of substance, multiple times.

I could point to the same examples this article refers to: the Bun blog post says "Having a rigid style guide [in Zig] with clear ownership expectations explicitly spelled out in the type system was a real option for Bun" and presents no technical reason why they didn't choose (or even TRY) that. They handwave it with "This is and ergonomic than the Zig we expect". Why was it in their own words a real option? And why…

The very next sentence justifies why they didn't do it: it argues that they would have ended up with what was technically Zig but something that was much less ergonomic than what would be expected from Zig.

You can argue that that's a bad justification for not doing it, but that's a debate on the technical merits, not a claim that they didn't provide justification.

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

#400

Post by saghm »

torginus wrote: post #211
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…

I don't even get what they gain by Rust - Bun imports Webkit, which is a C++ project, relying on it for stuff like JITing Javascript. I would say that's a major concern, and making sure the JIT doesn't emit anything broken or naughty is completely outside the scope of Rust.

I don't have a strong stance on the overall issue of whether it made sense for them to port like this, but I feel like this misunderstands the value proposition of Rust. The point of Rust is not and has never been "make literally everything safe", it's "push the unsafe boundary as low as possible and keep as much as possible above it so that you can reduce the surface area for unsafety and more easily find bugs in the unsafe code". For some things, that means you can rely only on unsafe code that's in the standard library implementation, which is awesome. For others, you might need to rely on FFI to interface with external libraries, and that's obviously less ideal but still provides tangible value. In the worst case, you might need to write unsafe Rust code yourself, but you can at least take efforts to minimize the surface area of it by wrapping it in safe abstractions that enforce the invariants you need to uphold safety.

The idea that "anything other then pure safe Rust is useless" is common (even among some Rust proponents, but generally not the most experienced ones), but it's a pretty fundamental misconception of what Rust actually offers. Safety is a spectrum, not a binary, and while the extreme end of "everything is guaranteed to be safe no matter what" is nice when you can get it, Rust is literally designed to solve the problem of giving you the ability to slide along the spectrum to calibrate to the most amount of safety you an achieve rather than being all-or-nothing.

If you still think there's no value in enforcing safety outside of the lowest level stuff like JIT, I'd suggest being more explicit about why you're confident that memory safety bugs wouldn't be a concern outside of those contexts. I've yet to hear an argument for why I shouldn't be concerned about memory unsafety in even relatively mundane code in memory unsafe languages that doesn't basically boil down to "just be really really careful", which I'd argue has been empircally shown to not work even a little bit no matter how skilled the programmers writing the code are.

Post reply on HN