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 suites). Also:
"this was a port to unsafe Rust, allowing a literal file-by-file migration to minimize risk"
How is that better than the Zig codebase you started with?
Now if that's further migrated to safe Rust, put into production & gathered feedback from lots of users, yes then you have something. As it is, the impressive bit is do such a big rewrite & result seems to work ok. Are Bun users happy with this?
To me it reads like Bun was forked. Will the Zig version survive? Will the Rust one? Both? All options ok.
Edit: and fwiw, I don't think Zig community should get triggered on any of this. It says nothing about how suitable Zig is or isn't for project xyz, and Zig community is big enough to carry their own project & applications besides Bun.
They get abandoned because they get generated on a whim.
Sunk cost fallacy can be a feature: if you have spent a lot of blood, sweat, and tears on a project, you are more likely to push it through adversity and the doldrums that inevitably one will encounter. If all it took was one of those momentarily brilliant ideas and a prompt on Claude to produce something, there is no attachment whatsoever to it.
Speaking as the ‘average programmer’, I have dozens of brilliant ideas per day that don’t stand the test of time or scrutiny, and the very few that pass the filter don’t seem that interesting days later, or worth the effort at all.
Ideas have always been cheap. Now, proof of concepts have become as cheap. I don’t care about your Show HN unless you have spent a month on it.
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 the wild asides you tend to talk yourself out of still on display.
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 world of pure though, in a sense, so most of the friction already lives in your head, and it is difficult to distinguish effort wasted fighting friction from effort making real progress.
Consider the Wright brothers. They worked iteratively. When they wanted to design an airplane they moved from Ohio to a windy place with lots of loose sand (NC outer banks). Why? So that they could do test runs with good wind conditions (for an airplane that is barely able to fly this matters a lot) and crash with the least amount of damage. They rebuilt the airplane dozens and dozens of times and had a workshop tuned to their needs on location. They reduced friction wherever they could so that they got the most work done that they could with the least amount of distraction.
>Programming is done in a world of pure though, in a sense, so most of the friction already lives in your head
It seems that way, but that's not actually true. A fully greased-up brain would produce just incoherent nonsense decoupled from reality, because it would lack all constraints that would allow it to judge the value of an idea (i.e. how possible and useful it would be to implement in the real world). The friction comes from fitting your ideas into the real world.
>They reduced friction wherever they could so that they got the most work done that they could with the least amount of distraction.
They reduced unnecessary friction. They could have eliminated all friction by imagining a teleporter machine that can send you anywhere instantly and that runs on the hopes of children. But they still wanted the friction of unsuccessful attempts so they could actually build a plane that worked.
Your concluding example doesn't make sense to me but I think that it's because we have different definitions for what friction means here. It's also kind of hard to define in context.
I would say that, within the Wright Brothers example, working with a battered, worn-out screwdriver is an example of friction (or, perhaps having to use a bit and brace instead of a power drill), but the act of building a new unsuccessful airplane iteration is not friction. Every build is asking physics for feedback on the design; every airplane build is just the same as running your code through the compiler. I wish I had a good word to distinguish this from friction. The closest thing I can imagine is how waste is defined in Lean Manufacturing, but keeping in mind that what you are manufacturing is Ideas and Software.
It sounds like you're not disagreeing with what the other person was saying then, you're just disagreeing with their application of the word "friction". I don't think it makes much sense to argue about the precise definition of a metaphor.
I liken it to dieting. If your only goal is to be certain weight, then learning how to cook, learning how to portion, learning to make a meal plan, learning about macro nutrients is all "friction" now that we have GLPs. And maybe using a meal prep service reduces some "unnecessary friction" but you still would have to learn a bunch of useful skills along the way.
Concretely, If your only goal is to produce "software" then learning about design, planning, project management, testing etc is all unnecessary friction when you can just ask an LLM to "make it so"
Nitpick, but this is misunderstanding GLPs (I'm on them). If you don't change your diet and your habits, yeah, you'll temporarily lose weight but it'll come right back when you're off it AND you'll lose a lot of muscle. You kinda still need to do "the right things", it's not a magic cure all. (Of course, same thing can be said of AI).
A fair callout, though yes it was supposed to be a simplified analogy. I think you got it exactly right though that its temporary in the same that I'd argue the benefits of using AI are temporary
As someone who has been losing weight over the past year, the cost of GLP1s is and was a greater point of friction to me compared to just eating less garbage.
I think this is just my choice of wording, friction as a means of slowing down and thinking something through is useful. Friction isn't just a roadblock. For all the times you want to do something exotic, throw an hour or two at it and in the process realise it was a bad idea and a more elegant idea emerges. That, that's the kind of useful friction I mean.
But overall yes, time spent thinking is the thing that matters.
It's less "there should be more friction" and more "LLMs remove too much". Instant gratification is great if you're a consumer, awful if you're a creator.
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.
I think that friction of feedback and friction of construction are two different things.
Having lots of tokens to build things doesn't mean you have more feedback.
I'm a bun user I like it. I can't really comment from my use on what the Zig vs Rust rewrite means to me.
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 have done is massively reduce the friction of intellectual effort, completely devaluing most expressions of it.
You have to get licensed to drive a car and there are rules. If you are caught breaking the rules you can be fined (or jailed if your rule breaking harms others enough). In extreme cases of rule breaking you can lose permission to drive the car.
This is all friction that is intended to make car-driving work at scale.
I don't think it inherently devalues it. But the mediocre baseline for it and how much it entices you to allow it to just spit out that mediocrity takes discipline I don't think everyone has. I've seen some lean in and keep their heads just fine. I've seen others lean in and become disillusioned.
Worst of all I've seen good engineers lean in and begin thinking uncritically and magically.
Let's first settle on the definition of vibecoding so that we're not miscommunicating over definitions. I'm using the one that seems the median definition nowadays: >95% of the code written by LLMs, <60% of the output code human-reviewed, meaning there's a large part of the codebase that no human ever reviews.
As you said it's about time invested in thinking about it, yes. But remember that even pre-AI >90% of software got never used, it was dead on arrival. Look up "success rate of software projects in business".
You can put lots of time into thinking and vibecode everything. You can put very little time into thinking and write by hand. Of course, vibecoding makes the former much more likely. But nothing about it is inherent to it.
I hate to be the guy arguing semantics, but is that the median definition? Everyone I know defines vibe coding as ignoring the actual output code completely and evaluating the result by how it behaves under test. Non-coders vibe code by default, because they don't understand how to read the code in the first place. Developers vibe code when they just trust the LLM to have been right about the behavior they don't explicitly test for. Vibe coding is the act of ignoring most possible friction, for better or worse.
It is. There are many people on here who think of having any LLM generated, never-human-reviewed code in the codebase, as vibecoding. There are also people like you, who believe it's about completely ignoring it, and even human-reviewing 10% of the code means it's not vibecoding. The median definition, at least on here, is somewhere in the middle, around "a large portion of the code is never looked at by a human".
Happy to learn about the concept today. It resonates with me.
I sometimes think of something Kant wrote, about how friction (hardship, etc.) elevates us.
In Kant's own words:
"Without those in themselves unamiable characteristics of unsociability from whence opposition springs-characteristics each man must find in his own selfish pretensions-all talents would remain hidden, unborn in an Arcadian shepherd’s life, with all its concord, contentment, and mutual affection. Men, good-natured as the sheep they herd, would hardly reach a higher worth than their beasts; they would not fill the empty place in creation by achieving their end, which is rational nature. Thanks be to Nature, then, for the incompatibility, for heartless competitive vanity, for the insatiable desire to possess and to rule! Without them, all the excellent natural capacities of humanity would forever sleep, undeveloped. Man wishes concord; but Nature knows better what is good for the race; she wills discord. He wishes to live comfortably and pleasantly; Nature wills that he should be plunged from sloth and passive contentment into labor and trouble, in order that he may find means of extricating himself from them. The natural urges to this, the sources of unsociableness and mutual opposition from which so many evils arise, drive men to new exertions of their forces and thus to the manifold development of their capacities. They thereby perhaps show the ordering of a wise Creator and not the hand of an evil spirit, who bungled in his great work or spoiled it out of envy."
See the section titled "FOURTH THESIS" at the following link if interested.
Alternatively, you can easily add the bloat, discover if it has real value, and then strip it without the bad feeling of having sunk countless hours creating it. Vibe coding is excellent for making the first prototype to throw away.
I agree with this wholeheartedly, it's harder to notice this in a field you are a professional in, but what really opened my eyes was noticing how often friction kept me from making mistakes in hobbyist metalworking/woodworking projects. More than once I've either made or didn't make mistakes based entirely on if the tool I "needed" for the next step was in arms reach or a walk across the garage and a search through multiple toolboxes.
I feel this too but it's very hard to argue myself out of adding features like mad. Features, features, features. Tech debt may be an illusion, if the LLM can keep maintaining it all.
features with theoretical use incur cost up front and yield no value. tech debt is only part of the cost, the other is opportunity cost of writing the OPTION. There’s really no good reason to create theoretical use features.
it’s a breakthrough for me because i too like to build so it’s hard to not build. With options, i don’t get to build blindly but there’s still satisfaction in holding the option. collect the options, system design them, build on that layer.
That analogy works for app code, it doesn't work for technologies, library, frameworks, algorithms. Why build a compiler for this app? YAGNI! makes no sense.
I think you're right, and I think this principle of friction-is-good-actually applies to a lot more domains than just software, but whether the world will ever accept that is a different question.
I know of some financial analysts who don’t like to pull data in from reports automatically. They prefer to read each row and copy it into their spreadsheet because they actually contemplate what the number means.
It's a flavour of Jevons paradox. Make production of software much more efficient (requiring fewer developer-hours), then you might get:
1. Same services provided using similar software stack, but maintained by fewer developers. I suspect this may hold for some sectors in the economy. Or
2. The Jevons case: similar # of developers maintaining a much bigger software stack that provides more services.
I might add:
2a: Similar but with lots of accidental complexity everywhere.
Probably we're heading towards some mix of the above? Depending on which application area you're talking about. Web dev is a lost cause, deeply-embedded won't see a big shake-up.
I also think it's universal. When talking about this IRL I always say:
"If one teenager works hard and saves for a few years to buy themselves a car and another has theirs bought for them on a whim, who would appreciate their car more?"
> I don’t care about your Show HN unless you have spent a month on it.
100%, you actually stated it correctly. It's not "I don't care unless you've written/reviewed everything by hand". If someone writes something by hand in an hour, including ideation, and puts it on Show HN, realistically it's almost certainly not going to be worth even looking at.
I've been running an app in prod for more than a year now, mostly vibecoded long before HN believed it was possible - HN only started believing this around Jan this year at the earliest. But nobody who uses it cares, or even notices, because it took a month to build. That's what matters, the amount of time and thought put into it. Of course it's true that vibecoded projects have a much lower median amount of time and thought put into it. But that's like Louisiana having a much lower median income than California, it's just a median, not an inherent characteristic of being a Louisianan vs a Californian, there are plenty of poorer Californians and richer Louisianans.
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.
Writing is thinking. If you don't spend time writing, then you didn't spend time thinking. LLMs don't think. Consequently, if you outsourced your writing to an LLM the resulting artifact was born of a thoughtless process. Instead of engaging your readers in your thought process you're tricking them with a puzzle. Readers will try to understand what you're thinking about (at least the non-passive ones will). This activity is a dead end for LLM output.
It's not that writing _is_ thinking, but (effective) writing _requires_ thinking. It forces you to take a collection of lose and incoherent thoughts and reify them into an argument that can hold its own weight.
The art of essay writing allows an author to ascertain how well they understand a topic and work out the flaws just by trying to put it into words. Paul Graham speaks about this.
Is writing thinking? Good writing requires thinking but does that also go for sloppy writing? What is thinking? This is the subject of a discussion [1, 2] I'm in - which in true HN style has been greyed-out because of ${reasons} - regarding the question whether these models 'think'. Your comment on writing [being] thinking supports the idea that what these models do is a form of thinking: selecting the next most likely descriptor given the current problem space including all previously added descriptors.
Reading the output of a LLM prompt someone else wrote isn't useful as I can run the prompt myself. Having the prompt is actually more useful because I can run it in any LLM I want.
> 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.
That's not it at all.
The problem with AI slop is that in general it's not worth reading, because to start off even the author deemed the topic wasn't even worth writing to begin with.
Worst, most AI slop blog spam was obviously not even reviewed by the bloggers who prompted them into existence. This means is also content that even the bloggers themselves felt wasn't worth reading at all.
But somehow they expect us to invest our time reading AI slop?
If you had a time machine and you could republish a claude generated article about some interesting tech topic to 2010 I'm sure it would get ok engagement.
To me the issue is that everything becomes written in the same style pattern. I don't know why but if I spot it I wince internally and immediately skim the post or just outright stop reading. A large part of it is overexposure. For me it's made browsing the internet quite uncomfortable since it's unavoidable.
I mainly spend my online time in group chats these days.
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 should I care about what's written here", it's however NOT that the quality is inherently poor (but perhaps one my insinuate that notion).
> 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.
>Ideas have always been cheap. Now, proof of concepts have become as cheap. I don’t care about your Show HN unless you have spent a month on it.
Yes. I'm as pro-AI coding as people come, but this is the part that bugs me too. If you whip something useful up in a weekend, great!
But you don't have to present it like you are building an actual product. It's fine if no one else knows about it. Because the fact is, most people don't care, even before AI. Building for yourself is fine.
It's very strange to vibe code a project and feel both a lack of emotional investment but also the cognitive overhead of steering an AI.
The process of iteration, or the feedback loop, typically allows space to try things out and experiment and then either drop an idea or refine it more purposefully. And those breaks in between the pure delivery to focus on that gives you room to breathe and also see the progress of your work.
Blatting it out in 6 hours with Fable 5 skips all of that and you have something like an MVP, but you haven't really put anything of yourself into it. So why bother committing unless you can take that further or apply something novel or reflect your own personality in it? Or you genuinely believe you're on to something and the AI approach actually gave you a path to building it?
I've been 'vibe coding' something, I've spent about a month on it on and off along with a fair bit of debugging on some sticky issues. I still think I'd suffer going into that codebase and doing stuff in it by hand, no matter how well I thought I organised it all.
>Ideas have always been cheap. Now, proof of concepts have become as cheap. I don’t care about your Show HN unless you have spent a month on it.
I dunno, this idea guy seems to have some really great ideas, what's wrong with you skeptical programmers who aren't on board implementing his ideas for equity?
Great point. It is simply lame impatient clout-chasing when someone goes out and promotes their project that is approximately as new to them as it is to the people they're promoting it to.
I wonder how much it costs them in the long run; the initial number mentioned seemed cheap enough (equivalent to 1-2 developers for a year - and I don't believe 1-2 developers could rewrite it in a year, for various reasons), but if it's a 1:1 "transpilation" to unsafe Rust... was it worth it? Will it be worth it in the long run?
But this is the longer running discourse about AI code's cost / benefit. I keep nagging my work's AI community to show me the numbers, so far nobody has been able to show an increase in productivity, quality, customer satisfaction, or company profits.
Keep in mind logic bug that ai makes are extremely hard and expensive to fix as the clanker needs to parse thousand and thousands of lines of text every prompt while a human tries to explain what it's obviously doing wrong.
I hate ai so much because its so easy to generate quick slop that "appears" functional.
> 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 because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
Just search "segfault" on the Zig issue tracker and you'll see why people are starting to be skeptical of the future utility of such a language in the face of something like Rust.
> Just search "segfault" on the Zig issue tracker and you'll see why people are starting to be skeptical of the future utility of such a language in the face of something like Rust.
Zig has 110 open "segfault" issues [1] versus Rust's 175 open "segfault" issues [2]. So, by your logic, Rust is also bad.
edit: I was just trying to point out that the parent's "just search segfault" argument is lazy. Also, Zig is still in beta.
I think the open to close ratio needs to be provided in any such comparison. It would arguably give a better indication of which project is doing a better job at addressing incoming user issues and bug fixes.
Yeah, well, my not-yet-written language has zero segfault issues raised, so it’s clearly superior to both Zig and Rust. I really need to get around to writing it because obviously it’s a much better design.
I see Rust encroaching in proposed transitions. It may even happen.
That said, it is a poor match for it compared to something like Zig (or Odin). It's hard to make the new Rust code use existing allocator abstractions (so now you have two systems doling out memory, how do you reliably free composite objects with memory from both? How do they share?) and you increasingly have to either abandon any actual benefits of the borrow-checker, or invest increasingly heavily into sufficiently fat bindings to wrap your existing C/C++ in a way where the borrow-checker can assist you.
That's before we consider the complexity of the language - I'd doubt a seasoned C programmer has much trouble deciphering Zig or Odin FFI bindings, but in the case of Rust? Yes, there is real friction.
Also if you really value predictable- and higher performance, being in more in control of memory allocations and cleanup is preferable. This is the direction both Zig and Odin cater to.
If you asked me what solves the most issues without adding too many new liabilities, I'd say Zig (or Odin).
It would simply be much, much easier to transition a C codebase to either, and either would bring a much improved stdlib with pluggable allocators capable of leak-detection etc.
If you literally want one and only one allocator instead of the Rust's built-in one, that's been supported for years[1]. Almost 8 years, to be precise. It's very easy to implement and works with the entire standard library and all its abstractions, and almost every 3rd party library will support it out of the box too (except the ones that go out of their way not to support it for some reason). Borrow checking and all the other safety features are still fully supported.
Now, mixing different allocators is a different beast, and much less supported. But it sounds like you are very much not interested in this use case, right?
C++ programmer here. I've looked at transitioning some of my code to Rust; not particularly out of a dissatisfaction with C++ but more just out of curiosity. I've always ended up deciding against it though, I feel like its safety features just come at too high of a price for the kind of work I do. If I was writing something that needs to be super secure like a web server or something I think it would make a lot of sense, but for most of the things I do memory corruption is relatively easy to avoid with good patterns and a crash just kills a local application. YMMV but I think the "safety" of Rust gets a little overhyped.. most the bugs I run into are not memory safety bugs.
The safety aspects do get very hyped. It's better to consider the language strict about correctness; memory safety falls out of that, but so does other stuff, like less logic bugs.
Thing is, this is from someone that likes Rust, but for various reasons has to reach out to C++ when going outside my daily use of managed languages, while C++ will never be as safer as Rust, there are many tools to get us half way there.
The big problem is that many projects keep ignoring those tools, the way Zig sorts out reporting use after free errors, the same solution exists for C and C++ for about 30 years now.
If you allow, I’m curious:
If you felt familiar with the language just as much as with C/Zig/Odin, would you prefer Rust for a completely greenfield project that requires no C interop (or none more detailed than say providing a general ABI)?
Just my opinion. It really depends. For systems- kind of software (low-level, DBs, file systems (also user-space)) no, I wouldn’t - if you manage memory with arenas and/or can plug in an allocator to tell you if you leaked memory (provided the codepath is triggered), I mostly get what I want with less mental overhead. Also, I very often want to interface with C libraries.
For games, again, I wouldn’t. I again strongly suspect I would and could organize my use of memory better.
I suspect Rust is best when you don’t want to interface with C code (except through bindings others wrote) and you’re maybe more doing applications development where C++ has also stood strong.
I completely see how, theoretically, Rust can make a great language for an office suite, browser and so on.
That’s actually also when I tried Rust for a personal project. I wrote a desktop application and while I spoke to C code, I only did so through bindings others had written.
It was/is fine :) I still got a segfault bug though hehe.
Basically I liked Ocaml so I have huge appreciation for all that Rust tries to bring into the mainstream on that front. I am just not thinking that the borrow-checker makes it well placed to interop with C. It becomes much better for relatively isolated applications work.
I like my datacenters like I like my railway infrastructure - covered in enough protective layer of rust that it will never suffer structural damage even when running for years under extremely heavy load.
> I think the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
You hit the nail on the head there. Zig is 10 years old now and it’s pretty clear that the industry isn’t biting, compared to the behemoth that is Rust. Between Rust, C, and C++ there is very little room for another language with a woefully incomplete library ecosystem to establish itself.
A true competitor would need to offer genuine extra value, such as dependent types or other formal verification features, to carve out a niche.
There is also the fact of newer "closer to C" alternatives like C3[1] and Zen C[2], or more intriguing C family alternatives such as Odin[3], Jai[4], or Vlang[5].
Zig is kind of trapped. It can't go "head to head" with heavy weights like Rust, who specialize in safety, are more mature (post 1.0), and have lots of corporate support. Then there are the other C alternatives, who each offer something it doesn't have.
It appears the only way for it to maintain its position, is through heavy hype and marketing, but the whole Bun ordeal and extensive beta issues are subtracting from any such attempts.
The industry isn't biting @ Zig because it's unstable, notoriously difficult to integrate new changes into an existing codebase and because the compiler is a bitch to develop with (hard error on unused variables with no way to turn it off).
Not sure that last one rings true. There are entire languages with no allowed unused variables (some without prepending a _ to the names) that people love to develop with.
In the industry, how often is it that a tool/language is picked up for the ease of developing that tool, vs ease of using that tool?
> it’s pretty clear that the industry isn’t biting
Zig isn't finished yet (they still have not released a v1.0). They're still iterating on the language itself and want the flexibility to make backwards-incompatible changes while they do so.
So in a sense, they have not yet asked anybody in mainstream industry to "bite." After v1.0, when there's an understanding of stability and ongoing language support, industry adoption or lack thereof might become a relevant metric for measuring the project's health. But right now that's not relevant at all.
I hear you, but Zig is also 10 years old now. While the authors may not want to signal they're ready, people make assumptions based on age regardless.
Either users think (a) it's actually ready after a decade, since many langs/libs are conservative with jumping to v1.0, or (b) they'll think it's [a toy/a side project/run by perfectionists] that's not ready for production, and might never be.
This isn't exactly fair for those who want to just take tir
> A true competitor would need to offer genuine extra value, such as dependent types or other formal verification features, to carve out a niche.
believe it or not it is generally easy to do this with zig with few modifications (WIP), and the team has said publically that they will be making this sort of thing a supported operation once the IR stabilizes post-1.0.
This is just a dumb take, hardly any language is immediately popular. Python, Ruby, etc. were still pretty niche 10 years in. Pretty much every popular language is 15+ years old.
> I think the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C for any serious use
I promise you, hand on heart, that literally no one on the Zig core team is wasting their time on thoughts like this.
> and their flagship project has now abandoned it.
Quoting Andrew:
> So, when the Anthropic aquisition finally happened, we at ZSF breathed a sigh of relief. When the donation silently stopped, our bank account was ready for it. When they neither canceled their monthly meeting with us, nor showed up, we were not surprised. The relationship was over.
I advise you to take this paragraph at face value. Again, I promise you that it is the truth.
> Removing #define alone would have been worth it.
If you reach out to any project manager and pitch the idea to rewrite a whole app from scratch because you want to get rid of #define, first you will be laught out of the room and second they will reach out to HR to get a PIP going because whatever the hiring bar they used to hire a developer you clearly are not meeting it.
If TigerBeetle is the Zig flagship then Zig is untenable for almost any team, because Tiger Style is untenable for almost any team. No, I think that Tiger Style makes Zig mostly unimportant.
On the other hand, as a corporate backer for Zig, TigerBeetle is definitely a big deal.
But in terms of exemplary and imitable projects in the ecosystem I would think something like Ghostty is the safer label for "flagship".
TigerBeetle has a unique static memory allocation strategy at launch time. It’s a strategy that sidesteps a lot of memory management issues but only works for very specific use cases.
Their success with this strategy isn’t portable to most other projects. I think they really need more traditional flagship projects that generalize to typical memory management use cases. The way the conversation keeps coming back to TigerBeetle as a success story isn’t helpful to anyone trying to evaluate the memory management angle.
I would say the exact opposite, actually - Zig is a language specifically suited for TigerBeetle's all-at-once approach to memory management, and the approach more commonly used in Rust (allocate wherever and whenever) is non-idiomatic in Zig.
TigerBeetle calculates all the memory it needs at startup. It allocates that much memory once. It does not allocate memory dynamically.
This only works for very specific use cases, like a fixed server size where you know exactly how much memory you want to allocate to a process.
It’s not portable to general purpose computing, where it’s expected that apps aren’t allocating the maximum amount of memory they might use at startup. Their memory usage grows and shrinks as you open and close files or as your documents get longer.
> and the approach more commonly used in Rust (allocate wherever and whenever) is non-idiomatic in Zig
Allocating memory as needed isn’t a Rust-specific idiom. Most programming involves dynamic memory allocation.
I don’t think the Zig developers would go as far as saying Zig isn’t a good fit for dynamic memory allocation. If it was that simple this entire debacle could have been written off as “Bun requires dynamic memory allocation by nature, therefore Zig isn’t a good fit”. That’s not what Andrew Kelley is trying to say though.
> This only works for very specific use cases, like a fixed server size where you know exactly how much memory you want to allocate to a process.
So, like, the JVM with its "initial heap size" setting? After reserving that space from the OS on startup, pieces of the space are then handed out by the JVM's internal allocator, where and when needed.
If initial heap size and max heap size are the same, that initial one is the only malloc() call that ever happens. Not as common for desktop software, but a common best practice when deploying JVM applications to servers.
(I think we're perhaps tripping over two different meanings of "allocate" - you can "allocate" in the sense of calling malloc(), and you can "allocate" a piece of that reserved memory to a particular scope/function/object without actually calling malloc.)
> Allocating memory as needed isn’t a Rust-specific idiom.
There isn't such thing as "The JVM", there is a standard with several implementations, which one with their own approach to memory management.
You might be mixing it with the reference implementation for the standard, OpenJDK, and even then, it depends pretty much on which set of configuration parameters are given.
The funny thing is that Rust works perfectly fine with statically preallocated memory. It's not even against its idioms - most code will work with zero changes. In a way, the borrow checker is the perfect tool for this situation, since nothing owns any memory and everything is borrowed from the static allocation.
There's definitely one code change that's needed - you need to override the Allocator being used by standard library containers (or, live without standard library containers) and by any third-party dependencies you have. That feature is not even stable, let alone idiomatic.
Using the allocator interface is only required if you allocate, which in this context you explicitly don't. If you want to use static preallocated memory in Rust, you'd have to use #[no_std] and only have access to the core part of the standard library. On the plus side, this is a very well supported and stable configuration, the core library is still pretty rich, and there's plenty of no_std libraries to choose from in the ecosystem.
I used "most" in the pedantic sense of "just a little bit over 50% if you count individual lines and not whole libraries". Most code doesn't operate on Box, Vec, String etc. directly, and is happy with & and &mut to underlying data. And even when it does, it's usually used for giving static lifetime to data, which is a non-issue here because all your preallocated memory has static lifetime already.
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 embedded niche, aimed at complex multithreaded code that has to combine high performance with not catching on fire because someone fucked up concurrency once again.
But the main issue I had with Rust - that it's frankly a bitch to write, nearing Go levels of awful, only worthwhile if its paradigm is buying you a lot - is diminished if it's an LLM that's doing the bulk of the line to line writing.
And, on the other end, C's warts, footguns and ancient quirks also matter less if you have an LLM plow through it.
So, the niche for Zig does seem to be shrinking. The window for it to establish itself might be genuinely closing now. Which is a shame, because I like the idea of having "better C" a lot. But all of this drama sure isn't helping it gain traction.
> 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.
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.
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.
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.
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
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.
"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.
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.
AFAIK zig is not trying to be "better C++" (that is Rust), zig is more like "better C". a ergonomic low level lang with very little abstractions. zig explicitly doesn't want to be better C++ or rust
I would go further and say that anyone who doesn't immediately identify this either isn't thinking clearly about this, or is intentionally ignoring it. I have no horse in this race AT ALL and this is _obviously_ the advantage.
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.
You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did). But either way, you're still stuck with a code base that's going to need extensive refactoring if you want to actually take advantage of rust.
Which is still a step ahead of Zig, which requires an entire rewrite to have the tiniest shred of RAII or borrow checking. What's your point, that if we can't do everything perfectly in one step we can't do it at all?
First off, you seem to be under the impression I'm a rust hater. Noting could be further from the truth. Rust is easily my favorite language at this point, I reach for it for basically everything (except quick scripts). While I do like a lot of zig's philosophy, I think at the end of the day the empirical evidence is overwhelming that manual memory management isn't sufficient.
> What's your point, that if we can't do everything perfectly in one step we can't do it at all?
My point is exactly what I initially said: you typically aren't much closer to a (mostly) safe rust codebase if you've done a line by line port to (partially unsafe) rust than you were to start with. Getting to safe rust is very likely to require substantial refactors either way. This doesn't mean you shouldn't do it (on it's own), but it does mean that the bun team's strategy/assumptions are more questionable than they appear to realize.
I didn't say they made a good, safe port. I literally said the opposite ("especially if you're flexible about actually upholding rust's rules"). You can get a line by line port to compile by just wrapping the parts that violate rust's ownership rules in `unsafe`. You won't have fixed the problem, and it won't be memory safe, but you can do it.
Well, only if Clone/Copy is compatible with the semantics of the API. I.e., the called function doesn't need to modify anything. No &mut params (or data members) except perhaps `&mut self` (which would refer to definitions the same file).
That's usually the case for Rust programs because the language encourages it. Are Zig programs like that?
To be fair, you can throw an Arc<Mutex<_>> or Rc<RefCell<_>> at it if you're starting from something that has multiple "mutable borrows", but that adds runtime cost and complexity.
This is not done by blindly porting Zig code 1:1 and calling it a day. You do have to make conscious decisions about code architecture to manage Unsafe code, since you need choose the right invariants for your Safe Rust code to conform inside the module (Note that unsafe pollutes the whole module containing it, not just the code inside the unsafe block!)
No one involved in the port proposed "blindly porting Zig code 1:1 and calling it a day". From the first blog post the creator said:
> We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships.
What the rewrite does is make the unsafe code greppable, which is a necessary first step to eliminating it and one that's actually achievable rather than going straight to idiomatic.
Every successful refractor takes this form of stepwise changes that leave the behavior intact. It just so happens that in this case the first stepwise change was the implementation language.
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.
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.
Except the blog post shows that they fixed a hundred or so known issues, patching several memory leaks and making the project viable for Prisma Compute's adoption - which it wasn't before. It's now running in production in two places just fine.
Can you point to an equal number of issue tracker tickets showing novel bugs or regressions in the canary build?
Yes, they have introduced (at least) several times more memory safety issues by violating the rust specific rules. Check how most of their unsafe blocks are unsound and worse, how many are straight up incorrect with a total bs // SAFETY above it, leaving no sensible usage without invoking UB.
We often ensure a project holds water against miri. This one doesn't even pass for clippy.
You realize that what you're describing is inherent complexity in memory management? This is not something that you can dodge by using Zig, it's just part of the domain.
The difference is that in Rust you get strong guarantees for everything that is not inside of unsafe and clearly demarcated areas where things might go wrong. Even if you never eliminate a single unsafe block, the clear demarcation is valuable as an artifact in its own right.
The art of Unsafe Rust is marking the right demarcation with the right set of invariants that Safe code must adhere to inside the module that uses Unsafe. If you do this incorrectly, then even Safe code outside the unsafe block can cause undefined behavior.
Which is why having unsafe code without exactly specified invariants is practically useless: the Bun rewrite code has too many SAFETY comments that are incorrect and misleading, so most of the unsafe demarcations aren't helpful in achieving UB-free code.
Is there a "Rust compiler's rule" you can point to that's harder than avoiding UB in C or C++ in similar circumstances? They strike me as very similar beasts.
This is nonsense. There is quite a subset of C which is perfectly safe and an even larger one which can easily be safe with tooling. You could argue that unsafe keyword is easier to spot than the unsafe features of C, so that makes it somewhat easier to screen for issues. But if you screen for memory safety only, this is problematic anyhow.
You do have to inevitably use unsafe because of FFI (Bun uses existing C++ modules like JavascriptCore for most functionality). Optionally also for performance (at least if you want to win Deno on that front)
The post starts off so cynical. I know a few people at anthropic and oai and the simplest explanation also matches my observations that they actually believe what they say. That agents will be doing the bulk of the programming in the not so distant future. They believe they themselves will be out of jobs at that point.
They aren't managing some message and trying to teach the anti AI folks a lesson.
Then they are naive. I've seen this a lot first hand during my PhD. Interpreting results in a way that reinforces their beliefs and ignores alternate hypotheses.
Frequently, those alternative hypotheses are demonstrated to be true. For example, "emergence" as was researched and proclaimed by many labs, including places like OpenAI and Anthropic is due to using too few discrete steps in sampling a continuous phenomenon. See "Are Emergent Abilities of Large Language Models a Mirage?" [1] for example.
The number of people who think the emergence thing is settled smh... It's been a thing for at least 30yr, answering it one way or the other would be a big deal. It does nobody any favors having these infinitely capitalized hype firms calling themselves "labs".
Sadly, like intelligence and reasoning, I think emergence is a word that people discuss while having different understandings of what the word means.
In the paper I linked, they talk of a particular take on the word that is commonly discussed in the ML research: between one discrete step and the next a phenomenon came into existence without existing before (i.e. it occurred spontaneously). The paper then goes on to refute specific claims. That's all I'm pointing out (I could point out similar issues with research into reasoning).
I think it's difficult to pin down "emergence" in the general sense as it likely goes into a deep philosophical argument like consciousness, so I'm unwilling to state whether or not some notion of "emergence" actually takes place. In that sense I agree with you.
> They aren't managing some message and trying to teach the anti AI folks a lesson.
Unless you know the senior execs in charge of marketing at these companies I don't know how you can make that assertion. I believe that a lot of the folks at these companies earnestly believe in the work they are doing. But a belief held by software engineers is not automatically shared by the marketing department, nor by senior execs.
"Anthropic is a giant company with a lot at stake and will seek to capitalize on any marketing opportunity" doesn't strike me as cynical so much as a statement of fact.
But it’s really the same old problem we’ve seen for decades. Developers write code. Owners declare victory. Owners rid themselves of expensive opex. Owners sell the division or try to keep the project limping along but all they see is vaguaries from the new cheap guy who they keep telling isn’t good enough for a raise, company hemorrhages money and eventually sells for a song.
They’ve just found a way to explore that logical fallacy even faster.
Owners and developers. I've been thinking about this a lot lately. Years ago, maybe in the late 2000s, when startups were becoming culturally significant, and "Tech" became an "Industry", two books were written and published: Founders at Work by Livingston, and Coders at Work by Seibel. I read both, and recall the Founders-book being a bit of a slog -- I only read it once[0]. The Coders-book, I have been re-reading it for more than a decade. I am sure there are many people who would express the _opposite_ sentiment.
The existence of _two_ books, published by the same publisher, within a few years of each other, is a kind of tacit acknowledgement, that there are two categories of people (Owners/Founders and Developers/Coders), that have a kind of symbiotic relationship with each other. That relationship has always been a relationship of convenience and gain, not resonance and understanding and appreciation.
It is, in a way, similar to globalization: nations will support it, only to the extent that it can make them (or their elites) wealthier, and not because they actually care about peace, or the magnificent diversity of human culture and creativity.
Just as the globalized economy is fraying, so is the symbiotic relationship between Founders and Coders. I think it started with the pandemic, which caused (without pointing any fingers) a tension between Founders and Coders, and has been accelerated by LLMs. In some sense, the tactics that were use by Tech companies to wow and win customers outside of Tech, are now being used by Tech companies on other Tech companies. And those tactics involve making grand promises to people who have knowledge-gaps, and are otherwise easily impressed.
I did not realize that there even was a symbiotic relationship, until I analyzed US degree-completion-rates for 1970 to 2011[1][2]. I suppose it should have been obvious, but these things are difficult to perceive from the inside (even if you've been working in the industry for an entire decade). The big problem is that the symbiosis is asymmetrical: founders get the money, and pay the coders, and are able to fire and replace coders at will, while coders can do none of this to the founders. This may have been fine, in an era where layoffs were rare, and getting a replacement job was less uncertain. But I suspect that the contest we are going to see in the next few years is: can Founders out-code Coders, or can Coders out-found Founders. Note that the Viaweb story (the archetypal startup-story for HN), is a story of Coders out-founding Founders (the equivalent of the late 90s era, did not found companies so much as administer small parts of them).
[0]: This is not a criticism of the author/interviewer, nor the interviewees -- the subject matter simply did not intersect enough with my own obsessions and fixations. I wish it did. It feels like I have some kind of color blindness, when it comes to "founder-y" things.
[2]: If you do not want to read all of that, here is a TLDR. The percentage of informatics-degree-completions never drops below 2% (which confirms an informal observation Knuth has made many times -- see his 3 or 4 oral histories and his interview in Coders at Work). The percentage of informatics-degree-completions rises and falls with business-degree-completions (the symbiosis is visible here). It never exceeds 4.5%, and such doublings coincide with bubbles (the dot-com bubble, and the 1980s AI-bubble -- there is a history section that helps narrate these numbers). Most intriguingly, informatics-degree-completions are _perfectly inversely correlated_ with healthcare-degree-completions -- their first-derivatives are nearly perfect mirror images. Also, the majority of graduates are business-graduates (accounting, administration, etc -- economics belongs to social-sciences instead of business), and their numbers have doubled since 1970, at the expense of social sciences and education (I suspect that this has had an impact on our (both global and American) culture akin to the impact that climate-change has had on our planet, but I have no data to put behind that suspicion, yet).
> 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.
I'm not convinced this explanation is self-evident enough to assert without any justification. I can think of at least one other plausible one, which is that maybe most side projects in general get abandoned after a certain amount of time, and being able to write the code a lot faster means that the point of diminishing returns for personal utility, enrichment, or pleasure are reached a lot faster.
> 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.
As entertaining as that article was when it came out, I think its apparent wisdom should have been reevaluated for at least the past two decades. Even back when it was written, its pertinence was questionable, since it hinged on the perception that written code has particular value, to justify much of the failures at Netscape and Borland, neglecting many of the other -- probably more relevant -- business and human factors that were at play within the two organizations and their surrounding ecosystems. But lessons learned from watching startups fail in trove in the following two decades have mooted many of Joel's arguments. With the vantage of hindsight, if you read JWZ's account of what went on at Netscape, some of the dysfunctions become glaring.
Making software projects successful has always been about a lot more than just writing code. People have been "rewriting code from scratch" successfully even before LLMs. We just don't tend to call it that. We call it "cloning", "competition", "copy", "alternative-to", "reverse-engineering", "x-written-in-language-y", etc.
It's funny, but I think the article is showing it's age. It's no longer true.
In hindsight having automated auto complete rewriting your code base wasn't something on 2000's radar.
Now switching from language to language is much easier. Just for Rust, there was Ladybird and Bun complete rewrite, that ran into zero things that Joel rallied about.
> It's funny, but I think the article is showing it's age. It's no longer true.
Joel argues 2 effects:
# Developer & time-cost of a rewrite is a big unknown. That's still true, but LLMs may cut that down by a factor of 10x or more. You cut time & developer-hours by throwing tokens ($) at it. An optimist might say this cost has vanished.
# Shipping a rewritten product is -by itself- an unknown risk. That still holds. You can do all the testing you want, but your test suite != your clients environment(s? multiply by number of users or target platforms).
A single bug that pops up in the rewritten codebase (which wasn't in the old one) can hurt a vendor's reputation badly if the stars align just right.
All in all Joel's article held up pretty well (esp. given how long ago it was written).
> Developer & time-cost of a rewrite is a big unknown... An optimist might say this cost has vanished.
I wouldn't say it vanished. I'd say it moved from unknown to known. It's highly likely that for code the size of Bun the price is around 200k dollars of tokens + a month of programmers time to monitor it.
> Shipping a rewritten product is -by itself- an unknown risk. That still holds. You can do all the testing you want, but your test suite != your clients environment(s? multiply by number of users or target platforms).
Fair point.
That said, it seems the number of relevant platforms is shrinking. Both on the hardware side - x86_64 AMD, x86_64 Intel, and aarch64. On the OS side, you have Linux, Mac and the dying Windows.
Still, it seems with enough tests and original source code, you can limit this risk to a few edge cases.
> All in all Joel's article held up pretty well
Aside from the fact that it mostly applies to commercial endeavors[1], it still missed the mark on old code decaying over time.
Turns out being exposed to the Internet has a chance to turn even old code sour.
[1] If you don't care about your users, or you care more about pleasing/attracting new developers, then points made in his article don't make rewriting it that bad.
I think it was always hyperbolic to call rewrites the single greatest mistake (I can think of worse) but I think most of the wisdom still holds. And AI generated rewrites are arguably riskier because now NOBODY is familiar with the massive codebase.
>I don't think Zig community should get triggered on any of this.
As far as I can tell No one from Zig community got triggered by this other than the Zig team. People were angry about Bun switching to Rust not because it is abandoning Zig, but this reckless behaviour of not letting users know up front, no migration path or two parallel version testing and basically trust AI on everything.
The internet was pretty much on Zig's side or at least between Bun and Zig they were Anti-Bun for a lot of things. That was until Zig's reply.
Yeah, I was just commenting on a LinkedIn post[0] (don't hate the player, hate the game :) ). In it, someone talked about the difference between creating software and owning it.
Creating software with AI is super easy--plan, prompt, test, go, go, go!
Owning software means you're responsible for maintaining it over time, fixing edge cases, operating it well, and more.
If you're building a one-off custom webapp to meet your needs, create away. If you're writing software for a business to run on, you're owning it. My fav article on this topic is this post[1] on durable vs disposable software.
I don't think Zig community is triggered, I think only Zig's creator is triggered because he is afraid of people interpreting this as "Zig is unsuitable for X".
I think a lot of people will, but those who do probably weren't the target audience for Zig in the first place?
Context matters. Big announcements and uninformed blog posts can kill your momentum.
I still remember the Twitter dev blog where they abandoned Ruby/Rails and the damage that did. It turned out Twitter was doing a lot of stupid things and there was a mismatch of tools and their goals. They loudly blamed the tools and people ate it up because Twitter was big, visible and adored at the time. Their conclusions bypassed most people’s ability to reason.
I remember that. It was the first time I heard about Scala.
I saw a lot of RoR companies/users thinking “should we do the same?” without even realizing that they do not have the same twitter scalability problems.
The same engineer at Twitter decided early on that no distributed messaging technology was good enough for Twitter, so they wrote their own. It fell over and they threw it away and wrote their own again. It fell over and they threw it away and now they use mainstream tools.
Similar to Discord's migration from Go to Rust. The measurements and reasons they gave were true but even by the time of the migration, Go had already moved on and improved. They were using an old version of Go.
Rust might be the right choice for Discord, I've no idea about that, but the problem is that the blog post lives on and influences people to this day.
I've run into a bunch of segfaults in Bun whenever I went slightly off the beaten path, probably from the "horrifying" Zig code. A huge test suite + a clean rewrite with a path towards more safety is how I would go about it too, personally. Now whether I would do that rewrite in Zig or Rust, I'm not sure. But I have high hopes it's going to work a lot better, especially since Anthropic uses Bun heavily.
Are LLMs better at writing Rust than Zig? I'd assume so, there's way more Rust open source code than Zig. And if so, that's a very solid reason to switch IMO.
I think the mistake people are making currently is that they publicize stuff way too early. I.e. they make a prototype and then put that out there. Possibly with a full product page and all.
People did this also before LLM, but the difference is that now the prototype is a fully functional product in the technical sense whereas before it was little more than a glorified Hello World. The human effort and calendar time used remains roughly the same.
There's gonna be amazing products made with LLM, but it'll take some time. Not as long as it did before, but still significant time.
There is going to be something that would not have existed without LLM because there wouldn't have been enough resources to create it before. Probably already is. Some of it will be amazing, although most of it probably not.
Example: Qobuz has no official Linux client, but there's https://qbz.lol/ which it seems to me is mostly vibecoded. It's not perfect, but it works pretty well and can do some fancy stuff like bit perfect DAC passthrough up to 192kHz/24bit.
I hear you, and those are good applications of LLMs: create something that didn't make economic sense before.
But I'm asking something slightly different. I'm asking about something that's amazing, not due to a different economic calculus, but something that's AMAZING that would not be possible to create by humans.
> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.
No, this is a classic mistake. The value of a project is in the instantaneous utility it provides integrated over time. Some things are valuable because they are throwaway single shots that do a thing that's hard. In the past, making those was too costly for the value, but as software drops to near-zero in marginal cost they're worth doing.
e.g. the costco receipts site involves clicking through to view receipts and only 10 'view receipt' buttons per page. I might have stuck it out in the past, but instead I just described the problem to my claw-like and gave it my user/pass and it found it for me while I was dressing the baby. It wrote some Playwright code and this and that and drove the browser interactively.
That code is throwaway code but it was quite useful.
> To me it reads like Bun was forked. Will the Zig version survive? Will the Rust one? Both? All options ok.
Maintenance of the zig code was abandoned, while the port continued in the same repo, and it's unlikely any work on the zig branch will keep momentum. So yes it forked, but more in the fork+exec sense (or maybe just exec, the analogy's not that great).
According to Andrew, bun-zig is not something some brave soul would be eager to maintain.
> We became increasingly horrified at the programming practices we saw in Bun's codebase. Hacks on top of hacks. Abuse of assertions. Most of all, recklessly speeding past feature after feature with very little time taken for reflection and elimination of bugs and technical debt.
Just "1MLOC JavaScriptCore wrapper" is enough to figure out why.
How many lines of code is Node, which is a wrapper for v8? I'm aware bun is not great quality, I tried and abandoned it myself, but Andrew's consistently bitter and spiteful tone makes him the worst conveyor of his own message.
I think the line is between AI-generated and AI-assisted - I have AI assisted projects that I have happily been developing for several months and they are going fine, I feel just as engaged with them as I did with my hand coded projects, but also I am more engaged insofar as I actively manage the architecture and the code, and see to it that the AI is following the plan I have in mind.
people chasing after "one shot" code certainly aren't helping, I agree.
> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.
It is in the marketing. Most software engineers are not skilled at marketing, do not have a large audience, and are not willing to spend money on advertising. It has nothing to do with code quality.
I wonder if new version of Bun has the same emotional values in Jarred's mind, I mean he did write it by hand and struggled for a long time and invested a lot of energy.
Meanwhile the rust rewrite just magically appeared to replace it.
Which one is more valuable for a person? High Effort or low effort?
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.
> 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".
Another definition: Rust is a lang to "Run fast and low-level software/firmware, with nicer tools, features, and syntax than the other langs which can do this"!
Obviously, the value proposition you find in this case depends on the subjective nature of that regarding rust vs zig!
I don't think I agree with this framing because "definition" implies comprehensiveness in a way that "here are some properties which may not cover everything that's relevant" does not. Your "definition" implicitly ignores the safety mechanism that Rust has and Zig lacks, which does a lot of rhetorical work into making it seem like the only difference is in "flavor" rather than "substance". My argument that there is a meaningful difference in substance, just not the one that the parent comment (and plenty of others) expected.
"safety" is not why I use and love it. I brought this up because someone who hasn't used Rust, but reads about it may assume it's a "safe" language; I would describe it instead as a nice all-around language.
I don't know if I totally agree with your characterization here either. I'd argue that if you're not actively writing unsafe code, then you are using it as a safe language, in the same way that Python and Java are also safe languages. Yes, I also think it's a quite nice language, but safety is important enough that any time you're comparing a language that can be used safely to one that fundamentally can't enforce safety, framing the choice as purely ergonomic (even implicitly) is misleading.
I think their original post lays out the benefits pretty well. I think the realization of some of these benefits is debatable (for example, they probably could have made their existing Zig code faster), but others are straightforward (like having fewer crashes because more of your code is provably “safe” in Rust terms).
(I think wrapping a large, complex C/C++ codebase is where Rust often shines, if you build the right joiner abstractions. PyO3 is a really great example of that.)
> making sure the JIT doesn't emit anything broken or naughty is completely outside the scope of Rust.
It's also outside the scope of the project if they're using Webkit's engine for that part. Which means Bun itself isn't a JIT, it's all the stuff built around the Webkit JIT, so whether or not Rust is useful for the JIT is entirely immaterial to the question of if Bun would benefit from Rust.
They listed some of the memory bugs they had in the blog post, I just looked at three of them, the first one was this:
> heap-use-after-free crash in node:zlib when calling .reset() on a zlib, Brotli, or Zstd stream while an async .write() is still in progress on the threadpool
It has the same guard in place as the zig and c++ versions, the rust code also just calls into the zlib bindings after the "write in progress" check.
So in this case at least the same exact use-after-free would've happened and they don't win anything from the rust port.
Another one was this:
> crash and out-of-bounds read in Buffer#copy and Buffer#fill when a valueOf callback detaches or resizes the underlying ArrayBuffer during argument coercion
I can't judge the Zig code, perhaps someone could say if this was a "beginner" mistake.
But this is at least one case where Rust would've helped, although even that is a bit complicated considering stuff like bun_ptr:
// Lifetime-erasure helpers (RUST_PATTERNS.md §6/§18) — re-exported here so
// crates that already depend on `bun_collections` (logger, css, js_parser,
// crash_handler, watcher, http_types) can route the borrowck-dodge through
// one centralised `unsafe fn` instead of open-coding the lifetime cast.
pub use bun_ptr::{RawSlice, detach_lifetime, detach_ref};
I've always viewed unsafe Rust as a sort of last resort you use when you just can't do something safely. Porting something to "unsafe Rust" to me feels pointless, and of course this hasty rewrite was probably not the best idea from any perspective.
If the end state were unsafe Rust, you'd be right, but that's explicitly not the intended end state. Unsafe Rust was the reachable first step. Now they have a Rust version and can iteratively remove `unsafe`, which they couldn't do before when it was in Zig.
It's the wrong abstraction though and I am kind of not surprised the Bun maintainers went way. The correct abstraction would be to translate into Rust while using `clone` and `copy` liberally and then iteratively converting to a borrowing model. Nowhere at all was an introduction of the `unsafe` keyword needed.
That's only the correct abstraction if you intended to hold off on releasing the rewrite until you were completely finished, because there's no universe where Bun of all projects releases a production version that uses clone and copy liberally.
Unsafe in theory in a transliteration is only as unsafe as the original Zig was, which makes it a perfectly reasonable place to land as a transition point in a way that introducing large numbers of allocations simply isn't.
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.
That battle tested bit is so true, always was. It’s hard for engineers to admit their hard work is worthless until they have let other people use and shape it.
Honestly I also think most vibe-coded projects are just.. kind of bad ideas. Which is fine! It's good to be able to determine an idea is bad quickly, there's value in that, but I think people ignore a really important aspect of creativity: the insights you need to have a good idea come from struggling in the muck and struggling in the medium. It's really hard to have good ideas from an ivory tower, you need to get into the details.
> Existing Zig codebase has seen X amount of battle-testing. Rust rewrite: 0 (except -I'm assuming- passing test suites).
Not taking a side here in the whole Bun vs. ZSF dispute, but isn't the entire selling point of Rust that you get a bunch of battle-tested guarantees simply from compiling the program? Is there even a metric for battle-tested? I would say something like sqlite is battle tested vs a vibe-coded network server in c, but does that mean rewriting anything in rust truly mean starting all the way back at square one?
Also, didn't Anthropic roll out a version of CC using the Rust rewrite of bun? Surely they didn't just say "works on my machine" and chuck it into production?
That's such a bad take. You mention some good things they need to do but ignore the part that those are next steps and will take time.
You are acting like they need to complete everything at once...why?
Bun (rust) is not even released as stable yet and getting extensive usage on Claude code. They are making improvements and fixes. So what's the issue here?
> Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?
Because we have a near infinite number of artificial monkeys figuratively typing at a computer keyboard and, once in a while, they spout out something that looks like an acceptable program.
But it's not acceptable: it's sloppy-pasta.
> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.
Yeah. I don't know if we live in the same world as some other HNers: I pay not one but three AI subscriptions: Google (through Google Workspace), Open AI and Anthropic. I'm switching from Claude Code to pi.dev atm.
I'm using LLMs daily. The person next to me too.
LLMs produce shit code. Pure unadulterated shit.
They're extremely useful for many things, including finding bugs. But, to me, they simply suck at fixing them. They write horrible, verbose, code full of bogus assertions and cases that are not handled or not handled correctly.
I do verify the output they produce: the number of time it "works" but I look at the code and see sheer horrors and say stuff like this: "wait, if you replace A by B like you suggest, shouldn't thing X that A makes be done too?". (it's a rethorical question: I know I'm right).
"good catch".
No. It's not a good catch. It's a totally obvious catch that any programmer who's been in this since more a few years (a few decades for me) would catch instantly.
Now if there's one area were they're semi okay'ish is for porting code from one language to another. At least you get a base to start from: if you're lucky. And I suspect it's only looks good if you don't know much about the target language.
Also don't be fooled: we're talking about a company with tens of billions investments that fully knows AI is not enough. You can be sure there are countless programmers fixing, behind the scene, the sheer mess that their AI (with unlimited budget btw) is creating. And then they pretend it's a 100% automated AI rewrite.
AI is not only definitely not enough: it's useful for finding bugs, it's a good rubber duck, but the more and more time passes, the more I'm appalled by the shit code it produces and by the errors they make all the time.
If I wanted to be facetious I'd say that at least we're already --how things moves fast-- long past the point were the kool-aid drinkers explain to us that these thing are intelligent.
It's summer 2026 and, as I type this, the SOTA models all suck at writing code.
Am I still deep into it? Sure am. For basically everything but coding (finding bugs, documentation, translation, generating assets, automating dumb stuff, ...).
Oh well, going back to pi.dev facepalming myself and rolling eyes. I know it's going to be "good".
It's more than just the battle testing. Things that are not wanted by a community or by users are not important. AI delusion memes are fairly reductive but a commonality I see in many overtly ai evangelistic groups is an urge to build without motivation and agreement. The yes we can answer AI gives to user's every question is a failure mode trigger. LLMs are missing the filter an engineer with a human body may give you to an idea...
Totally disagree that the value of a project is it's durability. The value of the project is almost entirely disconnected from durability. Value is simply the ability to solve a problem for you. I'll use a bad screwdriver before I use my fingers, even if I prefer good screwdrivers.
Claude Code was a vibe coded experiment, a "what if", that basically consumed software engineering in six months flat. Not because it's durable (it's not), but because the value it provided was so overwhelming.
People will use bad software if the value it provides is high. People will avoid the most durable and battle-tested software ever written if it doesn't actually provide value (solve a problem for them).
"How is that better than the Zig codebase you started with?" - It will be worst, as this will not be idiomatic Rust. That's kind of interesting, BTW, as in next iteration LLM will be trained on tones of crappy code, created as some random rewrites, AI slops, etc., I am curious if someone will be able to curate this or it will be the same process of crapification experienced by Google Search that finally lost the battle with SEO spammers.
> How is that better than the Zig codebase you started with?
It's worse, and I say this as an avid Rust fan and programmer. Try Miri with the new Bun project. It's currently blowing up. The Rust compiler's non-unsafe aliasing rules still need to hold during unsafe, which are far more complex than writing correct Zig code. That's the trade-off about Rust: The compiler has a ton of clever proofs for safe code, but if you're on your own, you'll have to do the work yourself.
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, might subject me to this kind of article from their BDFL. I can’t conceive of the leadership of the Python or Rust or any other community I’ve ever worked with doing something like that.
>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 more welcoming community, the remainder will be more concentrated.
Not GP, but I don't think a specific other community was being specified. It's more like some hypothetical other community whose primary characteristic is "not Zig".
>What Bun did here is basically a sabotage of Zig's reputation.
No a single soul thought Bun was doing anything against Zig's reputation apart from a few people in Zig. They are the one being over sensitive. When the whole internet was on Zig's side and not a single soul which are normally on Rust came it to support. But somehow it is sabotage of zig?
There is a whole lot of different between being rude and direct to a person on technical issues, such as what Linus used to do on kennel list, and a personal attack that goes beyond the initial point.
You say that as though it somehow justifies the comment.
Github employees are just that: employees, of one of the biggest companies on Earth. Someone who would call them "monkeys" is telling us that we shouldn't listen to him.
Which is the right conclusion here. Don't use Zig, don't use Bun, neither are mature products from mature teams. Problem solved.
There seems to be a team sport mentality with AI topic in HN these days. Almost feels like people are picking sides, and thus not being very thoughtful or rational.
Sigh, there definitely an attitude creeping into the community and it's a huge turn off unfortunately.
Yeah, I think AI could well destroy this community. There’s a lot of personal identity tied up in being a hacker (broadly defined), and only some aspects of that identity will be strengthened by AI.
Similar to Go and Chess, AI might make “programming for beauty” more accessible and popular. However it will almost certainly make the act of writing “code for money” much less valuable, which means many people will stop getting paid exorbitant sums to do what they love.
Personally what I loved was never the typing characters or optimizing algorithms; building is better than ever. But I really empathize with those who loved the craft of code golf, algorithms, literate programming, the elegance of micro structure of programs, etc. and who see their world under threat.
> However it will almost certainly make the act of writing “code for money” much less valuable, which means many people will stop getting paid exorbitant sums to do what they love.
Most programmers are not being paid "exorbitant sums". Maybe if you can put up with working at Meta or something. I hate how VC culture is pretending that paying skilled people a fair wage is some horrible imposition on the poor millionaires and billionaires.
>I really empathize with those who loved the craft of code golf, algorithms, literate programming, the elegance of micro structure of programs, etc. and who see their world under threat.
I love all of those things but don't feel threatened by AI. I do weird microcontroller things, I have dweets on https://beta.dwitter.net I have a website for making animations using 50 characters of a custom stack expression code. Algorithms, code golf, asm, inventing instruction sets, working on my own 8 bit cpu design, all that stuff is what I choose to do with my time.
I don't feel like it is in conflict with AI generated code. There's still plenty of uninteresting code that it can do.
I see some people disliking AI because they like solving problems, which I also don't really relate to, because AI presents entirely new classes of problems.
I'm not sure how much of this is just dependent on what kind of person you are, I find it quite amusing to see the ways in which LLMs get the wrong end of the stick and find it fascinating to analyse and counter the things that lead it to go off the rails. Some people seem to have the same experiences but completely different emotional responses.
I have made things with AI that I could not have made without using it, but at the same time AI could absolutely not have produced it without me directing what needed to be done.
I think the animosity to AI is more complex. There's combinations of anger about wealth disparity, a loss of trust, another of Sagan's great demotions, and this weird anticapitalist embracing of a hypercapitalist notion of Intellectual property.
Adding to this is, I suspect a few actors spending money to muddy the waters, from the Russian government, to the discovery institute, to people who just seem to like the sound of their own voice.
Keep responding kindly, respectfully, without assuming you know the internal thoughts of others, and you can influence things in a healthier direction.
> I think the animosity to AI is more complex. There's combinations of anger about wealth disparity, a loss of trust, another of Sagan's great demotions, and this weird anticapitalist embracing of a hypercapitalist notion of Intellectual property.
I think a lot of the animosity is fear. For decades, software engineering/development/programming provided good wages,relative stability, and often satisfyingly challenging work. You saw a lot of people from secure parts of the economy being told to "learn to code," to secure their futures. Now you've got business leaders racing hard to push us into economic obsolescence or precarity (because that's where they want all labor).
It's not some bullshit about "personal identity tied up in being a hacker (broadly defined)" or liking code golf.
I think a lot of the enthusiasm of AI is from people who are too arrogant to read the writing on the wall, and it doesn't help that software engineers were paid so well for so long that many of us forgot we are laborers and confused themselves for billionaires (and adopted billionaire ideology, like libertarianism and opposition to unions).
I was thinking of the Zig community but I agree that there seem to be some tribalism on HN as well.
Possibly the thing that will determine the long term survivability of each will be the respective attitudes of dang compared to Andrew. Putting out flare ups may be a fairly thankless and unending job but it probably is more protective than pouring gasolene over them.
Maybe one day dang will pop and it will all come out in a spectacular rage.
>There seems to be a team sport mentality with AI topic in HN these days. Almost feels like people are picking sides, and thus not being very thoughtful or rational.
If you are financially set for the rest of your life - Pro AI
If you are not financially set for the rest of your life - Anti AI
As someone in the "not set for life" club, I worry a lot about my peers who are blind to the reality of AI progress. You don't have to believe AI is entirely hype to be anti-AI. It can be bad AND real.
We've had this discussion since the first beta of chatgpt was out and you "completely rational" people keep insisting AI is 100% perfect and better than any software developer.
Just because it's better than you doesn't mean it's better than everyone else :)
>and you "completely rational" people keep insisting AI is 100% perfect and better than any software developer.
I don't think I know of a single person who has seriously suggested that.
I think the most optimistic I have heard is that it might be the case that they will be better at some point in the future, with unrealistic timelines suggested,
"These days"? Only if "these days" start in 2022 when LLMs first hit the scene. Everyone recognized in their gut, pretty early on, what they were and what they represented.
I honestly hope that isn’t true. I’ve interacted with some Zig projects (and some people I’d characterize as Zig evangelists, in a positive way), and my experiences with both were very good.
> 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.
my instinct is to step up and defend Andrew: to say that truly, he has strong opinions -- which is to say he _cares_ about doing things right -- but that he's more patient and accommodating than you're judging him to be from this 10,000ft view.
that's kinda weird: you might view this as a personal attack _from_ Andrew against Bun and i might view the reactions as personal attacks _against_ Andrew. viewing it through this lens without our preconceptions ought to make either both parties or neither party look bad, i think? i don't know the solution except to highlight the outsized impact that our individual preconceptions play when judging a situation from 10,000ft away.
I want to be very clear: I don't dislike Andrew (or Jarred). Everything I've seen about him suggests that he's a bright and motivated person, and (like a lot of people, including myself) I suspect he struggles with how is tone is read online versus IRL.
I'm not judging him as a human being. I just think the post does not accomplish his goals, unless his goal really was to write a personal attack.
I think it's weird to say crap like "So and so was a stinky manager" and then be like it's not a personal attack!
I liked Zed Shaw. I liked Ted Unangst. They made solid technical points and they were kinda mean about it. They didn't act like butter wouldn't melt in their mouths at the same time.
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.
It's the "Bun is better in Rust" section which is misleading, where most things could have been done in Zig as well with a comparable amount of work (if we don't count the rewrite itself).
This section can also give the impression that the LLM rewrite itself brought those improvements, which it didn't.
Nor the LLM rewrite nor Rust in itself brought these improvements, extra work did.
The fuzzing thing also does looks bad and nothing was refuted: just by reading the bun post one could think they've been fuzzing for a long time, but it started only a few months before the rewrite, which makes it almost irrelevant: the result never shipped, or only for a short time. The whole thing looks like this: technically correct so hard to criticize because people can tell you "well no, the post doesn't say this!", but deceitful, with important omissions.
But even the dates they’re pointing to as evidence of fuzzing in that post pre-date Andrew Kelley’s accusation that they weren’t fuzzing.
When it gets to the point of having to click HN links to other HN posts which link to a reply in a thread on Mastodon which is splitting hairs over dates that are still prior to the accusation, you’ve lost me.
At best it seems like a more accurate outcome would be to update the original blog post with an edit saying that he meant they only started fuzzing recently and acknowledging the PR from 8 months ago?
I am struggling to even understand what are they trying to achieve? Or do they need a dozens of lessons on basic PR. Especially this is coming from VP of community.
As of this moment, even with all the new evidence being provided on Bluesky / mastodon, it doesn't amount to anything.
> The post implies you were diligently fuzzing your Zig code, while during our calls the Bun team told us that they were not fuzzing anything.
That's not compatible with saying that Kelley made the misleading claims. Bun told him they were not fuzzing. If they brought receipts later that indicate they lied, what should we be left to believe?
I think we can quibble about the Bun post’s factual claims. But I don’t think the post was deceptive or dishonest in its claims. Like most technical writing, it represents a vantage point.
As for ghosting in meetings: sure, that seems bad. I would also be upset if someone did that to me. But you can state that factually without making it into a personal attack. It would even be more convincing.
It’s marketing that is also technical writing. Most companies do this, and IMO we should prefer this over the alternative (which is corporate blogspam).
Compare Cloudflare, the Google Chrome Security blog, etc.
> I don’t think the post was deceptive or dishonest in its claims
Presenting only one side of argument (only pros, no cons, etc.) is deceptive and dishonest. The fact that they were incredibly focused on build time in Zig and didn't even talk about it as a tradeoff going to Rust is very telling.
Are we talking about the same post? This is the one I’m talking about[1], and I can’t see where it’s claimed that Rust’s build times are better. Apologies if I’m missing it.
(The one reference I found to Rust’s compile times is them talking about how they had to split their Rust rewrite into 100 crates. A plain reading of this is the opposite of what you’re saying: they’re pointing out that Rust’s compile times are slower, but that this wasn’t an overriding negative.)
You don't have to claim that they're better, but making a big fuss about them in Zig - to the point of maintaining a compiler fork - and then not talking about it at all in the Rust doc (where it's apparent to anyone who's used Rust that compilation there is guaranteed to be slower) is dishonest or at least massively hypocritical.
The bun team made no mention of compile times in their post. The author of this post points to other work by bun that was hardly making a big fuss. It was just a Twitter post about parallelizing some things to make builds faster.
I knew that LLMs had caused reading comprehension to tank, but I quite literally already directly answered that question - as did the original article under discussion here.
You haven’t answered it, and I can’t find a fair reading that would lend itself to that interpretation either. You can easily correct me by quoting the part of the Bun post that you find to be “making a big fuss.”
(Surely a relatively bland technical criticism of Zig - one that gets couched with praise - does not count as “a big fuss.”)
> making a big fuss about them in Zig - to the point of maintaining a compiler fork
Literal quote (and again, appeared in the original article as well). Forking the compiler to try to get faster compile times is a significant effort that absolutely counts as raising a fuss.
The word “fuss” doesn’t occur in the original Bun article.
I also don’t think that forking the compiler is a big fuss. Large companies do that all the time, to carry whatever patches they haven’t upstreamed yet (or can’t). It’s really not that big of a deal.
> But you can state that factually without making it into a personal attack. It would even be more convincing.
I 100% agree with this.
I was just saying that you are probably less at risk of triggering people if you don't politely lie about stuff they make. I don't 100% agree with Andrew's response and I think he should apologize or explain more.
> I can’t conceive of the leadership of the Python or Rust or any other community I’ve ever worked with doing something like that.
At least for Rust, part of this is because there is no BDFL, by design. Python has moved away from the BDFL model as well, IIRC. Individual contributors can get mad and write angry personal attacks, but there’s no face of the language like there is with Zig.
To me, this addendum makes it worse. Making small edits to a post like this makes it seem like you're doubling down on the original resentful points, especially with all the new justifications like "a trillion dollar company fired the first shot." Should have just deleted the blog post in its entirety imho.
>outstanding relationships with essentially everyone who openly uses Zig
and talks about it publicly
I don't think the style of multiple revisions to walk back the most problematic parts really helps the case. It very much leaves me with the impression that the original version is the one that the author really meant, with the revisions being just a weak attempt to deflect criticism.
So if you leave a post unchanged, it's proof you meant what you wrote; and if you edit it, it's even stronger proof you meant what you wrote, even if the edits signify some change.
I understand that many interpretations are open in such things, but this kind of logic seems ridiculous.
> I can’t conceive of the leadership of the Python or Rust or any other community I’ve ever worked with doing something like that.
I'd be prudent to use a clear faux-pas by a BDFL as an argument to push for an alternative, seemingly more consensual, leadership style. I'd also be careful to fall for the apparent lack of overt aggression in the latter type of structures, as a necessarily positive signal. I've seen people in various such communities (including the two cited languages) that have chosen not to interact with their steering committees, because of perceived toxicity.
This can and does happen with any kind of structure and can take many shapes, some of whom are too subtle or passive to even accurately pinpoint, in the way you would for example directly index a BDFL. In The Tyranny of Structurelessness Jo Freeman made the case that the lack of a clear structure in the make up of a movement presents with opportunities for very fuzzy power dynamics and related abuses that are also much more challenging to deal with.
Yeah, I don’t mean to detract from the serious communication issues that other ecosystems have.
(I don’t think committee/unstructured/BDFL communities do better as a rule, it’s more about the culture that’s promulgated by whoever is at the top, regardless of how many of them there are.)
I appreciate having an opinion vs a bunch of safe words saying nothing. Most CEO communication probably isn't even written by them and has a person-less touch.
It's totally fine to get a negative reaction and avoid the project. It's called having human emotions, which is actually healthy. Getting feedback is how you learn and grow as a person.
There’s a difference between having a negative reaction, which is a natural human thing, and talking out of both sides of your mouth. You can also have negative things to say (or just strong opinions) without being indecorous or unkind.
To me it's just highlighting the reality -- Anthropic fired the first shots. I think it's reasonable for people to say, hey, if you're going to trash the reputation of Zig (in a pretend-objective way) then it's entirely fair for people to put in important context that Bun was not written well.
They're suggesting that the bugs are endemic to using Zig and couldn't be prevented by a modified coding style. Then they point out that the well known way to avoid the issue (defer) is "not ergonomic" (really one extra line is that bad?) It seems like a lot of misinformation couched in a reasonable sounding tone, which is par for the course for how these labs operate.
I don’t think the basic idea that Zig is less safe than a language like Rust (and therefore has different classes of “endemic” bugs) is controversial among Zig programmers.
The points they make around explicit defers are a lot more subtle than it being too many lines. Quoting:
> For Zig code, when exactly should we be running the cleanup code? If we're passing the same *T to many different functions, how do we know when it's no longer accessible and can be cleaned up? How does it work when some functions need to continue to reference the memory after the function is called?
I've seen plenty of projects in C with way more complexity and far fewer issues than Bun, and C is definitely less safe than Zig. Memory management strategies are not new things! Professional developers learn to use their tools effectively. After reading the article and the connected context I just get the sense that this is a poorly developed codebase. A bad carpenter blames his tools and all that. I agree with the article that this seems to be about culture. A vibe coded port that explicitly uses unsafe in Rust is not going to be any safer.
I mean look, I'm sorry, but at this point I cannot take the Bun project seriously. If people are bragging about not-bothering-to-read-the-code and practicing atrocious engineering with LLMs, and then they're like "it's the language's fault!". Yeah, no, I don't buy it. Plenty of people can write applications in languages without automatic memory management without endemic use-after-free issues. As vibe coders like to say: skill issue.
I don’t have an opinion about whether Bun is poorly coded or not. I also don’t have an opinions on it being a good project or not.
I do find these kinds of “get good” arguments tiresome, though. Our job as responsible engineers is to develop strong and safe abstractions for the next group of engineers to use. Rust is one such abstraction.
Andrew didn't make the hit piece out of nowhere, unprovoked.
Jared, using Anthropic's multi-billion dollar microphone, painted Zig in a bad light with their first (denied) attempt to merge a vibecoded PR to improve Zig's build times.
Then very shortly after that failed attempt, about 11 days later I gather, Jared (again with help from Anthropic's very big microphone) made public the Zig-to-Rust port.
So unless you're planning on getting acquihired by Anthropic _and_ planning on porting away from Rust using their tools very publicly, I think you'll be safe from such pieces.
Is it true that Jarred and the Bun team at large engaged in "outright fabrication" in professional business discussions? What do you think of that statement made by Andrew?
It was serious enough that Jarred showed up to post receipts with very little commentary, so as not to distract from the receipts. The charge of professional dishonesty is very strong.
There's literally nothing in that post of substance, other than the fact the Zig community is obsessed with trying to "prove him wrong" or some other such nonsense. Jarred's responses have been composed and civil, while the Zig team has been petty and vindictive.
I think there were valid technical and professional criticisms in that post. For example, “Oven’s working culture was poor” is an excellent thing to communicate that I otherwise wouldn’t have any sense about.
At the same time, I also think they were essentially wrapped in an insult sandwich: the post starts with personal swipes against Jarred (who, again, I don’t know) and end with an insult to the reader (who is expected to not believe their lying eyes about all the personal attacks they just read).
Yet one is technical and the one you actually got a negative opinion about a programming language supposedly isn't?
I knew it was gonna happen at one point, guess I didn't believe it'd happen so soon, but I still can't believe that nowadays people make choices about what programming language to used based on what semi-celebrity they like the most, and it's all about emotional arguments. What happened and since when is this the way people make technical choices? I feel like I woke up in an alternative universe.
You are reaching quite a bit, and misrepresenting too.
But it's actually as simple as: Jarred's post was mature and didn't throw shade; Andrew's threw quite a bit of it while insisting it did not.
I and many others don't want to be slandered or trash-talked if we moved away from a language we previously chose. That can and has had actual business impact on projects / companies in the past. So naturally, people will judge you if you cannot be mature when responding to an event that made some splash in the ecosystem.
The language in question here is maintained by a BDFL, which means that one person has outsized influence on the language, and it's direction.
In this context, I find it reasonable that if someone is ticked off by that BDFL, they might second guess the direction of the language itself. Since the opinions and emotions of that BDFL _will_ end up in the language and it's community.
This is different than some un-associated influencer having an opinion, and using that to choose a language.
> The language in question here is maintained by a BDFL, which means that one person has outsized influence on the language, and it's direction.
Seems like a strange perspective, isn't it expected (and even wanted) that if you have a BDFL, they have the most influence on the language and its direction? That's why they're BDFL, that cannot be outsized, it's perfectly sized for what it's explicitly trying to be, that's the entire point.
> In this context, I find it reasonable that if someone is ticked off by that BDFL, they might second guess the direction of the language itself. Since the opinions and emotions of that BDFL _will_ end up in the language and it's community.
Yeah, I suppose in the new daily reality where we care more about what opinions people hold, rather than what quality, reliability and so on they actually produce, this does make a lot of sense. Personally I never used Linux because of how much I love/despise Torvalds, I've basically never cared about what he thinks, never thought it was important either, as long as Linux continues to work for me.
(I also don’t have any opinions about micro-celebrities or whatever else. I don’t know Jarred or Andrew, and I have priors about JavaScript that in any other context would naturally bias me against Bun. But the Zig post’s flaws are, in my opinion, not ignorable.)
The technical content of the Andrew’s post didn’t leave me with a negative opinion. To quote my original comment:
> 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 can’t conceive of the leadership of the Python or Rust or any other community I’ve ever worked with doing something like that.
Yet one is technical and the one you actually got a negative opinion about a programming language supposedly isn't?
Yes, on the one hand here's "Structure and Interpretation of Computer Programs" and on the other hand here's my blog "embedding-shape is a stinky slop beginner shit show"
And yet you got a negative opinion of me from the "embedding-shape is a stinky slop hack beginner shit show" post rather than SICP? I feel like I woke up in an alternative universe!
It's insane that you think there's any moral problem with using a LLM to rewrite a FOSS software project in another programming language, regardless of whether or not Anthropic employees are doing it. This is the kind of thing that every free software license worthy of the name allows and encourages anyone to do for any reason.
I didnt say that there was a moral or legal problem with rewriting FOSS in another language, I said that Anthropic doing so in this instance was a direct act of hostility aimed at chilling critical discourse about their products and marketing narrative, and I’m shocked at how many people (maybe) are rushing to their defense.
BTW the rhetorical device of misrepresenting what someone else says as something much weaker or incorrect and then arguing with that is usually called “strawmanning”. Just thought I’d point that out to you in case you weren’t conscious that this is what you’re doing.
I think it is insane to characterize Anthropic, or Jared Sumner in particular, using Anthropic's LLM to assist with rewriting Bun in Rust as a direct act of hostility aimed at chilling critical discourse about Anthropic's products and marketing narrative. I'm defending Anthropic because I think this is an okay thing for anyone at all to do, and I would defend anyone at all doing it. If any criticism of Anthropic can in principle be chilled by an Anthropic employee using an LLM to rewrite a piece of open-source software in Rust, then that criticism cannot possibly be good.
> We wouldn't have gotten this far if not for Zig, and I'll always be grateful. Until very recently, programming language choice was a one-way decision for a project like Bun.
I actually don’t work for the PSF, and have never received any money from the PSF. Thank you for imputing bias into my motives rather than responding to the comment, though.
Yep. If anything, this ought to bias me against Anthropic. But I don’t share my employer’s opinions about everything, as I assume you don’t.
(Edit: I don’t understand the relevant of these links, to be clear. PyPI is a PSF-hosted project, but that’s because PSF is a legal and fiscal umbrella, not because they pay me for my contributions to PyPI. They don’t.)
Someone pays your living, I’m guessing. But I trust that you aren’t unduly motivated by their interests, because you’re a human with your own thoughts and opinions. I ask you kindly to grant me the same presumption.
Nah, I would not comment on things related to my employer's business because that might mean they could sue me for damages or insider trading or all sort of things.
Everyone is motivated. It seems to me that Anthropic went out fishing for something to blow up. As Ray puts it: "Management eagerly approved the Rust rewrite option because it was a great marketing opportunity to showcase their new Fable model, Anthropic already uses Rust, and Zig is openly against using Anthropic’s products." Sounds spot on.
Others have pointed to some plausible technical benefits from the port, namely that it forces an enumeration of unsafe code boundaries. There's probably something to that, but the big idea is that Anthropic bet that its models could do a big job, and they needed to both demonstrate that and make hay of it. Everything aligned. They did the port. The artisans might call it slop, but it runs, they did it like 2 weeks, and they stuck it to the guy that shuns AI.
If you're the type of manager who picks farming out work to a body shop with 100 unskilled workers instead of hiring 2 legitimate FTEs, then this is speaking your language.
I didn't say or imply that it did. I just don't believe that the decision to port bun was based on innate technical merits of zig vs rust. I also don't think that it is entirely meritless, as I mentioned, because now that there's a par rewrite, there is clear delineation of the areas that need to be ported to safe rust. Still, does anyone really think that this would have happened without Anthropic's provocation?
I see it like this: Anthropic saw an opportunity to make a splash. Jarred made it happen without directly disparaging zig, but the implication is that zig couldn't cut it. Andrew made it more personal.
I don't understand how a port is a "provocation." That's a very cynical and transactional way of thinking about open source.
(As for Anthropic's motivation: only they know. But I suspect that they saw Zig's AI policy as a potentially existential risk, and moved to de-risk their position. That is a technical decision, just not one rooted in the merits of any particular language.)
By provocation, I mean what motivated the port. I'm not suggesting that it was "provocative" like with intent to bother the zig team. That's why I ask if anyone thinks that bun would be ported to rust if not for the Anthropic deal. I doubt it, and I think that's why it took everyone by surprise.
Regarding zig becoming a risk: that's a reasonable line of thinking that I hadn't considered. I don't know how likely it is that zig will fail to progress and fall behind as a language compared to others that are assisted with AI, but it's a possibility.
I had this exact same reaction. Agreeing with the substance of the critique of approach etc but not at all its tone nor of the underlying elitism that lays there.
This is not how professionals behave in a profession.
Decorum actually matters.
Anthropic is doing bad stuff. They clearly have a broken internal engineering culture. Hence I don't use their products. But I expect to see this laid out in a structured argumentation that doesn't go after people and their personalities.
As someone who's been following Sumner's work closely for years, Kelley's accusations are very much true even if unkind. While the results are useful and cool, it a wankfluencer op from start to finish. I dare you to refute thus.
And I say all this as someone who does agentic development 8hrs a day and someone who always pestered my team to opt for Rust and Deno instead of Node. Call a spade a spade, the rewrite was poorly justified and one in a long lines of successful psyops Dario and co. cooked and delivered.
Now, would Andrew's message have been better received if it had better "decorum"? Maybe. But I'm glad he stayed honest to himself instead and didn't have a PR team ghostwrite his thoughts. You have to appreciate that.
> But I'm glad he stayed honest to himself instead and didn't have a PR team ghostwrite his thoughts.
If there's one thing I learned in this debacle is "I should spend 1-2 days and send to a close friend before hitting publish on a firey reply." The way Andrew rephrased the closing section is the kind of thing I should publish on the first edit in similar scenarios.
Abraham Lincoln used to write angry letters and stow them away, unsigned and unsent [1]. The book "How to Win Friends and Influence People" claims he stopped harshly criticizing people publicly after being challenged to a duel [2] by a government official he had attacked anonymously in the press.
Unlikely a useful lesson here. If it would have been written as "political correct" version up to the point of not calling Jarred out at all would have missed the core message. The fact that it was written blunt is the reason it went viral.
uhhh, that's not how the how that figure speech goes. There's a reason why people say all publicity is good publicity, and you can't just flip that to fit your perspective.
I read that as him beginning the healing stages. Acknowledging his flaws as soon as he could even if he couldn't change what he already said - because that post did blow up, if he had taken the whole thing down it may have just exacerbated things.
I think if the last decade has taught us anything, its that decorum has zero to negative value in public communication. People pay attention to drama, and you need attention to be heard. When the penalty for rudeness is gone, just go for contention.
I assume Andrew's goal isn't to be a viral influencer but to achieve some type of long term impact or goal. Programmers don't pick languages based on maximal vitriol and if anything do the opposite.
Wankfluencer has now been added to my lexicon. It's a word that feels like it should always have existed, but didn't. So very aptly describes these personas who would pimp their own mother for a t-shirt with a logo on it.
The fact of the matter is, the reason Bun chose to go with Zig in the first place was for clout and clout only. Bun is a textbook case of a wankfluencer operation: unnecessary rewrite of an existing useful project using the latest hot language or ecosystem to get lip-service by influencers and get easy VC buy in.
There's nothing wrong with chasing a little clout really but I was not surprised to hear Bun's engineering itself wasn't up to par. A single person was shipping not just a runtime but half the ecosystem/tooling justified by sketchy benchmarks? As someone very familiar with the effort it takes to ship solid code in Node and Deno and the ecosystem writ large, their early claims of performance and being production ready were very suspect and it was unfortunately proven false once it duped real projects into getting adoption.
Again, there's nothing wrong being overly ambitious and failing. But I dare anyone to refute that in Oven.sh and many other twitter first projects today (usually in the Js ecosystem), solid engineering and actual usefulness takes a backseat to being viral and being featured in some idiot's weekly roundup news segment.
If you're familiar with Kelley's and the Zig Foundation ethos, it's not surprising that there was internal clashes and drama with such a project.
It was poorly justified up-front but frankly I did not need the examples to understand Jarred’s frustration.
What I found helpful were his explanation of how the interaction with JavaScript’s garbage collector created unique challenges for Bun. Andrew did not address this point at all. It was also helpful to understand how the test suite covered the new code - many people had assumed the tests were also vibe translated and couldn’t be trusted. Andrew pretends he didn’t understand that tests don’t catch all bugs, which is true of all software including Zig.
To me this whole exchange is mostly the typical “memory unsafe languages lead to time consuming and disruptive defects that can be almost entirely prevented with a choice of programming languages” versus the “git gud and don’t write bugs” response.
Layer on the AI tension, Anthropic’s involvement and Andrew’s classic Linus impersonation and of course its viral.
They didn't have to but Anthropic chose to open their mouth and announce their "reasons" for the rewrite. Don't blame anyone but Anthropic for this, they didn't have to try to justify it, but they decided to anyway.
Sure that had to justify it, people were writing all sorts of posts about how Bun was no longer trusted since it was rewritten with Rust.
Bun's post was explanation of that process that was (IMHO) pretty reassuring in that the new version of Bun is not 100% garbage.
(Now in the ideal case that post would be released before, or at the same time as, rust-based source code on github... Then there would be much less drama)
Exactly. The people criticizing the rewrite for the most part are just trying to exert power from the wrong end of a parasocial relationship. And then they get upset when no-one takes them seriously.
Linus attack on "things" he dislike and call the person out on it. I don't believe Linus has ever call out on that person's other non related behaviour.
People keep using Linus here as if they are the same. They are not.
if he actually was, then it's not a personal attack but stating facts about a person - there's a meaningful difference.
A personal attack has no informational value (about the accused), while bringing to light bad qualities of a person does - especially if those qualities are related to the issue at hand, which in this particular situation seems to be the case.
Again, the distinction between a personal attack and proper characterisation of bad qualities rests on actual facts i.e. was it slander or was he really a bad manager?
I don't know but I personally give less probability to the former than the latter.
Does that include Claude itself? Half joking aside, my main concern remains that both OpenAI and Anthropic practice this fear mongering as strategy at the executive level because they have to. A corporation is a different beast. Not human, exactly. Not AI either. What happens when a corporation starts being informed by the AI it is building?
In this, not only did the interviewer admit he knew Suleyman had written about the issues he talks about in his rebuttals, he then says he's only asking (the hard question) because the "audience" wants it.
Suleyman's response talks about taking "accountability for the things that we build" and the "types of problems that we choose to work on," it highlights the fundamental flaw in the cloud-rented AI model.
In that ecosystem, "we" means a handful of corporate executives deciding what tools the rest of the world gets to use, how they operate, and what data they extract. All based on the profitability of the corporation. It is the absolute antithesis of a sovereign architecture where execution happens locally and the user dictates the terms of the system.
They are coming for open models. It's time to harden the gates.
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.
> 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
Anthropic absolutely is in the programming language market. If/since AI makes rewrites to certain languages relatively easy, a success story will tie the given language(s) to the given AI company.
Rust may have a tremendous success in the future, because it's much easier to write it with AI (ignoring for a moment whether that's really a good thing). The implication is that Anthropic has a stake in Rust's success.
Also, to be kept in mind that devs advertising successfull rewrites often hide some aspects that are unfavorable to the narrative; typically, how bad was the code before the rewrite), although there are other (significant) aspects that have been omitted.
> Zig's response is a sour opinion piece full of personal attacks.
- Jarred has written Bun with very bad engineering standards
- Jarred has managed public relations very poorly (e.g. ghosting the Zig foundation)
- When they rewrote the project to Rust, and described Zig as poor choice, there has been a negative fallout for Zig
- The ZSF is obviously upset because of the poor publicity
This is summarized at the end of the post:
> Zig users who knew next to none of these facts and have only the surface level understanding that an ex-Zig-user is getting trashed by the language creator. Such people might reasonably worry that might happen to them
As a matter of fact, I also believed the same after reading's Bun's post. This is undeserved though, and that's what Kelley explains.
There's definitely a personal attack somewhat, and this is addressed in the last (added later) section.
> I also believed the same after reading's Bun's post.
This doesn't even make any sense. The part that you're quoting[0], is Andrew commenting on the fallout from the blog post he made. How could you have thought something about a blog post that hadn't come out yet?
Also, if you are talkinga bout the post Jarred made, it was extremely charitable about zig: "Zig made Bun possible. I would never have been able to build this much in 1 year if it wasn't for Zig."
[0] "The other critical mistake I made with this post was failing to consider the rather obvious and important point that this might affect Zig users who knew next to none of these facts and have only the surface level understanding that an ex-Zig-user is getting trashed by the language creator."
- When they rewrote the project to Rust, and described Zig as poor choice, there has been a negative fallout for Zig
- The ZSF is obviously upset because of the poor publicity
No where did they describe zig as poor choice, and there were zero evidence ZSF was getting poor publicity.
Had whole of HN, Reddit and Twitter all laughing at Zig this would have make more sense. But that was not the case. As a matter of fact I don't even record a single comment about it. If anything a lot of these "poor publicity" and "Zig as poor choice" were completely fabricated.
Had the internet turned against Zig, the response may have deserve a lot more weight.
>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 hate about ornery IT people.
That is an absolutely foolish position to take. Basically, when given proof that agents need improvement you're sticking your fingers in your ears and going "nuh uh, it's not their fault".
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 should worry all of us.
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.
My comment shouldn't be read as an explanation for why Anthropic chose Rust in this case.
I was simply disputing the claim that LLMs are good at all languages, and that their biases--both intentional and otherwise--will swing the entire industry.
They really don't. Even per-project it can be a shitshow. For instance, while I use LLMs to write some typescript, when I'm writing code for Unreal Engine in C++ & Blueprint I pretty much do it by hand because it absolutely can't do blueprint in any meaningful sense. Even the most basic requests result in an absolute mess. (I imagine it's also very hard to train on since its stored as binary data). Even the C++ code it generates is pretty rough -- regular linker errors etc.
>Jarred has managed public relations very poorly (e.g. ghosting the Zig foundation)
I actually love the use of ghosting in this post. It is almost a Freudian slip about how Zig looks like from the view of outsiders. Zig moves exactly like how toxic exes do. They point fingers, make passive-aggressive statements, unnecessarily air out dirty laundry, and downplay all of the good their partner has done during the relationship.
> Rust may have a tremendous success in the future, because it's much easier to write it with AI (ignoring for a moment whether that's really a good thing).
It’s interesting that Rust could become the most deployed but the least written (by humans) programming language if the dreams of AI bros come true.
If AI gets good enough to competently translate other languages to Rust then there is no point writing in Rust (a language with a steep learning curve and is high friction in use), you can just write in a low friction language like C, C++, Odin, Zig, … etc. and have AI translate it to Rust catching all the memory bugs in the process.
If your objective is just to hack something together quickly to test an idea, and doesn't care if the application segfault 6 hours later (eg. a prototype game engine), C++ is definitely the superior choice to Rust.
Rust is like the instructor demanding that you build your house up to the national code, down to the choice of nail for your floor board. Your house will be perfect, but building it is extremely difficult and high-friction. In many cases this is unnecessary.
I can get cross platform rust up and building and running with 5 minutes. It’s probably half a day at least for c++ and a more significant maintenance burden.
Also, I think the “quick to prototype” only is beneficial if you know c++ and don’t know rust. I know both and I can say that Rust is much faster to prototype in precisely because
a) tests are trivial to add meaning it’s trivial to add test coverage vs in c++ you have to integrate gtest and bother to set that up which no one does
B) many initial startup bugs are prevented. It’s not segfault after 6 hours but spend hours getting it to work correctly after it compiles vs it runs mostly correctly from the first build.
Even if Rust is slower to write (which is only true if you don’t know Rust and don’t have AI) it’s still overall faster to develop in. I can’t recall if MS or Google have written up their experience on that side or focused only on impact to vulnerabilities.
You can hack things together pretty effectively in rust if you put your mind to it (so many things that bog people down in rust are due to focusing too hard on premature optimization of either performance or correctness), and the easier to use tooling really helps with that kind of thing. I use Rust for small one-off projects frequently just because it's easier to work with.
> translate it to Rust catching all the memory bugs in the process
That's not possible. If it were, you'd just fix the memory bugs directly in the original language.
Your best bet is to have a translation littered with unsafe blocks, so you still have to do the work of nailing down the specifics to make them safe. There's no magic "unsafe language" -> "safe Rust" pipeline, even with GenAI.
I imagine it could, eventually, if not now. The Bun translation used Anthropic's best model, cost hundreds of thousands of dollars, and still contained a large number of unsafe blocks. Maybe if they left the agent running for longer, using Miri for verification?
We've read the andrew blog. It is a personal attack a very petty one, you're clearly a biased fan of his and of zig probably if you cannot see the obvious, but we're telling you as outsiders how poorly it reflects on andrew and the future of zig, and this is coming from someone who originally had a very good opinion of zig and andrew, now not so much.
You can choose to ignore that and engage in the massive circlejerk zig fans are engaging in during this or maybe take a second and reconsider
Yeah, exactly. It's weird that Zig even responded to that. Imagining that your studio switched from Unity to Unreal and Unity proceeded to release a hit piece attacking your codebase quality and workplace environment.
But that hit piece would be an answer to the (multi-billion dollar) studio saying how much better the result is after the rewrite to Unreal, except it's not because Unreal is better (which it could be btw, or not, or more probably it depends on the use case), it's because the studio worked hard to make it look better, which they could have done without the rewrite.
Anthropic does this to sell LLM rewrites and make them look better than they actually are, Zig being the source language, they are a collateral victim of that misleading advertisement. Of course it's unfair to them and of course they should highlight this.
There was an almost exact example of this: City Skyline 2. It's (was) a poorly optimized game and they said Unity's DOTS didn't match their expectation, making Unity look bad, while some issues (like they didn't use LoD where they should have) weren't Unity's fault.
And even in this case, it'd be extremely weird if Unity published a blog post about how City Skyline's studio is a "Just a total shit show, from an employment perspective" (quoting Andrew word by word here).
This is actually is an interesting example, because Cities Skylines 2 has been handed over from Colossal Order to Iceflake Studios recently and since then they have (in my opinion) quickly been able to improve and fix a lot of things that CO weren't able pull off for years. So perhaps CO's development was somewhat of a "total shit show"?
I'm not saying Unity should publish PR about how Unity is working well and this handover and subsequent fixes proves it, but I think you could argue that they could and that they would have at least some facts to back it up with.
Anthropic is massively bigger than a studio, Zig is massively smaller than Unity, and it wasn’t a quiet switch, it was a huge publicity event. It’s more like the #1 movie of the year being “The Profound Joy of Finally Leaving Unity”. Sometimes things are big enough to warrant a response.
It was a pull request and a blog post which HN et al. collectively foamed at the mouth about. You’re acting like Anthropic sunk millions into a marketing campaign.
Anthropic produced the tokens. They don’t have pay themselves retail API rates for them.
The cost was only provided as an honest estimate of what it would have cost someone else at time of writing, which I thought was fair.
The number is peanuts relative to the cost of engineers working on the project. I find it odd that so many people think this cost number is some sort of smoking gun.
At the same time, Anthropic is still running at a loss, so should this actually be 300k? 500k?
Anyway, the exact number doesn't really matter in the context of my comment anyway (which was meant to facetiously note that the marketing campaign includes the Bun rewrite)
It’s not weird considering what we’ve learned through this:
the Zig project is driven by people with fragile emotions and egos who lash out at people personally when they feel threatened.
We’d like Zig to be a project with steady and technically driven leadership like Rust, but Kelley has made clear (many times) it’s more of an egoistic vanity project like Elm, designed to cater to the emotional needs of the BDFL.
Well, if your game would be one of very few AAA games written in Unity (actually, the only game written in Unity people reasonably familiar with the subject would be able to name off the top of their heads), things might look different...
> I talked to those who interviewed for a job at Oven. I talked to people who worked there. Those people talked to each other. Everybody talked to everybody. The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show, from an employment perspective
Yeah, exact words you would expect from someone who is happy about a win-win situation.
Andrew is bitter (or something related) about this whole situation, that's no question, he writes it in his updated post (he doesn't say "bitter", but he speaks about unprocessed emotions).
People are entitled to their emotions. The question is whether the bitterness is warranted. I think it is.
Yes, people are entitled to their emotions, but the ways they behave in public and express their emotions reflects on them in a major way. The Bun blog post focused on the technical reasons to change, and was complimentary about Zig. The Zig blog post was heavy on personal attacks, with some technical claims that the Bun blog post had mostly addressed already. Between the two, the Bun post is a lot more compelling from technical and professional perspectives.
I'll admit to thinking that the Rust crowd often has a toxic atmosphere, but Zig came off as worse in this exchange.
When accusing someone of "good looking lies", it would help to provide an example or two with an explanation of why you think they're lies (rather than mistakes, oversights or differences of opinion). Complaints that the post "subtly and misleadingly throws shade at Zig" are hard to accept without that kind of support.
> Of course when you are the creator of Zig, that may feel quite unfair and you should highlight it.
Then highlight that, don't repeatedly insult someone. If Andrew thinks the same kind of ai-assisted improvement would be possible in Zig, and that avoiding the kinds of errors migrating to rust achieved would be possible in Zig, he should demonstrate it. And I don't necessarily mean rewriting all of Bun in "better-zig", but like, if you're going to say "this project is bad because it is badly maintained, not because the language has limitations" then demonstrate something to that effect.
The only technical detail I recall from Andrew's post is that zig has faster compile times, which may well be true but what do I care?
Why not? Sharing your experience with working with people is fine, they're subjective opinions. Does this mean it's slander and/or a hit piece? Seemingly a lot of people would say so, personally I don't think people sharing those sort of experience publicly are doing so out of spite, some of us are just still used to the old-internet where you can share stuff like this in public, without getting piled on for not "thinking/writing the right way" or whatever people are complaining about.
> Incredible the different takeaways people get from text content on the internet
It is incredible isn't it.
"Jarred was already writing slop well before he had access to LLMs"
"The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show, from an employment perspective."
"at some point they would sell out (let's be honest, their vague "sell some cloud something" business plan was a farce from the get-go"
"he was essentially groomed from a young age into uncritically embracing the Silicon Valley mindset"
There is more but I'll stop quoting to not end up copying the whole thing.
nah. I have no horse in this race in fact before this blog I had high regards for andrew and zig, less-so after this blog.
You're accusing me of cherry picking, can you explain how these are cherry picked ? do you even know what cherry picking means ? maybe explain the important context for "Jarred was already writing slop well before he had access to LLMs" that I omitted apparently.
...Unity made a blog post saying they were happy about you moving to Unreal, publishing they think it'd be a win-win, then outlining why they think so
I mean, that makes it all sound very polite and dispassionate, but Andrew's piece was anything but. I have no dog in this fight, I don't use Zig, Rust, Bun or Claude, and initially I thought the bun rewrite sounded like a terrible idea. I changed my mind after reading the piece about the migration - it was very interesting and the process was obviously quite thoughtful. Andrew's piece made me want to take a shower afterwards.
And what is even the point of saying that Andrew dislikes how Jarred acts and works?
Let's say the supervisor wants you to write a new microservice. Do you refuse to do it because the supervisor smokes cigarettes and you're an anti-smoker? I think that if you have objections, you should refuse only on technical grounds, not personal.
It is in there nature. They (specially zig creator) were so jealous about about vlang getting traction and getting $800/month donations, they made it their core mission to attack vlang and spread hate.
Vlang is a ridiculous project that was entirely driven by hype that should have been easy for all to see straight through. It is ridiculous that it got $800/month with nothing to show for it. I haven't seen any hate spread for it by Zig.
With over 37,500 stars, over 2,300 forks, 826 contributors, books written on it (in Japanese and Portuguese, besides English), and a Wikipedia page; vlang is clearly a significant and successful open-source project.
> entirely driven by hype
People can plainly see Zig (and other HN pushed languages) directly engaging in marketing propaganda and hype (with HN accounts clearly stating they are from those projects) using social media (including HN) at levels way beyond anything anyone could accuse the V project of doing. The creator of vlang is also not a native English speaker, where the creator of Zig (and other competitors) have no such excuse. They know exactly what they are saying, the connotations of it, the cultural nuance surrounding it, and what it means in English.
> ridiculous that it got $800/month with nothing to show for it
Jealousy over vlang getting as much (or more) donation money (in 2019) from its supporters was a central theme in numerous social media and website posts made directly by Andrew Kelley[1]. Even to the extent he and the Odin creator[2] were asking people to give them money, instead of to the V project. Many would consider such behavior as extremely bad and unprofessional. Also note, there is no reverse of such behavior to be seen by the V community at them, instead we see uncalled for conduct and statements being directed by them towards the V project.
Donations that vlang had received and continue to receive, is from their supporters. Some of these paying supporters have even come to HN, to publicly express their support[3][4][5] against competitor false accusations and disinformation. Competitors should have nothing to do with someone else's supporters giving donations, in the same way that vlang's creator does not speak on who donates or supports their projects.
> I haven't seen any hate spread for it by Zig.
It is documented, on HN no less (and elsewhere), where people can see Zig's creator directly slandering vlang's creator[6] and this kind of unprofessional behavior encouraged followers to do similar.
I don't see any hate in these references. Perhaps just truths you don't want to hear. I've seen your name pop up multiple times in past conversations about V in response to anything less than positive. What's your involvement with the language to watch its discussions so ardently?
People know what jealousy, slander, and unprofessional behavior are. Including how the V project is treated, regardless if certain others pretend not to or try to blank out others for noticing.
> What's your involvement with the language
Just responding to the comments of others, like the truthful one made by f-serif.
Not part of any V organization, just use the language (and some others). Which is more than I can say for a number of accounts where their profiles clearly say they are directly part of or work for the Zig organization.
Yeah this is why Vlang is banned from discussion on HN; any time it comes up people have a critical thing to say about Vlang, these guys descend with paragraphs, links, and a list of grievances about how their language is slandered and hated by people fueled with envy. Doesn’t matter if it’s buried in a thread in a comment section in an unrelated story, these guys rush in to defend the honor of Vlang.
Meanwhile, years later Vlang still have not delivered on the initial claims that made the language even remotely interesting.
It's the old craftsmen vs industry issue, Andrew comes from the craftsman tradition that prefers all other people developing to also be proud craftsmen.
What Java, JS, Python and C# all did to conquer the industry from a C++ dominance was to provide safety harnesses for less "perfectionist" workers to fumble around without causing a mess, to write C and C++ in an increasingly hostile world we realized you needed a lot of craftsmanship, the performance benefits outdid and kept the latter languages relevant for a long while.
Still, the performance/predictability penalty didn't give way so Rust (and Swift) came into play. They don't have as many unpredictable performance characteristics as the previously "safe" GC languages but still provided more or less the same guarantees (in some ways perhaps even better for Rust).
The brilliance of the Rust ideas did start a bit of a cambrian explosion of languages in that niche, most of them however targeting a bit more of a craftsman position than Rust (that came out of distinct industry needs).
The problem as the article illustrates, in car terms.
If Java,JS,etc are mostly "regular safe cars" and C/C++ a two wheel motorcycle.
Rust is perhaps a rally car (fast but still a car so occupants inside are well protected) whilst Zig really is a quadbike or open wheel cart, not as unsafe as a two wheel bike since you won't slide for the smallest oil/ice patch but flipping over is still dangerous as hell.
And that takes us to the crux, so many developers who love the craft and perfection (and don't live under- or perhaps care of- financial constraints) think that "good careful" developers is all that's needed and don't see dangerous language designs as a problem.
I'm an older developer, and given that I can write "good careful code", but 90% of the time it's also a matter of time and financial constraints so I wouldn't trust mine (or anyone elses for that matter) code written under those "industry" conditions.
I think Zig has a lot of nice perks, but it was obvious from day 1 that it's very much for people that love their hacking freedom over writing code for todays hostile world.
All I’ve seen is there is literally no programmer smart and careful enough to never create a use after free or out of bounds read in a sufficiently complex codebase.
The state of computer security has moved on from the old model of just patching bugs when you find them. To now where we need to systematically prevent them from happening to begin with.
Have you heard of TigerBeetle? Being smart enough doesn't seem to be the primary factor. It's about having a strategy and the discipline to follow it. No type system will ever free you from the burden of doing the actual engineering.
I find TigerBeetle very impressive. One of the impressive (and correct) decisions it made was to use an allocate-up-front pattern, which makes certain classes of temporal memory corruption harder to write.
At the same time, TigerBeetle can do this because it’s solving a specific shape of problem that’s amenable to that allocation strategy. Binding a third-party runtime written in C++ (TMU, this is what Bun is) is a pretty differently shaped problem that doesn’t easily admit that style.
In other words, discipline isn’t always enough (although you do certainly need it). Sometimes the shape of the problem makes environmental constraints (like the kind Rust offers) important.
- any GC'ed language can manage memory for you if you want
- My first rust project (a gui app in GTK) managed to segfault just fine in spite of Rust (no unsafe blocks on my part, not deliberately trying to break anything).
- I think the state of computer security has moved on still, we now rely on LLMs armed with various tools to pick apart and try to break our code AND to generate our code -- it is not at all obvious to me that banging your head against the borrow checker is a worthwhile tradeoff in this new world.
I trust myself to write good code, but I’ve been under pressure to rush things and extra features in Java, C#, TypeScript are really great on those occasions. I love C and Perl, but as you say, there’s not a lot of safety harness. A lot of trust is required for those in a team.
Can't remember the exact featureset of the popular D one (because boy, was there many languages called D and E and so on over the years in the 80s/90s), I'd say to be a car it needs both temporal and bounds safety at the least but faintly I remember D being a bit of a kitchen sink? Wasn't there 2 standard libraries for a while? Were they even coherent in style/used language features?
The results improving the end user experience didn’t have much to do with the rewrite. Improvements in binary size and speed could be had with similar efforts on the Zig codebase. They spent extra effort to get those metrics to look good to sell the rewrite.
The memory safety aspects could be discussed. Arguably they could have had equally good memory safety by employing AI, tests and fuzzing (the Zig integrated fuzzer that the Zig team suggested they use, not just the high level fuzzing they were doing)
For this kind of project I do think using Rust is a good idea. At the very least because a project like Bun probably can benefit from a more mature language.
But I also think Andrew’s perspective of this process has been essential to understand what happened here, and though he could have been nicer with his word selection in a couple of places (he doesn’t have the clout of Linus Torvalds to get away with it), what he wrote absolutely needed to be said. I find it annoying that people dismiss it as personal attacks. If being a bad manager is the direct cause of a poor working relationship and bad engineering results, pointing it out is not a personal attacks. It’s essential context for understanding what happened.
> If being a bad manager is the direct cause of a poor working relationship and bad engineering results, pointing it out is not a personal attacks.
The post did no such thing — it spread rumors and leaned into gossip. There’s no proof or evidence or examples whatsoever offered by Kelley except Jarred’s own public words, which means the post didn’t reveal or expose anything about his management.
> Anthropic is not in the programming language market
Arguing that a product that sells itself as improving programmer productivity by writing the code for you has no stakes in "the programming language market" because it doesn't sell a programming language of its own is impressively shortsighted. Especially when the leader of a programming language has openly stated their dislike of vibecoding, critisized the industry, and the language project itself rejects PRs made with the product being sold.
I'm starting to think that a way we can easily filter what's being heavily composed by (SOTA/mainstream) LLMs or not is by how "polite" the public sees their published blog post.
If everyone sees the post as "polite", most of it probably been written by LLMs, as they remove anything that could be seen as "nonpolite" and human. Meanwhile, engineers who just want to publish their own thoughts and feelings on a subject, will be filled with stuff the public sees as "nonpolite", and since those hard edges weren't trimmed before the publishing, we can then assume this is actually a genuine person's thoughts and feelings.
That'd have been fun, wouldn't it? No, I'm too lazy for that, HN gets my raw and unfiltered disgustingly human thoughts and feelings, unfortunately for all of you.
For shits and giggles, I asked Sol xhigh what it thought about my previous comment, giving it a "6.5/10 for politeness", saying "it’s polite in tone, but somewhat provocative and reductive in substance.".
Maybe this filter should also include provocativeness and reductiveness, and if it isn't provocative and reductive enough, surely it's a LLM? ;)
Yes, it’s a misleading, self promoting marketing piece, of course the tone is different between them - I’m struggling to believe some of the tone policing comments here are entirely honest
IMO if Jarred wasn't literally working for Anthropic and using their tools to do the rewrite, the whole thing would've been much more well received. Imagine if he'd used Sol to do it (while working for Anthropic – impossible of course), or GLM 5.2, etc.
Instead, since he does work for Anthropic, it just looks like a big marketing gimmick that was going to be done whether it was the right thing to do or not.
> Maybe. But they don't particularly care about one programming language over another.
Other than JS (which they obviously do prefer), this rewrite would have taken place no matter what programming language was originally used for Bun.
The reason for the rewrite was marketing, not engineering. The justification after the fact can be done no matter what language they were rewriting from.
Zig -> Rust : "We had all these memory errors"
Rust -> Zig : "We had poor iteration due to compile times"
Java -> Anything : "Memory is at a premium when we're trying to run a fleet of agents"
Anything -> JS : "We wanted a single language to optimise our agents for"
> Maybe. But they don't particularly care about one programming language over another.
I mean, they did buy a JS runtime, so surely they must care more about JavaScript and TypeScript than other languages, right? Otherwise that move makes 0 sense.
Maybe this part from their marketing post about the acquisition is just a straight up lie I suppose?
> Together, we’ll keep making Bun the best JavaScript runtime for all developers [...]
> Anthropic is not in the programming language market;
Did we just read the same blog post? I see no assertion in it that Anthropic is in the programming language market, rather that this rewrite was a marketing opportunity for them they were happy to lean into.
> For context, I'm using Codex and have no interest in either Zig or Rust, so just observing this drama from the sidelines.
The latter part of the post is much less about Anthropic and more about AI coding in general so I’d say it’s still very relevant to your interests.
Did we read the same Anthropic and Andrew Kelly's posts?
Anthropic's posts were sanctimonious, self-serving, tone-concealed delegitimisation of Zig. Kelly's post was a strategically poor but sincere individual understandably frustrated at this concealed attack, expressing his honest feelings about the situation.
> Anthropic is not in the programming language market;
The article by Ray Myers makes the case that Anthropic is in the programming language market by way of them having a clear monetary stake in making their agents look supremely capable of all tasks, up to and including rewriting an entire Zig codebase to Rust.
From TFA:
> Anthropic is actively campaigning to end software engineering. They need you to believe they can do that. Well, maybe it’s not you that they need to convince. Maybe it’s your C-Suite, various world leaders, or the manager of your retirement fund. They’ve raised $132 billion in investment, and are approaching an IPO valued over $1 trillion. Since they cannot show profitability, this depends on selling their hypothetical future impact.
> In literary terms, Anthropic is an unreliable narrator.
> One of their key narratives is: Coding is going away, then the rest of software engineering, and eventually most other human labor. This kind of money behind this kind of story has an impact, regardless of how true we think the story is.
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.
Andrew Kelley mentioned that the rewrite did bring technical improvements, however those were not tied to Rust and could've been made in the Zig codebase.
> Zig's response is a sour opinion piece full of personal attacks.
Not sure; it has some elements of personal issues, but they're followed by a rationale from the author.
Honestly, seeing the project lead (Andrew Kelly) take a stand against poor engineering practices without any equivocation makes me more inclined to want to use Zig - their values (in this regard, at least) align with mine.
He also substantiates what many of us are saying to all these "Very Senior Chief Engineer with 40 years experience" who are boasting of 10x productivity: these people aren't reading the code they are generating, and were producing slop even without AI.
You mean Anthropic has no agenda on its own? That seems a very biased analysis here. The response by Zig could be flawed (speculation, I have not reached this conclusion yet) but I don't see how this offsets Anthropic wanting to promote its AI slop here in any way, shape or form.
It's said to imply they have no bias. But someone using Codex or AI agents heavily already have a bias here, just to be clear. Because the discussion isn't just about bun/anthropic/zig/rust, but also between AIs role in coding. So them touting their use of Codex, while not Claude, can still be a bias, especially in the direction they're trying to absolve themselves from.
What I have been missing in all this debate is substance. I don't care that Bun was ported to Rust; I don't care that Andrew wrote a hit piece about it; I don't care that Anthropic sells shovels in the gold rush.
What I do care about is technical details. Jared shared some motivation as to why they ported to Rust, and I think they look valid (even if provided with sparse evidence). But I have not seen any sort of refutation from Andrew that these are not actually issues or how they should be solved in Zig canonically. I'd really like to see an exploration of these arguments, specifically pertaining to the Zig code as it was written for Bun.
The facts as presented from the Bun side show a lack of technical merit for the rewrite.
This shouldn't be surprising, because rewrites are bad engineering, in most cases.
The Bun project was started in Zig by someone with a lack of experience using the language, despite the massive scope and complexity, and was effectively a rewrite from another language in the first place.
From the Bun post:
> Bun started as a line-for-line port of esbuild's JavaScript & TypeScript transpiler from Go to Zig.
Then, a few years later, the entire codebase was thrown out to do another rewrite in another language.
Completely different approaches. The TypeScript Go port was done responsibly, reviewing every line ported, publishing both runtimes in parallel to give it time for real-life battle testing, with plenty of communication to the community about what was happening.
The Bun Rust port was irresponsible and unprofessional, merging a million lines of unreviewed code while gaslighting the community, relentlessly casting shade on Zig while pretending to be neutral and objective. The Bun rewrite was not just bad engineering, but also (one might say "stinky") management and community relations.
It's no wonder the author of Zig blew up emotionally - which was also unprofessional but at least it was honest and human, unlike Bun's author.
> Porting TypeScript to Go in 7.0 doesn’t seem like bad engineering.
They needed 10x speedup and it was not possible with the current language. And they chose Go, because they could retain 1:1 architecture in most cases. So whether or not it was well engineered, is not so clear. They did not choose Rust because they would have needed to redesign the whole architecture.
In the case of Bun, it smells more like bad engineering, so I am not sure if these are comparable.
I think this situation is a referendum on whether that is still true—or, if it is true, whether the proportions on “most” have changed significantly due to AI.
You're allowed to have a tantrum when a 10 figure company is doing a marketing stunt and shitting on your life's work to do so.
If you spend X amount of years building something, and someone you know to be a mediocre dev trashes it in an effort to enrich themselves, you're allowed to expose the things you know about them. End of story. I wish more people would throw a tantrum. We should expose all these charleton and thieves.
the best way I've seen it described is like this: Bun wants to move fast and breaks things, Zig forces you to move slow and carefully.
Bun wants to ship new features ASAP (a shell lang, sqlite/pg client, etc), so they'd really want stuff like memory management out of the way. Zig forces you to think and deal with memory management, lifetimes, etc. Rust is just a better fit like w `Drop`, and Zig explicitly won't add `Drop` or anything similar.
Just like I wouldn't write a SQL database in Python, Zig is not the right tool for Bun. So there isn't really anything that "should be solved in Zig canonically". I'd say it's more in how Jarred want the project to move forward. Move fast and break things.
> What I have been missing in all this debate is substance.
That’s strange because in this (and Andrew’s in lesser extent) post there’s plenty of substance on both technical, management and corporate influences like the difference of styles guides vs agent instructions, binary size, compile time, Anthropic’s marketing and incentives, etc. It’s hard to miss.
I agree with some of Kelley’s takes, but the issue is the tone.
Does anyone think that if Bun had been rewritten from Rust to Zig that a member of the Rust core team would have written a personal hit piece against Sumner (while pretending it isn’t a hit piece)? Probably not.
Kelley can write what he wants, but as the BDFL of a rising programming language, people are allowed to react if they don’t agree with the public image being portrayed by Zig.
> Management eagerly approved the Rust rewrite option because it was a great marketing opportunity to showcase their new Fable model, Anthropic already uses Rust, and Zig is openly against using Anthropic’s products.
Yeah, don't discount how powerful "marketing" is to management/executives, and also don't discount how absolutely ridiculously petty people can be, especially people who end up like CEOs and similar, requires a particular person. I can definitively see reason #1 and #3 from that to basically already set in stone that Bun had to be rewritten in Rust.
I don’t understand why anyone thinks management of any kind was involved in this at all. It seems much more plausible to me that Jarred just does what he wants. He has said as much.
> don’t understand why anyone thinks management of any kind was involved in this at all
Because it’s marketing gold? Any marketer worth their salt would be super keen to get their claws into a project like this.
Anthropic and friends are in then business of selling LLM’s. This is a demonstration of LLM capability, they’d be foolish to not even try to cash in on it.
Seems like if the experiment didn't work, nothing to lose. But it did and he capitalized it in the most in-your-face possible. it would be interesting to line up the timelines of the Rust experiment vs him joining Anthropic.
Devs need to start realize how people in power take advantage of them. If you already have a bright starry-eyed Peter Thiel acolyte, it's not hard to see how they can be taken advantage of. Especially when it's a multibillion dollar company that stands to give you literally multigenerational defining amount of wealth.
They hired them because they already agreed with them. Reminds me of that Noam Chomsky quote during an interview:
> Marr: “How can you know I’m self-censoring?”
> Chomsky: “I’m not saying you’re self-censoring. I’m sure you believe everything you say. But what I’m saying is if you believed something different you wouldn’t be sitting where you’re sitting.”
Thank you. I was left confused after people praised the Bun to Rust blog post eventhough it contained very actual technical substance. No clear evaluation of options, very biased report on impact, missing figures. It absolutely didn't feel like an engineering blog post.
Maybe people were more interested in the agentic part more than the actual rationale for the port in the first place, because it was very disappointing from a technical standpoint.
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 did they not go for it? This is the technical substance I'm looking for: an engineer explaining what options have been considered and what wanted and unwanted tradeoffs they present.
Also only mentioning figures for the platforms that saw an improvement is sketchy. "With ICU and code folding Windows and Linux get 20% smaller", what about macOS? Why did it not see the same gains? The fact that they don't mention it makes me think that they don't KNOW, and isn't confidence inspiring coming from the engineer who SHOULD know.
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.
Yeah since my whole point is about the technical merits of the rewrite article, I don't count that as justification.
Why is just a wrapper type "less ergonomic"? Everybody does that all the time in every language. And then if you can convince me it is less "ergonomic": why does it matter if it solves the problem? And that is considering humans write the code manually. Why does it matter if agents write the code? This makes no sense.
The example shows three extra lines of code, two of which are `defer`s. I'm not an expert in Zig and can't tell you whether the example they give is contrived, but the claim they're making is way more than "a wrapper type".
> And that is considering humans write the code manually. Why does it matter if agents write the code? This makes no sense.
Because the particular form of non-ergonomic code that is demonstrated here amounts to a quadrupling of tokens. That's a substantial hit to the context window for safety that isn't even statically enforced.
A wrapper class if you want, a wrapper type with methods / dedicated functions. Still, seems pretty ergonomic to me. Yeah we went from one line to three, but the three lines guarantee safety whereas the one doesn't so?
Also I'm not sure the token count is very relevant for an Anthropic employee who just spent 165k worth of token rewriting the whole thing in Rust. Sprinkling a few defers here and there and swapping types surely would have been immensely cheaper in tokens.
You're failing to distinguish between token count spent and context window used.
You're correct that the former is not a concern for Anthropic, but it's also not the problem I'm pointing out.
The actual is not token count, it's context window. Your context window is finite, and every token you add to it reduces the model's accuracy during inference.
Because if you have to quadruple the number of tokens in your code base in order to make the Zig provably safe, you have 1/4 of the context window to do useful work.
Because what they did say is true for both agents and humans. Which makes it a more compelling argument than just emphasizing the specific aspect of that limitation agentic workflows.
In one comment you are presuming that agents can just ignore ergonomic problems, which would be a kind of magic if it were true, and in the next you are saying that their inability to digest enormous quantities of unnecessary tokens is some kind of flaw that needs to be called out.
Enormous quantities of unnecessary tokens are bad ergonomics for anyone, agent or otherwise.
If you write a blog post about "I switched from X to Y", I expect the WHY: the pros and cons of X, of Y, and of the alternatives that were considered and dismissed before considering Y.
This is more a blog post about how to use Fable to switch from X to Y, than it is about X or Y.
Why are we even discussing stuff like work hour expectations in a story about language switch drama?
Even if the guy is a terrible manager this still comes across as a determined attempt to find something negative to say.
To me it’s telling how little focus there is on the technical merits of the rewrite from zig side. Anthropic claimed a bunch of victories and as best as I can tell nobody has even attempted to refute them.
If I was running a project and someone threw it into an LLM rewrite and it comes out with improvements and silence on downsides I’d be pretty worried and try to address that. Instead we’re talking about working hours somehow
I really don't understand what Andrew Kelly hopes to achieve here. Even the non-programmers at r/programming who usually piles on any type of anti-AI posts called it out.
I'm trying to not let this affect my thoughts about Zig as a language but it's hard.
> Views are my own. I have no history with Zig. I’ve never spoken to Andrew Kelley
There are better primary sources to explain what ZSF is trying to achieve with its AI stance. Kelley's rant [0] was a bit much but the ZSF AI Policy [1] and Kelley's interview on it [2] are interesting and informative.
I think the only point that matters is that having Anthropic owning a project which is written in a programming language where the community (or at least the leaders of it) have come out as openly hostile to AI generated code is a clear conflict of interest. I think Andrew Kelley might have been better to say just that and leave it - the comments about Bun's founders energy and motivations don't really add anything worth adding in my opinion.
Yeah, hard to imagine opposing AI absolutists settling their differences.
IMO all the technical arguments and attacks are post-rationalization; different orgs, different contexts, different goals.
I think Kelley saw this, but couldn't resist muddying his point. I give him a pass. The rant [0] is too much, but the addendum about moving on is healthy, and I'd rather the BDFL be too spicy than not spicy enough.
> From my perspective, Anthropic is the party we need to hold accountable here.
It's insane that Ray Myers thinks that Anthropic did anything related to this port that requires holding them accountable; the fact that he used those words makes me want to prevent him from having any influence over AI policy.
Why shouldn't people evaluate Anthropic more after seeing this technical achievement using their software product?
Seriously, let's say that every single instance of people using Anthropic LLMs to translate code in an open-source software project from one language to another was deliberately orchestrated by Anthropic's marketing department, with the aim of increasing their stock price at IPO. Even if this were true, why specifically would that be bad? Why would that be some kind of offense that Anthropic as a company committed, that they would need to be held accountable for?
If you think that Anthropic's stock price will be overvalued at its IPO because too many other investors are looking at uses of Anthropic LLMs to translate code in this way, drawing a flawed conclusion from them, and then using that flawed conclusion to bid up the price of Anthropic stock, then you can trade against them in the market. Short Anthropic's stock. If you're not sure enough about this thesis to actually make this trade, then why should anyone take you seriously when you claim that this is some kind of "trick" on Anthropic's part?
> It would be inconvenient if maintainability still mattered because their products default to making it worse.
I think this is the most important line from this piece.
Incentives matter. The AI companies are incentivized to have us believe that LLMs are the new compiler. That’s ridiculous (a coding LLM is a very very leaky abstraction) but I hear coders, especially coders with poor fundamentals, say it all the time.
This entire AI period has been a study in marketing disguised as futurism.
I say this as one who uses and teaches AI. What fantastic, amazing, unreliable tools. Extraordinary in the right hands, but engines of cognitive and technical debt.
The thing is, it's possible to call a spade a spade without resorting to ad hominem. Andrew's post would've been more effective if he focused more on the Rust port being for marketing, and the shortcomings of Bun's Zig implementation.
Instead, the first half of it solely consists of personal attacks.
> We made futile attempts to guide them towards better programming practices. There were a few exceptional heroes who did their very best in a dysfunctional company. You know who you are. But you can't stop a rising tide.
So not only is Zig written by amateurs, but these amateurs also don’t know how to run a company?
Who is Andrew to say this, Oven got an exit. As far as their investors and owners are concerned that’s the only real reason to exist.
Assuming ( big assumption to be fair) all the early Bun employees got a fair amount of equity they’re all rich now. That’s a much better outcome than most startups.
At my first startup we had 6 day work weeks. I still remember staying up until 2 or 3am manually installing Postgres again and again. All we got was a paycheck. Although for me I went from a minimum wage earning college dropout to a 6 figure software engineer( at a new company).
As for actual coding…
LLMs will always do better work in a well known stable language than something relatively new.
I had to give up on trying to get LLMs to write working Haxe code. Haxe is too niche for LLMs to handle.
I personally can’t stand Rust, it feels like it’s designed for machines to write. Zig is designed for humans. Outside of a 200k+ job offer you won’t see me learning Rust.
Zig is rather pleasant. I can imagine writing a side project with it.
Finally, my QA background is screaming in rage. You expect me to trust a project that you basically vibe coded in a week as a key part of my workflow?
You know it works because the automated tests ( which I guess you also vibe coded) pass ?
By that logic say I don’t like Rust, can I spend a few thousand in Fable tokens and ship DinnerRoll( Bun in D).
>As for actual coding… LLMs will always do better work in a well known stable language than something relatively new.
Say that louder for the people in the back, who still think that LLM companies don't influence the entire programming language and framework field, by merit of the fact that LLM's can only perform at scale after lots of training.
And when we reach the point where source code doesn't need to be read, said companies will vendor lock you even harder by marketing their own LLM-optimized language and framework, promising everything and the moon in terms of productivity gains. First class support was the reason they acquired Bun.
> Doubtful. Think this move only works for someone with an existing product and following
So what you’re saying is actually build it, get it in the hands of end users and then find co-founder who does nothing but call his VC friends.
Maybe this co founder will be merciful enough to let me keep a 5% stake. Although in all seriousness, given Oven sold for ( Google AI estimate) hundred of millions that would still be more money than I’d ever need.
That’s the tricky part. Bun has a pretty big following. If you can replicate that at similar scale then yeah maybe there is a vc cheque for you in the future
| how their AI was powerful enough to do this rewrite (even though it was not powerful enough to catch a use-after-free)
This, I don't think enough people pointed this out. We have been sold the "coding is solved" and "software engineering is over" shit by Anthropic folks for a while now. The discourse should have revolved around claude's capabilities and instead it became a Jared vs Andrew thing.
I think two things can be true at once....It was obviously a great marketing story for anthropic but that doesn't automatically mean that engineering work had no value. Companies have always turned interesting technical projects into marketing.
I really don't understand what's the big deal here. Anthropic converted Bun from Zig to Rust using Fable and used that for marketing, but do people blindly trust them? Also isn't Zig still unstable and from that perspective regardless of how they did it, wouldn't it make sense to migrate it to a stable language?
>Judging from internet posts and HN comments, many do.
Judging from the HN comments in the past on Bun's rewrite. I wouldn't even use the word "many". It was literally all Anti-AI comments and reckless engineering behaviour complain.
Then that's their own fault. Nothing to do with Anthropic, it could have been any other company putting out marketing material and people blindly trust them.
I don’t understand the distinction you’re trying to make.
Yes, “it could have been any other company”, but it wasn’t, it was this one. Had it been any other company, we’d be talking about that other company; because it was this one, we’re talking about this one.
My point is that the article starts with
> Anthropic is actively campaigning to end software engineering
But that's true only if one believe what they are putting out blindly. Why not just call it a bluff and move on rather than making a mountain out of molehill
It's a big precisely because so many people are blindly trusting AI company marketing. It blows my mind how many people, especially here on once-subversive hacker news, are not just swallowing the marketing but they are doing the marketing for these companies for free. That's why it needs to be talked about!
I'm not involved in this community, but I watched Andrew's interview with JetBrains a few weeks ago and I was really impressed. I don't currently have a project that would benefit from zig, but it's a language I want to explore when I have a good use case for it. I view his take as blunt but entirely reasonable.
Bun's rewrite has made me nervous about using it. I do have a project that would theoretically benefit from it, but that amount of vibe coding just makes me nervous. I'm not saying I'd never use it, but personally I'd rather wait for the dust to settle on it a bit. I feel like rewriting to a new language is going to be buggy no matter what (even if the tests pass), but an AI rewrite in a very short time makes me extra concerned. Just my 2 cents.
Also, one thing I want to highlight in the article because I agree hard with it:
> My advice? Don’t work for people that brag about 90 hour weeks. Work for people who will defend your ability to sleep at night.
I used to work in the games industry, where crunch was the norm, and I don't think crunching really helped at all past a couple weeks. I'm not particularly old (early 40s), but my performance falls off a cliff if I sleep poorly or don't practice self care. To me, people working ultra-long hours for marathon periods of time are making a grave mistake. It usually ends up being productivity theater rather than real productivity. Taking care of yourself is really important for being productive.
If left to my own devices, I can code 12-16 hour days. Have a crash day every 4-5 days, and then go back.
It would be extremely unwise to merge even half of that stuff. I would frequently throw it away. Even before AI.
It would be extremely naive to think that I am productive/efficient or responsible or a hard-worker for doing this.
Hey, I can party the way I like to party.
(I am old enough to catch myself and stop this cycle now)
Edit: I was super impressed with him in the first 10 minutes. It’s very Knuth-like to create a programming language because you had trouble building an audio system.
Andrew may be a little bit grating to some (including me at times), but I value the perspectives that he brings.
There is a lot of discussion about the exact tone and phrasing, etc, of Andrew's post. There's something there - we expect perfectly composed writing, never getting emotional, never saying how we actually feel about a specific individual's behaviour. Meanwhile, in private, we often let those emotions fly, name names, etc.
I think Andrew gave us an actual look into how he feels about Jarred -- ambivalent, largely.
Anthropic migrated Bun from Zig to Rust, they probably tried writing it in Zig using AI and ran into issues because there isn't enough Zig training data. A year ago, most LLMs couldn' t code reliably in Rust, But were fluent in Python, C, and web tech.
Do you think this gives your claim extra merit? You understand it does the opposite, right?
What it actually achieves is that it makes you look like you're raging against the dying of the light, in utter and complete futility.
Yes, LLMs are especially good at the web stack, given that training data is overwhelmed with enormous volumes of such data. It is the one realm that has been completely obsoleted by modern AI, while a few other realms at least have some resistance.
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.
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. and here is that token heavy story!
so weird people are not commenting on this.
it's like.. I dunno, rewrite linux in rust, because bun uses glibc, this will somehow make it better, so claude code somehow can run better?
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.
This paragraph is written by AI. I did not notice it earlier in the piece:
> The piece about the migration process is very cool, with details that are reusable. No complaints, I think that’s the real contribution here. I particularly like the honesty in explaining that this was a port to unsafe Rust, allowing a literal file-by-file migration to minimize risk, paving the way for redesign in future steps. That’s a sensible move explained well.
I doubt that is what happened, but this is where I quit reading so I did not evaluate the rest of the article. I'm assuming the previous section was either largely written by hand or it was much more carefully edited.
We already know junior hiring an are down. And how many people are now excited to learn to code compared to 5years ago?
How many of those excited people are ACTUALLY learning to code and not just learning to prompt?
LLMs/agents will take over (or at least dominate) software dev even if they don’t get any better because humans will just get old and there’ll be no new humans who know how to do it.
Well, I see LLM coding capabilities as a great enabler for people who have some codeing-like skills or needs, but were not sufficiently skilled to do something more complicated. Think of people who are good at Excel, who use statistical tools like SAS, SPSS, other analytical software. Now they can ask LLM to create a Pandas/SAS lang script and do much more advanced stuff.
People who were in the marketing data analysis (like sentiment analysis) - 5 minutes and they have a code that uses Hugging Face model suited for sentiment analysis, zero-shot classification, etc. No need to pay for expensive online services or expensive NLP software. It's here for free or $20 a month.
Still, it does not mean you will be able to code database engine with LLM, application server, rewrite Django in Rust, etc. So software engineers still will be needed to do ambitious, complicated stuff.
So, I kind of see it backwards, real skills, like knowing algorithms, understanding performance (including hardware stuff like processor caches, etc.) will become needed, as other, simpler jobs that needed only a "coding monkey" will be gone.
We no longer need to dig ditches manually, we have machines for that, but the purpose of the ditches is still planned by man.
If you push that ditch analogy though. Yeah we no longer dig ditches manually - but we also then all got overweight and weak because people aren’t doing any physical labour anymore. (Most people anyway)
And diggers absolutely do have a monopoly on digging ditches now.
I don’t see how someone learning to code now will ever be as good at coding as someone who learned before LLMs.
Just like right now no-one is gonna get better at digging ditches than people were before diggers - it just doesn’t make sense for someone to put the time and effort into that.
This is quite true. Also, there is no project you can make as a junior to demonstrate your unassisted competence because 10 other people used AI for a similar project
Not to "glaze" the author as the kids say but this has to be one of the best written musings I've read on HN in a long time. I'm likely bias because it's written in "my style" but I feel like it's a rather fair and balanced approach to a nuanced and socially difficult topic.
Zig creator's article seems to have changed? I don't remember the bottom bit being there when I read it a few days ago.
> Ray’s story: Faced with a legitimate challenge of memory bugs, there were several viable options. Management eagerly approved the Rust rewrite option because it was a great marketing opportunity to showcase their new Fable model, Anthropic already uses Rust, and Zig is openly against using Anthropic’s products.
Kinda makes sense. They also tried to make a C compiler earlier in the year. Idk what happened to that.
I guess it's an experiment without much downside for Anthropic, if it works use it to make a point about AI assisted coding - if it doesn't bun users will learn a costly lesson but who cares, it will just be another case study to make their product better.
That said, I think it'd be great to see this actually work out.
I agree that both Andrew, and the author have numerous good points, and yet I see things differently.
- I too am a fan of Andrew, and Zig, although all of my future plans currently are tied to Rust.
- I think the crux is that we are talking about 2 Vibe-ish AI rewrites, one to Zig, and another to Rust. I believe the investment in both reasonably minimal beyond the cost of tokens.
- I think that more adherence to a Zig style guide would probably have been very beneficial to the final work product.
- I have high expectations that the Rust rewrite will yield a more stable work product out-of-the-box. I am looking forward to the post-analysis.
Wow. Wonderful post; best read this year so far. Lots of gold in this one. I like the way the author slowly undressed the - social media influenced - hype to reveal both Anthropic and Bun as they are: awfully basic
> we still need good judgement and communcation in deciding where to go
I want to emphatically endorse this statement.
This is where the human workload will shift to: making good decisions... understanding why one path is preferred over another. And collaborating and communicating in constructive ways. More to the point, humans excel at being able to recognize when a chosen path is no longer fruitful, or where a conversation devolves into the unproductive.
We are constantly making decisions based on tradeoffs. We choose one approach over another, not so much because our chosen path is obviously superior, but because the peril on our chosen path is preferential to the peril on a different path.
I have used ai to great utility in my design process, to help me understand the tradeoffs within any given endeavor, greatly helping in choosing which path to take.
Thus far, I haven't seen an AI which can unilaterally be relied up on to always effect "good judgement" for the work it is tasked with completing.
But once good judgement, and the correct path, is codified in markdown files, ai can be exceedingly
efficient in carrying it out.
> Anthropic is actively campaigning to end software engineering
While this may be slightly overstated, my take on this is that AI progress should have us upgrade our view of the human brain rather than the opposite.
I have found myself wondering a lot lately about the alternative universe where all the effort and resources devoted to developing and using AI coding and debugging agents were instead simply dedicated to fuzzing human-generated code. How would the code quality and total usefulness of the results have compared?
It should have been possible to build a new LLVM alternative, a new chromium like browser and some other similar things imo and that would have been definitely more impactful for me.
It is unimaginable how many static analysis tools or fuzzers could have been created with a fraction of LLM investment too.
For example honggfuzz was created by a single engineer possibly in less than a years’s worth time
The more I interact with the real world and mature as a person the less respect I have for temper tantrums such as these. Even if everything you say is correct, coming across as emotional and petty just does not help your case. This just makes Zig look like a zealot fighting a turf war rather than a serious ecosystem.
> The more I interact with the real world and mature as a person
I don't think this statement has the effect you want it to have. You're not laying out the experience you're speaking from. You're just setting it up so that no matter how reasonable the next thing you say is, it will appear maximally arrogant and condescending.
> I remember the uber db migration post and I can't help but wonder if the tone of these conversations would be different for bun if AI wasn't involved.
Another point of view is that, if AI wasn't available, pre-port Bun wouldn't have been such a total mess that even Fable couldn't unfuck it.
IOW, the Bun codebase was being vibed well before the port; if AI was not available, would Bun have been in such a poor state that a rewrite was even necessary?
The AI panic has infiltrated the space now, and it’s just as bad as the AI hype. Half formed ideas, emotional posts with personal attacks and arrogant language, exaggerated claims, posturing, etc.
In the meantime, most of us are just using whatever tools are at our disposal and minding our own business.
Anthropic isn't selling that, that's the point. Anthropic is selling "coding is solved", worth $1tn.
If they keep hiring developers and LLMs need huge procedural harnesses, then the hypocrisy is open for all to see. And worse for them, it probably means their business model is worth maybe 5-10x what Jetbrains is worth, not $1tn.
I agree that "coding" isn't solved but LLMs needing a harness is not necessarily a huge hit on AI
As for valuation, it's all a grift, always has been for anything hip in tech. SpaceX should've been in the $500b range and they have an actual rocket and working satellite constellations
LLMs needing harnesses is a hit on AI because it means LLMs can't be extended a lot (or indefinitely as AI boosters hope). We're back to (enhanced) expert systems from the 80s and nobody is excited about those.
And regarding SpaceX, SpaceX even without xAI didn't make a ton of money and it's business initiatives are super long horizon things. Moon bases won't be profitable for at least 10 years and Mars bases probably for 20+.
Also, even though they are behind, competition is moving. China caught their first rocket yesterday (and we know they can move fast), BlueOrigin is behind but they have the money to keep going. The EU and India will keep investing and developing as rockets are a core concern for both, at some point they will have reusable rockets.
These huge valuations for SpaceX are predicated on winner takes all mechanics, which are mostly software based. Many markets don't work like that since the cost to get another unit of revenue increases linearly with that unit. Not like software where extra copies and customers are basically free.
Compilers are widely available as open source software not coming from companies that need to justify a $1tn valuation ASAP for their development of LLMs.
Also the LLM = compiler comparison is generally just ridiculous. Their complexity, both internal and in usage for coding are multiple orders of magnitude apart.
Oh yeah, nothing complex about a compiler, that only takes 4 years of college to understand. That's soooo much simpler than typing "make me a Tetris clone".
Literally no one has 4 years of experience with LLMs, because they haven't existed for four years. Today's experts are tomorrow's college graduates.
Obviously the neckbeard who wrote C in vim and compiled when he is done is a better coder than the one who kept compiling and fixed issues when told by the compiler.
The neckbeards that wrote C did so precisely because they saw how C was a better way to get things done, and they were probably the first people to start using compilers, because, again, they're the ones that built them.
The neckbeards that wrote C tend to view LLMs as the obvious next step, and a lot of them actively use them for hobby projects even if they're not quite "maintain the Linux Kernel" tier yet.
In this whole discussion of what can be done with AI, I think a lot of people are missing the distinction between:
A. making consumer end-user apps, basic enterprise applications (making end products)
B. making tooling, libraries, languages (making things people build on top of)
What is the "software engineering" that AI will replace? A? Or both A and B?
Just because people can get away with using AI to make A apps that are "good enough" or pass test suites, does NOT meant that therefore people can get away with doing all software engineering with AI. B products require a whole other level of quality, stability, and extensibility.
I'm not saying doing A with AI is a good idea either, I just think that it's a fallacy to say that because you can do A with AI, you can do B.
Isn't it a case of "SVN trying to be CVS done right", as Linus Torvalds famously explained during his talk about Git at Google: SVN was doomed from the start because it's not possible to do CVS right.
Is this Typescript Zig any good? (don't know anything about it) Is it even worth porting to another language?
And why not an entirely new project? Ain't it an admission of failure of LLMs at writing new code? (porting ain't the same thing at all as writing a new project)
No dig at Zig: I just want to know if it's not yet another turd of the extremely turdy JS ecosystem.
Interesting article, seems more balanced than Andrew Kelley's one that it links to.
The thing I still think is wrong: why are Anthropic rewriting a Javascript runtime from Zig to Rust? Why not rewrite Claude Code itself in Rust (or Go or whatever, lots of options there) and drop Bun completely. That actually seems like an easier solution (rather than having to create a performant, correct Javascript runtime, just rewrite your CLI console app in something else) and the final result is better (smaller and faster) although likely not on the most critical axes for them.
I think Zig being a new and a low-resource language (not enough training data) is also one of the reasons Bun decided to use Rust as large language models will simply not be as good no matter how good the model is.
My experience was that LLMs performed at Zig and Rust at about the same level? That is: worse than at something like JS or C or Python, but well enough to write code that works. And they only got better since I first tried them.
Intuitively, Rust would perform worse because ownership is a different paradigm, while Zig is far more similar to things like C/C++. But I guess that's canceled out by the disparity in the language resource base.
Anything that can be written in Rust will be written in Rust.
I'm using Rust as a placeholder for a language with excellent performance and safety characteristics. It may not be a good thing, but there's no way around it.
If we expand the placeholder, I think "Anything that can be rewritten in a language with excellent performance and safety characteristics will be rewritten in a language with excellent performance and safety characteristics" is a desirable state of affairs.
if I had to pick a side, I would pick Andrew but I don't think his side matters as much. IMO, it doesn't matter the technical reason why Jared ported Bun, it's his project, his wanting to do so is enough. I think the issue is that Jared turned it into a technical subtle reason of why "Zig is bad" without meaning to, and Andrew goes on the defense.
All that said, the coolest thing is that Jared did so, I don't care if it came out a bit worse with Rust, the interesting thing is here is what can be done with AI/LLM/Agents today. Yes, it might be worse, but on a reasonable enough timeline, it will get better. Folks get upset about these things. I did AOC in 2024 with LLM, my goal was not to top the leaderboard, but to see how good LOCAL LLMs could keep up. I did it with Qwen2.5-Coder-32B locally, and solved about 50%. Folks were often upset when I shared that, called it cheating, etc, even tho I often started about 8hrs after the competition due to timezone. It was so good, I suspected the cloud models would probably solve 75-80% and I concluded after my experiment that in 2025, LLM can solve it 100%. I didn't bother to try and the models were an order or magnitude better locally.
No matter the take on AI, they are very capable tools and we are only beginning to figure out how they can be used. I don't think we should stop, surely it's frightening on what that would mean if it can really "takeoff". This fight is multi layered, Zig vs Rust, Writing good code vs bad code, having good development standard vs not, being honest and transparent in technical disclosure, attacking Zig vs attacking Jared, AI good vs AI not, etc.
Oh, they're converting Bun to unsafe rust. That's easy, but useless. That's the sort of thing c2rust does - transpile to an low level language which is unsafe Rust with a set of functions that unsafely emulate C pointer semantics. You don't need an LLM for that.
There's no point. It's not doing the job DARPA's TRACTOR program is trying to do - translate C to safe Rust. I've used c2rust. It works, but what you get out is like compiler output, not something you can work on.
> Oh, they're converting Bun to unsafe rust. That's easy, but useless.
You really need to escape the Zig vs Rust language wars bubble to get a real read on what Bun was doing.
They started by attempting a more direct translation. Not quite transliteration but close. At this stage they wanted to bootstrap the codebase into Rust as quickly as possible using parallel agent sessions, which requires minimizing the number of refactors that cut across the codebase. After it was bootstrapped into Rust they continued on the rewrite to take advantage of Rust’s features.
The anti-Rust side has been clinging to that first step as evidence that it’s all broken, ignoring the fact that it was an intermediate step.
The “unsafe” part is also confusing a lot of non-Rust devs who don’t understand that unsafe is used in cases of crossing FFI boundaries, which Bun does a lot of by nature
> ignoring the fact that it was an intermediate step.
They are going to release the "intermediate step" with all its issues as v1.4. I think that says a lot about which party is ignoring facts. (hint: not me, not you, not Andrew)
> The “unsafe” part is also confusing
They are right in this case. The code base contains thousands of the most unsafe unsafe blocks I've ever seen in Rust.
The Rust toolchain is a delight in comparison to Zig's, and the unsafe code only need be temporary until humans (or, gasp, AI) address each class of underlying issue.
Great Article. I appreciate the amount of detail you went into here to give everyone a fair hearing. Will there be a recording of your talk at the software should work conference next week? Thanks!
I don't agree that Anthropic's position is AI is all you need. My interpretation is that it's about developer acceleration. I've been following their messaging closely and it's not that you can fire all of your developers. It's mostly their developers saying they are somewhat more productive. They have published papers showing that productivity gains are uneven.
There are billions of lines of garbage code out there written in C, C++, Java, you name it. So much garbage, it has driven people to create languages with tighter guardrails to help programmers.
Yet, I've never seen those language creators blame anyone else. I don't recall Bjarne Stroustrup lashing out at people migrating from C++ to Java, Rust, or anything else.
I think I got all the information I need to be able to judge that article from seeing that the author calls themselves a "Retrofuturist Software Mender".
> The Bun code is a mess because of their engineering decisions, including overusing AI agents to write and review everything.
Life would be paradise if people were just good for each other. They are not though. So you need a system for that case. Rust is a system that fits the modern real world software development dynamics than Zig.
Keeping it to the most mainstream, Java is a mighty fine choice as well, with even better options for third-party packages, tooling, integrations, and telemetry than most of the above.
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.
There is going to be a lot of this kind of thing as AI makes writing manual code optional at best. A project that bans use of agentic coding is going to have a slower development cycle, as Zig is already fairly pedestrian (for said reasons) it's going to become less and less relevant i'm afraid.
There will be a group of programming languages that become the main choices, (Rust, Go, Typescript, C++, Java, C, Lisp and Haskell) for agentic coding, Zig was slightly too late to the game, the great LLM cutoff has happened.
Andrew is trying to fight the tsunami here with a paddle boat as his vision of Zig was conceived before LLM's landed on the scene and is likely unable to accept it.
I wonder how AI is going to affect language development and discussions like this. Zig taking anti AI stance is commendable, but it’ll surely hurt adoption.
Interesting thread. On the verification side — do you think formal methods or fuzzing scales better for catching the class of bugs LLM-generated code introduces?
Those problems are partly attributable to Zig itself. If the project accepted AI-assisted contributions, this controversy might never have happened. Completely shutting out one side of the industry and taking a dogmatic position is not helpful, especially for a pre-1.0 language that is still relatively immature.
Now the Zig community is attacking one of the largest and best-known codebases ever built with the language. Anthropic’s motives are clearly promotional, but even so, I would not choose Zig for any project.
> Completely shutting out one side of the industry and taking a dogmatic position is not helpful, especially for a pre-1.0 language that is still relatively immature.
It is useful, you just have different goals in mind than the Zig leadership. Zig shared their detailed reasoning for that decision, which is mostly about the development and protection of the community
I'm on the same page with you that their AI stance is probably harmful for them -- but I think they wrote those as a reaction to the contributions from Bun and others. So your implied timeline is not entirely correct.
Nobody should feel insulted simply because a project decides to port its codebase to another language. It is a technical decision, not a personal attack.
Zig’s response has been a serious mistake. The TypeScript team ported the TypeScript compiler and language service from TypeScript to Go for TypeScript 7.0. Did anyone interpret that as the team insulting TypeScript itself? I certainly did not.
They don’t care about the switch and it seems they’re actually happy with it. What they care about is the implied messaging that Zig has issues that the rewrite in Rust solved. Andrew highlighted that they had bad engineering practice, the rewrite did not solve anything, and they invested a lot of engineering with Rust to try getting things to work, engineering effort they have not invested in Zig.
> Did anyone interpret that as the team insulting TypeScript itself?
No because Go and Typescript have wildly different use cases, and they explained in details the rationale for migrating the compiler, and why Go versus Rust. Their rationale makes sense, and did not throw Typescript under the bus (obviously).
Yes, why would Zig respond seriously to a company that has proven to have utter complete disdain towards humanity? Why would anyone be upset that a company is ruining workers lives, poisoning innocent civilians, and being used to kill school children?
Agreed. The outrage around what Andrew said was performative and melodramatic. I remember the "no work-life balance if you work here" thing, and then I remember Bun's CEO last year complaining he might not be able to get H1Bs anymore...
And this whole thing reeked of a publicity stunt. Show people you can use $$$ of tokens to vibe code a refactor. The headline is how great anthropic - bun's owner - is.
A lot to unpack here, setting aside the drama I get a few takeaways:
- Your AI code is probably as good as your human user's skills and attention:
Seems pretty likely they were shying from style guides because the AI use was itself sloppy. I'm not a big AI user but if I just ask a chat model for some code it will give it to me, then I have to go over it and fix the code for our check-style. Without deliberately aligning all your AI use to enforce it style is hard to maintain. Existing lack of style was a technical debt they didn't want to pay.
- The most popular language is probably the best language:
I suspect the amount of training data on Rust is several orders of magnitude greater than Zig. I suspect they could have gotten there simply asking the LLM to rewrite the Zig thing in Zig, however I'm betting LLMs write much better rust code so why not take the opportunity to move to a language that will get all-around better results.
- Technical bankruptcy is more favorable than paying technical debt:
These migrations we're seeing seem to point to a future where it's simply easier to burn a code-base to the ground, take the test suite and re-implement rather than actually pay large amounts of technical debt. I think this is a pattern that will come up more often with heavily AI written codebases that become untenably noodley, or brittle.
One of the things I find so disappointing about Kelley's behavior here is that he falsely accused Jarred Sumner of lying about fuzzing Bun, and then when Sumner showed evidence[0] that they've been fuzzing Bun for months, Kelley just silently edited his post[1] to walk back the accusation and never apologized or admitted he was wrong.
I commented on Mastodon[2] to point out to Kelley that it's dishonest to silently remove the accusation, as so many people were already talking about it, and it confuses the conversation if Kelley retroactively edits it, and he replied[3]:
> the false claim is in the bun blog post not mine. I only changed the text because it's easy to lazily argue against it. Please read more carefully. They are the ones being deceitful not me.
Loris Cro, Zig's VP of Community, gave a slightly clearer response[4]:
> Jarred's post has a section about what they "were already doing" to maintain their Zig codebase, which includes "24/7 fuzzing", which will make the average reader assume that the codebase has been fuzzed thoroughly, while in reality it has been for, what, 2 months before the rewrite?
Even then, I find it so bizarre that Loris thinks that if someone says, "We've been fuzzing Bun," and shows evidence of months of fuzzing, then that person is lying because "We've been fuzzing Bun" somehow implies something longer than two months.
The duration is irrelevant. If you say you've been fuzzing it and you've fixed bugs that your fuzzer found, then clearly you're fuzzing. The Zig team doesn't get to arbitrarily move the goalposts of what "fuzzing" means.
If Sumner says today, "We do X," then Kelley can say, "Nine months ago, Sumner did not do X," and both can be correct. What Kelley can't do is say, "It's an outright fabrication that Sumner does X today," based on an observation from nine months ago.
Now you've misquoted me. Actual quote[1] is: "This appears to be an outright fabrication."
To quote yourself[2], "The honest thing to do is acknowledge that you were mistaken and apologize for the false accusation."
Are you going to do that for me now?
I don't expect you to, because I don't think you are being dishonest. I think you are earnestly trying to untangle the facts from two parties for whom you have no bias one way or the other, which is commendable.
Like you, I am an individual attempting to paint an accurate picture of reality for my readers.
Anthropic, on the other hand, is not an individual nor trying to be accurate. They are doing exactly as they are supposed to: maximizing value for shareholders. To do this, they need to make this rewrite appear successful, so they need to retcon this idea that they were doing good engineering practices in their zig codebase the whole time, including fuzzing, even though that is not the case.
Dude just stop. This has been embarrassing and damaging enough to your reputation, you should just give it a rest for now. Your friends have made you self-aware enough to realize you have unprocessed emotions about this — process them. Best to get out of the comment section, and your head. The saying is if you’re explaining you’re losing. I’m not a fan of Bun or Jarred but of your Zig work. Stick to that, it’s where you serve the community best. In the future, just present the verifiable facts and you’ll be okay.
"Anthropic is actively campaigning to end software engineering" - good but are they the only ones? I do not like Anthropic after their recent locking mechanisms. I use opencode with GLM, Mimo, Qwen, and what not. I use Codex as well.
Anthropic does not need to tell me that much of software engineering is being re-written. In my opinion, the costs have crashed. I build commercial projects at 1/3rd my earlier costs. I started build everything I can in Rust and I am still doing that. My projects have only gotten more ambitious, latest being https://github.com/brainless/akar - a WIP, please don't scream at me.
Many folks have publicly said they want to keep AI agents away from their works. Good for them. I want to accelerate software engineering, something I have done passionately for 20 years, with all the agents I can use. And I make my own agents, constantly experimenting to push local llm based agents.
If engineers want to stay behind, good for them. Not everyone does. Andrew Kelly's post read like an attack, IMHO. But why care about me? I am just a farmer (https://www.instagram.com/curryhostel) who uses AI to now build ambitious software.
I’m puzzled by how many people seem to be convinced (deluded?) into believing that their productivity has been multiplied and costs have become fractional to build things, why don’t I see any of that productivity gain or cost reduction out in the world? What has become cheaper or better engineered? If you believe posts like thsi, we should be living in a golden age of prosperity, when it seems that aside from getting better lots of products and companies seem to just be getting worse? Like seriously, to a normal person, putting aside from the benefits of using LLM’s directly for the LLM user, what things in the world have gotten better thanks to this abundance and oversupply of “intelligence” that is supposedly mutiplying people’s productivity?
A lot of those products are from big companies who seem to be struggling the most. Software does not solve bureaucracy. As an indie engineer, I have absolutely no doubt what I am doing myself.
But that change does not mean my products will become popular. That is a lot beyond software. Also, the tooling is just barely 1.5 years old and people are already asking for world-changing results. All the while totally ignoring what indies are saying.
I kind of disagree that asking for world changing results is setting the bar too high, people’s claims about their personal experience are that the world changing results are already here, productivity has been multiplied and costs have been reduced by some factor, and AFAICT everyone is using these tools, with many reporting a similar experience.
The fact that people’s personal experience using the tool don’t cohere with the impact the tool has had in the world to me doesn’t suggest a slippage between how long it takes for productivity multipliers to be felt, it suggests that these tools might actually be better at delivering the perception to the user (and where relevant, the user’s manager) of increased productivity while real productivity gains are lower, or maybe zero, or maybe negative in some cases.
The key word is "already". I myself absolutely expect world changing results. But that will need time. I can only say what I know. My own experiments in building nocodo, a coding agent are 12-13 years old. Pre-LLM. I used template based code generation and related ideas. Template processors and what not. nocodo.com is with me since 2013 maybe, you can verify.
I am a software engineer, most of my experiments are on GitHub. I would not have ventured into building the UI framework before LLMs.
And this is what bothers me - people are not looking at the generated software. Indies like us are experimenting like crazy. I live far outside the tech scene, in a small Himalayan village. But I resonate so much with the experiments, the methods, harness engineering and so many other topics. I see the benefits in how ambitious my projects are becoming.
I teach an online course on coding agents as a co-mentor. 600 young professionals join each month for a 2 week course. The joy of people, who did not know much technology, when they create a simple project management software by just typing English does not lie.
We used to write software in a very different manner. The entire mental paradigm has shifted. Many of my friends and acquaintances are on the fence, still! Some are internally giving up - unable to cope with this change. But the change is happening - the tooling is only going to get better.
Interesting! I am curious to ask someone who has been working on no-code tools for so long: I've been reading about no code platforms from the 1990s, and how all of those ended up failing. The reason I've seen cited most is that the tools/platforms did not allow for enough variability to do the jobs that people wanted (without becoming a full programming language themselves). What do you think about that in the context of the past ten years, pre- and post-LLMs?
And what do you think about coding agents in the next few years? Will we see a variation in agent capabilities? E.g. a company makes and distributes a specialized coding agent for CSS, or even serving up a kind of library that's language-agnostic, since they seem to be best at translation rather than creation?
"company makes and distributes a specialized coding agent for CSS" - weird that you think this is a path because I think this is not as appreciated as it should be.
No-code has been in a poor state for many reasons. I agree that people want more generic software to be built and the platforms did not allow for enough variability. This is what being better enabled with LLMs.
I think coding agents, particularly Claude Code, makes people think that models are the key. Some people disagree. I disagree as well. I think small models with lots of deterministic code is the way. But this will not fill Anthropic's or OpenAI's pockets.
Using an LSP, for example is recent in coding agents. But if you think about it, we should have started with that. Most agents expect LLMs to know too broadly. I would instead create 40 (random number) agents - one for each language and part of the stack. This is why your CSS example is interesting. I create just an agent for the ORM related code in a Rust/Diesel based coding agent. It worked with a 4B parameter model!
People will fight over "worked" but basically what I did was create deterministic code generator for the ORM layer - schema, model and model accessor or mutator functions and then asked the tiny model to fill in the code with lots of code example straight from the official docs. It played well for many different kinds of prompts - all focused only on model related changes.
What if we create many layers of this - a higher level agent breaks human prompts into an intermediate language and then tech-stack focused agents write the code within deterministic tooling. Agents cannot read or write any file they want - they are specific to that part of the stack, linter, compiler, etc. kick in automatically.
> it suggests that these tools might actually be better at delivering the perception to the user of increased productivity while real productivity gains are lower, or maybe zero, or maybe negative in some cases.
Or that the gains are in niche applications (like the GP's) that don't translate at scale.
> Like seriously, to a normal person, putting aside from the benefits of using LLM’s directly for the LLM user, what things in the world have gotten better thanks to this abundance and oversupply of “intelligence” that is supposedly mutiplying people’s productivity?
For the normal person, they now have more choice. To businesses it is an even more fierce competition. There is an illusion of productivity since everyone using LLMs can’t stop because their competitor is also moving faster with LLMs.
So everyone is so “productive” in “building” anything at the third of the cost, it also means that even the customers that the builders are selling to are also building their own solution themselves.
Customers turn into competitors faster and those in pure software are now making even less money. Except for companies in frontier AI, infrastructure and hardware.
I am not sure if you mean good, bad or ugly but yeah this username is perhaps with me since 1998. I used to hang around in MIT, Stanford and many other Uni IRC rooms. I was this odd username from a far away city. Tim Berners-Lee once asked me about the real person behind the username. I almost shat my pants but somehow I answered.
I am sure you have a great story for your username and the blank HN profile too.
Looking at your profile it's clear you're heavily invested in passing the idea that "AI is going to take our jobs" as if you have some money in the game ...
Yes, I know that is how it would seem in this ultra-capitalistic world. But no. I am a believer, follower of Sci-Fi and a dreamer. I see AI as way to tear down structures - "When everyone is super, no one will be".
The next 10 years of software can either centralize power, like we have done in the 10 years past. Or, we could open up for everyone - every mom and pop business can run their business with the best software - their own workflow.
I do not believe in the systems that have led us here and I see AI as a chance to rectify. I live in rural India, by choice. I am 44 and kicking. Have a farm, dream life and a chance to bring change I have dearly wanted - true empowerment. Big Cos/SaaS have brainwashed people away from what software for people could have been. Time to change that.
programming language creators have now fully pivoted from 'my language is faster than yours' to 'my corporate criticism is sharper than yours' and honestly it's an upgrade
Wow, it's unsafe Rust? That seems... like the worst of all worlds.
If nobody knows why the unsafe is required there's no way they'll be able to unwind it. If they can't unwind it then they're in a worse version of C (+ cargo).
Sure, but you cordon that stuff off into small, bounded unsafe surfaces. My bet is the new bun is a crashy pile of garbage if they've just translated Zig spaghetti into Rust unsafe spaghetti with an LLM. Hadn't occurred to me.
Fair, but that's also kinda like saying "we translated it to ASM as an intermediate step to C". The hard (and valuable) part is safe rust. If unsafe is everywhere, there will be abstractions that simply have to be reengineered to use safe rust. Maybe it's a way to hit the "finish line" quick in terms of using Rust but a pure unsafe translation seems almost as far away as the original Zig project.
All right there is so much hate for this rust rewrite, but I'm going to tell everybody that people are way way underestimating how sucky the Zig codebase was.
Basically all the time people were having horrid memory leaks and stuff that they couldn't even figure out.
So yeah, I get it, people are frustrated, but stop pretending Bun was this battle tested mature thing. It was a prototype, and still is.
Switching it to Rust is understandable since they just couldn't fix the memory leaks. It was and still is in beta, because anything with memory leaks is beta.
So yeah, I understand the concern but nobody would ever use it in production anyways for a server now because of the leaks so treat it like what it is - beta software and a cool experiment.
> The marketing needed to focus on how their AI was powerful enough to do this rewrite (even though it was not powerful enough to catch a use-after-free).
> The hearsay is essentially repeating what was announced publicly. Their job listing might as well have said, “now seeking applicants for total shit show”. It’s bad form for us to say this out loud.
It's a good thing to point out these unspoken truths explicitly. As people internalize the norms that make it bad form, it becomes easy to skip the mental step of acknowledging the problem. Even internally. But that quiet acknowledgement is necessary to keep oneself sane. Without it, the best case is someone steers away without good reason, at worst it leads to experienced and expressed frustration that doesn't add up and can snowball into the wrong places.
There's so much weaselling in this post. His suggested solution to Zig memory errors is to never dynamically allocate memory? I mean... come on.
He complains about the lack of motivational blog post until after the merge, but a) they aren't obliged to do that (where are all the "it's free so you can't complain" people now?), and b) they gave plenty of motivation in HN comments, the rewrite PR, etc.
I don't like the idea of AI slop code either but it seems to work at least reasonably well for porting from one language to another.
The only reason we're paying attention to this is because of the drama.
The fact that rust is likely more interesting than zig (which is also interesting) is indictated by community size (and other signs like linux kernel inclusion).
The fact that anthropic is very likely overselling their timeline and max-utility for an IPO is generally well accepted as well.
Also that us tech bros are somewhat annoying is also well understood.
An excellent analysis. So the Bun rewrite story is full of contradictions, irrationality, and bullshit. Not that that's really a surprise at this point.
It's hardly really about Anthropic. It's about all the people who funded them, and other AI companies, who are on the campaign by funding Anthropic seeking to end a majority of life for most humans.
Because that's what it really appears to be about, preserving a rich man family's legacy so his children can live for another few generations before they over populate and humanity repeats the cycle of indefinite war, hoarding of resources, and killing to have more for yourself. I guess every rich, powerful generation though doesn't think that future will come now, so they keep manipulating their way to extracting more and more from people and stealing their way to the top.
When a majority of the population is sick, naive, and overstimulated its not hard to convince them with your propaganda that that you are on their side and that the sacrifices they make for your power are worth it. of course they don't see how their life spans, their deaths, etc were for you cause and not theirs.
I have no beef in this flight -- I don't write Zig or Rust or use Bun (other than using Claude Code which runs on Bun, but that's an implementation detail that I don't care). But the more I look at this, the more I despise Anthropic and respect the Zig foundation. One is like "we can do whatever we want because WE HAVE MONEY, what can you do about it", the other looks at things from a engineering perspective.
It will be sad if everyone buys Anthropic's hype, forget the basic engineering principles in this industry and think that AI solves every problem. Fortunately lots of people don't.
Let’s assume their marketing argument is in good faith (it isn’t, they’re just capturing market knowing very well they won’t replace most software dev):
Where did Anthropic say that they want to “end” software development. They make it more efficient, which could lead to less software developer.
How is this “campaigning to end software engineering”? It’s an exaggeration at best, dishonest and sensationalist at worst
This article explains what they mean by end of software engineering:
> his engineering teams rarely write code from scratch anymore. The role has shifted from creation to orchestration. Engineers now operate as “conductors”—defining high-level problems, prompting AI systems to generate implementations, then reviewing and integrating outputs.
Well I have been working like that as well but sure as hell I still consider that to be software engineering. You won’t get anywhere if you try doing this without being a software engineer. At least not very far, see how far purely vibe coded applications can get.
Can you point out exactly where it says that? As I read it, the claim is that AI boosts the productivity of writing code to the point that it's usually not productive for humans to write code directly. I think that boost only goes so far -- safety-critical code still needs to be well-understood by people, and a lot of the higher level thinking has insufficient ground truth to train AIs on it -- but it's fundamentally a claim about transforming software development rather than ending it.
Anthropic leadership, including CEO Dario Amodei and co-founder Boris Cherny, has declared that software engineering is dead or will become obsolete within 6 to 12 months due to AI automation.
Cherny states that at Anthropic, no code is manually written anymore, with engineers using Claude Code to generate 22–27 pull requests daily and AI agents operating in autonomous loops.
very narrow vision, openai and anthropic realized what they have probably won’t lead to agi so they moved the goalposts to replacing jobs, programming just happened to be the easiest field because engineers are technical, willing to pay, and the input/output is relatively easy to measure, even that has problems though, a lot of managers are noticing that code generation is fast but actual production output doesn’t improve at the same rate, anthropic basically bootstrapped itself on coding and now they’re looking for higher paying fields that put less pressure on their servers
So much drama between all these completely irrelevant actors circling the drain.
Anthropic have lost their minds, and eventually a metric shit ton of money. Meanwhile, nobody uses Bun or Zig either. Rust continues to chug along very very slowly.
Writing the blog post took longer than the million line Rust rewrite. That is all someone with a few brain cells needs to understand what’s going on here.
Probably just you. I use them somewhat frequently to make it clear where a set breaks down into alternatives or parallel factors. If there's a preface and trailer around a list of complex items, I think writing the list in one paragraph is often ambiguous and hard to follow. Using a bullet list within that kind of paragraph (IMO) makes it easier to follow what I think is important.
To me it seems as if the AI corporations declared war
on software engineers in general. I understand that
many software engineers have already been addicted
to e. g. claude (look at github, you see tons of
"co-authored" rubbishness here) but to me it is clear
that the AI corporations also work against the humans
here - this example of the creator of the zig language
(which I don't use myself, as I dislike several
design choices made) being harassed by Anthropic shows
this clearly as well.
Yeah, but argumenting that "Bun codebase is a mess" is anti-Zig in itself.
The whole point of the borrow checker is to make it impossible to write wrong code. If Zig accepts bad code, but assumes people will have self-discipline to maintain it, how is that different from C?
C assumes good discipline, as well as C++. But it will happily accept bad code. So I'm not even sure what Zig is even improving on.
Rust was designed to answer this exact problem (among a few others of course).
So the argument "your code is fscking sheet" is very 1990's. In 2026 we need guarantees that we can't produce invalid code.
> The whole point of the borrow checker is to make it impossible to write wrong code.
> In 2026 we need guarantees that we can't produce invalid code.
Rust doesn't provide either of those guarantees.
If I were to rephrase your sentiment for accuracy: Rust disallows certain coding patterns. Certain classes of bugs can only appear in those coding patterns.
IOW, Rust disallows $FOO which is a superset of "specific class of errors". This means that while Rust prevents specific bugs, as a side-effect it will also prevent some correct code.
The borrow checker is a good tool (and it makes Rust objectively better than Zig to me), but it unfortunately doesn't prevent writing bad code
An issue with Bun is that it interfaces with a C++ JS engine and it needs unsafe. In this case, the best practice is to write a safe binding to encapsulate this external dependency (that's why in Rust we have -sys crates with raw unsafe bindings, and other crates with a safe interface on top), and then write your business logic entirely in safe Rust
However, the Rust port of Bun didn't follow such best practices (perhaps with good SDD practices it could, not sure about that). The resulting code has literally thousands of unsafe blocks. It also contains plenty of UB. The port already costed hundreds of thousands of dollars. It's unclear if Mythos/Fable is able to refactor it further to remove unsafe usage without introducing further UB, and how much it will cost
(here It's important to note something. Rust UB is in some abstract sense harder to deal with than C or Zig UB, because it also needs to uphold the guarantees of safe Rust. If you get to write your business logic in safe Rust that's a good deal, but the price of that is that your unsafe code has extra responsibilities)
Rust requires discipline too. I can go around using Arc, Rc and .clone() everywhere without upsetting the borrow checker, I can use let mut a bunch and pretend if, match, etc. aren't expressions. This results in worse code, and Rust didn't stop me.
The borrow checker prevents a set of errors from being possible, but it doesn't prevent bad code from being written.
It would be easier for you to argument that the user is expected to have discipline to NOT use "unsafe" keyword in all functions.
Because a lot of mechanisms actually still have guards in runtime. And using .clone() on Rc/Arc is actually the idiomatic/preferred way of evading the borrow checker if we can't design the data structure in a different way.
It's a big difference between cases when you need to spend brain energy to find ways to "out-smart" the compiler, and spend brain energy to "fit into the proper set of assumptions" of a programming language.
Static memory safety is a spectrum and so is code quality.
> how is that different from C?
Zig gives you far more memory and type safety than C and without a borrow checker and a complex generics system.
Zig also allows optional runtime checks (at the cost of runtime performance).
There is no better language between Rust and Zig because they have different tradeoffs that are better or worse in different scenarios. It is more like Rust vs C++ and Zig vs C.
I disagree; Rust's type system, which supports pretty rich algebraic data types, makes it easier to specify the correct data model for your system than it would be in languages with simpler type systems like C or Python. The ability to define enum types with arbitrary shapes for each variant, and then match on them in code, allows programmers to build better, more-accurate abstractions and have less fear of screwing up and causing a logic bug.
In my experience, it absolutely does (at least if you use it idiomatically). Using the type system (esp. enums, Result and newtypes) makes a good bunch of invalid states irrepresentable.
This also helps to focus on the remaining things that could go wrong.
The integration of unit tests also lowers the barrier to just sprinkle some tests in, if you're unsure that you got an edge case right. Anf clippy (not stricly the language, but still kind of a core component) greaty helps to stay on the idiomatic track.
No silver bullet of course, but I never had so few runtime issues with any other programming language so far.
This post is ultimately complaining about a build step consisting of an automatic translation from technically irrelevant language A to technically slightly less, but still substantially irrelevant language B.
I don't care what Anthropic says and what the CEOs buy, I care about my own output and the recent models give me 2x uplift easily, I'd say 10x in single digit percentage of the time and I know I'm not using them to their full potential. We're living in an era of mass produced software. You can still be an artisan in this era, but you have to be aware.
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 suites). Also:
"this was a port to unsafe Rust, allowing a literal file-by-file migration to minimize risk"
How is that better than the Zig codebase you started with?
Now if that's further migrated to safe Rust, put into production & gathered feedback from lots of users, yes then you have something. As it is, the impressive bit is do such a big rewrite & result seems to work ok. Are Bun users happy with this?
To me it reads like Bun was forked. Will the Zig version survive? Will the Rust one? Both? All options ok.
Edit: and fwiw, I don't think Zig community should get triggered on any of this. It says nothing about how suitable Zig is or isn't for project xyz, and Zig community is big enough to carry their own project & applications besides Bun.
They get abandoned because they get generated on a whim.
Sunk cost fallacy can be a feature: if you have spent a lot of blood, sweat, and tears on a project, you are more likely to push it through adversity and the doldrums that inevitably one will encounter. If all it took was one of those momentarily brilliant ideas and a prompt on Claude to produce something, there is no attachment whatsoever to it.
Speaking as the ‘average programmer’, I have dozens of brilliant ideas per day that don’t stand the test of time or scrutiny, and the very few that pass the filter don’t seem that interesting days later, or worth the effort at all.
Ideas have always been cheap. Now, proof of concepts have become as cheap. I don’t care about your Show HN unless you have spent a month on it.
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 the wild asides you tend to talk yourself out of still on display.
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 world of pure though, in a sense, so most of the friction already lives in your head, and it is difficult to distinguish effort wasted fighting friction from effort making real progress.
Consider the Wright brothers. They worked iteratively. When they wanted to design an airplane they moved from Ohio to a windy place with lots of loose sand (NC outer banks). Why? So that they could do test runs with good wind conditions (for an airplane that is barely able to fly this matters a lot) and crash with the least amount of damage. They rebuilt the airplane dozens and dozens of times and had a workshop tuned to their needs on location. They reduced friction wherever they could so that they got the most work done that they could with the least amount of distraction.
>Programming is done in a world of pure though, in a sense, so most of the friction already lives in your head
It seems that way, but that's not actually true. A fully greased-up brain would produce just incoherent nonsense decoupled from reality, because it would lack all constraints that would allow it to judge the value of an idea (i.e. how possible and useful it would be to implement in the real world). The friction comes from fitting your ideas into the real world.
>They reduced friction wherever they could so that they got the most work done that they could with the least amount of distraction.
They reduced unnecessary friction. They could have eliminated all friction by imagining a teleporter machine that can send you anywhere instantly and that runs on the hopes of children. But they still wanted the friction of unsuccessful attempts so they could actually build a plane that worked.
Your concluding example doesn't make sense to me but I think that it's because we have different definitions for what friction means here. It's also kind of hard to define in context.
I would say that, within the Wright Brothers example, working with a battered, worn-out screwdriver is an example of friction (or, perhaps having to use a bit and brace instead of a power drill), but the act of building a new unsuccessful airplane iteration is not friction. Every build is asking physics for feedback on the design; every airplane build is just the same as running your code through the compiler. I wish I had a good word to distinguish this from friction. The closest thing I can imagine is how waste is defined in Lean Manufacturing, but keeping in mind that what you are manufacturing is Ideas and Software.
It sounds like you're not disagreeing with what the other person was saying then, you're just disagreeing with their application of the word "friction". I don't think it makes much sense to argue about the precise definition of a metaphor.
Didn't see this reply before adding my own. Yes, I think we're in agreement.
fair enough. I'm probably still in disagreement with the friends I mentioned earlier!
I liken it to dieting. If your only goal is to be certain weight, then learning how to cook, learning how to portion, learning to make a meal plan, learning about macro nutrients is all "friction" now that we have GLPs. And maybe using a meal prep service reduces some "unnecessary friction" but you still would have to learn a bunch of useful skills along the way.
Concretely, If your only goal is to produce "software" then learning about design, planning, project management, testing etc is all unnecessary friction when you can just ask an LLM to "make it so"
Nitpick, but this is misunderstanding GLPs (I'm on them). If you don't change your diet and your habits, yeah, you'll temporarily lose weight but it'll come right back when you're off it AND you'll lose a lot of muscle. You kinda still need to do "the right things", it's not a magic cure all. (Of course, same thing can be said of AI).
GLP's don't make you lose muscle. Losing weight without exercising does.
You'll get the exact same muscle loss with a CICO calculation weight loss.
A fair callout, though yes it was supposed to be a simplified analogy. I think you got it exactly right though that its temporary in the same that I'd argue the benefits of using AI are temporary
I definitely agree with your overall point, just wanted to correct that one thing.
As someone who has been losing weight over the past year, the cost of GLP1s is and was a greater point of friction to me compared to just eating less garbage.
I think this is just my choice of wording, friction as a means of slowing down and thinking something through is useful. Friction isn't just a roadblock. For all the times you want to do something exotic, throw an hour or two at it and in the process realise it was a bad idea and a more elegant idea emerges. That, that's the kind of useful friction I mean.
But overall yes, time spent thinking is the thing that matters.
It's less "there should be more friction" and more "LLMs remove too much". Instant gratification is great if you're a consumer, awful if you're a creator.
> 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.
I think that friction of feedback and friction of construction are two different things. Having lots of tokens to build things doesn't mean you have more feedback. I'm a bun user I like it. I can't really comment from my use on what the Zig vs Rust rewrite means to me.
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 have done is massively reduce the friction of intellectual effort, completely devaluing most expressions of it.
You can't build muscle without resistance, you can't cook ideas without friction.
Both needs heat.
If you wanna travel faster you can build muscle, or you can just get in a car.
You have to get licensed to drive a car and there are rules. If you are caught breaking the rules you can be fined (or jailed if your rule breaking harms others enough). In extreme cases of rule breaking you can lose permission to drive the car.
This is all friction that is intended to make car-driving work at scale.
Zero Player Games and Cow Clicker calling...
There really, truly, absolutely, 100% is no accounting for taste...
brings back fond memories of idlerpg
In terms of removing friction, I think of moving a boulder. Wheels = good. Ice slide = bad
I don't think it inherently devalues it. But the mediocre baseline for it and how much it entices you to allow it to just spit out that mediocrity takes discipline I don't think everyone has. I've seen some lean in and keep their heads just fine. I've seen others lean in and become disillusioned.
Worst of all I've seen good engineers lean in and begin thinking uncritically and magically.
Some friction can be painful. It's not always beneficial.
Yes and no.
Let's first settle on the definition of vibecoding so that we're not miscommunicating over definitions. I'm using the one that seems the median definition nowadays: >95% of the code written by LLMs, <60% of the output code human-reviewed, meaning there's a large part of the codebase that no human ever reviews.
As you said it's about time invested in thinking about it, yes. But remember that even pre-AI >90% of software got never used, it was dead on arrival. Look up "success rate of software projects in business".
You can put lots of time into thinking and vibecode everything. You can put very little time into thinking and write by hand. Of course, vibecoding makes the former much more likely. But nothing about it is inherent to it.
I hate to be the guy arguing semantics, but is that the median definition? Everyone I know defines vibe coding as ignoring the actual output code completely and evaluating the result by how it behaves under test. Non-coders vibe code by default, because they don't understand how to read the code in the first place. Developers vibe code when they just trust the LLM to have been right about the behavior they don't explicitly test for. Vibe coding is the act of ignoring most possible friction, for better or worse.
It is. There are many people on here who think of having any LLM generated, never-human-reviewed code in the codebase, as vibecoding. There are also people like you, who believe it's about completely ignoring it, and even human-reviewing 10% of the code means it's not vibecoding. The median definition, at least on here, is somewhere in the middle, around "a large portion of the code is never looked at by a human".
Fuben-Eki! https://news.ycombinator.com/item?id=37169679
thanks for that link, I've thought that friction was helpful but this gives me a word and a concept to look at.
Happy to learn about the concept today. It resonates with me.
I sometimes think of something Kant wrote, about how friction (hardship, etc.) elevates us.
In Kant's own words:
"Without those in themselves unamiable characteristics of unsociability from whence opposition springs-characteristics each man must find in his own selfish pretensions-all talents would remain hidden, unborn in an Arcadian shepherd’s life, with all its concord, contentment, and mutual affection. Men, good-natured as the sheep they herd, would hardly reach a higher worth than their beasts; they would not fill the empty place in creation by achieving their end, which is rational nature. Thanks be to Nature, then, for the incompatibility, for heartless competitive vanity, for the insatiable desire to possess and to rule! Without them, all the excellent natural capacities of humanity would forever sleep, undeveloped. Man wishes concord; but Nature knows better what is good for the race; she wills discord. He wishes to live comfortably and pleasantly; Nature wills that he should be plunged from sloth and passive contentment into labor and trouble, in order that he may find means of extricating himself from them. The natural urges to this, the sources of unsociableness and mutual opposition from which so many evils arise, drive men to new exertions of their forces and thus to the manifold development of their capacities. They thereby perhaps show the ordering of a wise Creator and not the hand of an evil spirit, who bungled in his great work or spoiled it out of envy."
See the section titled "FOURTH THESIS" at the following link if interested.
https://en.wikisource.org/wiki/Idea_for_a_Universal_History_...
Alternatively, you can easily add the bloat, discover if it has real value, and then strip it without the bad feeling of having sunk countless hours creating it. Vibe coding is excellent for making the first prototype to throw away.
I agree with this wholeheartedly, it's harder to notice this in a field you are a professional in, but what really opened my eyes was noticing how often friction kept me from making mistakes in hobbyist metalworking/woodworking projects. More than once I've either made or didn't make mistakes based entirely on if the tool I "needed" for the next step was in arms reach or a walk across the garage and a search through multiple toolboxes.
I feel this too but it's very hard to argue myself out of adding features like mad. Features, features, features. Tech debt may be an illusion, if the LLM can keep maintaining it all.
features with theoretical use incur cost up front and yield no value. tech debt is only part of the cost, the other is opportunity cost of writing the OPTION. There’s really no good reason to create theoretical use features.
Thinking of software from finance and derivatives pov really blew my mind. here’s the article, it has AI smell but it’s short and the mental model is good: https://newsletter.kentbeck.com/p/the-cost-yagni-was-never-a...
it’s a breakthrough for me because i too like to build so it’s hard to not build. With options, i don’t get to build blindly but there’s still satisfaction in holding the option. collect the options, system design them, build on that layer.
That analogy works for app code, it doesn't work for technologies, library, frameworks, algorithms. Why build a compiler for this app? YAGNI! makes no sense.
I think you're right, and I think this principle of friction-is-good-actually applies to a lot more domains than just software, but whether the world will ever accept that is a different question.
I know of some financial analysts who don’t like to pull data in from reports automatically. They prefer to read each row and copy it into their spreadsheet because they actually contemplate what the number means.
Same with taking notes by hand compared to writing on a keyboard, and the effect it has on memory retention is well researched.
It's a flavour of Jevons paradox. Make production of software much more efficient (requiring fewer developer-hours), then you might get:
1. Same services provided using similar software stack, but maintained by fewer developers. I suspect this may hold for some sectors in the economy. Or
2. The Jevons case: similar # of developers maintaining a much bigger software stack that provides more services.
I might add:
2a: Similar but with lots of accidental complexity everywhere.
Probably we're heading towards some mix of the above? Depending on which application area you're talking about. Web dev is a lost cause, deeply-embedded won't see a big shake-up.
I also think it's universal. When talking about this IRL I always say:
"If one teenager works hard and saves for a few years to buy themselves a car and another has theirs bought for them on a whim, who would appreciate their car more?"
Odds are it's the former, not always. But mostly.
Ugh. Most of this thread can be resolved by realizing that Teriyaki Bomb is using the word "friction" as a synonym for "constraints" and not "toil".
> I don’t care about your Show HN unless you have spent a month on it.
100%, you actually stated it correctly. It's not "I don't care unless you've written/reviewed everything by hand". If someone writes something by hand in an hour, including ideation, and puts it on Show HN, realistically it's almost certainly not going to be worth even looking at.
I've been running an app in prod for more than a year now, mostly vibecoded long before HN believed it was possible - HN only started believing this around Jan this year at the earliest. But nobody who uses it cares, or even notices, because it took a month to build. That's what matters, the amount of time and thought put into it. Of course it's true that vibecoded projects have a much lower median amount of time and thought put into it. But that's like Louisiana having a much lower median income than California, it's just a median, not an inherent characteristic of being a Louisianan vs a Californian, there are plenty of poorer Californians and richer Louisianans.
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.
Writing is thinking. If you don't spend time writing, then you didn't spend time thinking. LLMs don't think. Consequently, if you outsourced your writing to an LLM the resulting artifact was born of a thoughtless process. Instead of engaging your readers in your thought process you're tricking them with a puzzle. Readers will try to understand what you're thinking about (at least the non-passive ones will). This activity is a dead end for LLM output.
It's not that writing _is_ thinking, but (effective) writing _requires_ thinking. It forces you to take a collection of lose and incoherent thoughts and reify them into an argument that can hold its own weight.
The art of essay writing allows an author to ascertain how well they understand a topic and work out the flaws just by trying to put it into words. Paul Graham speaks about this.
Is writing thinking? Good writing requires thinking but does that also go for sloppy writing? What is thinking? This is the subject of a discussion [1, 2] I'm in - which in true HN style has been greyed-out because of ${reasons} - regarding the question whether these models 'think'. Your comment on writing [being] thinking supports the idea that what these models do is a form of thinking: selecting the next most likely descriptor given the current problem space including all previously added descriptors.
[1] https://news.ycombinator.com/item?id=48884193
[2] https://news.ycombinator.com/item?id=48890755
writing is a form of thinking, but there are others
Yeah -- if it wasn't worth your time to write the post, why do I think it should be worth my time to read it?
Fabulous use of meta-irony, bravo.
Reading the output of a LLM prompt someone else wrote isn't useful as I can run the prompt myself. Having the prompt is actually more useful because I can run it in any LLM I want.
Look at Mr infinite tokens over here.
> 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.
That's not it at all.
The problem with AI slop is that in general it's not worth reading, because to start off even the author deemed the topic wasn't even worth writing to begin with.
Worst, most AI slop blog spam was obviously not even reviewed by the bloggers who prompted them into existence. This means is also content that even the bloggers themselves felt wasn't worth reading at all.
But somehow they expect us to invest our time reading AI slop?
Think how much LinkedIn slop wasn’t worth reading BEFORE AI; but at least some effort had to be put in. Now none is needed.
Or rather because they are always just of poor quality
If you had a time machine and you could republish a claude generated article about some interesting tech topic to 2010 I'm sure it would get ok engagement.
To me the issue is that everything becomes written in the same style pattern. I don't know why but if I spot it I wince internally and immediately skim the post or just outright stop reading. A large part of it is overexposure. For me it's made browsing the internet quite uncomfortable since it's unavoidable.
I mainly spend my online time in group chats these days.
> ok engagement
That is such a miserably low bar
Define “quality”
(I’m pretty sure both you and I would “know it when we see it”, but…)
There was an entire book about that 50 years ago, and last month someone brought that thinking and analysis to the LLM-bot issue:
EDIT: this is the one I was thinking of...
https://sinclairtarget.com/blog/2026/06/01/quality-in-the-ag...
But this is relevant too...
https://bersas.substack.com/p/zen-and-the-dance-of-generativ...
[flagged]
Then why don't you just eat soylent and drink tap water while using only your imagination? The medium is also part of the message.
heh you know a person with "carbon chauvinist" in their vocabularies already does just eat soylent
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 should I care about what's written here", it's however NOT that the quality is inherently poor (but perhaps one my insinuate that notion).
> 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.
> You can't unilaterally say all AI blogs are low quality. That's bullshit.
Quality is a bit nuanced but that quality of AI generated content is subpar to expert output is fairly established.
The implications of this ever becoming false amounts to GAI.
AGI*
> You can't unilaterally say all AI blogs are low quality. That's bullshit.
Can you point us to a single blog (or even blog post) that is generated by AI that is excellent quality? Or even average quality?
> You can't unilaterally say all AI blogs are low quality. That's bullshit.
Watch me.
I absolutely can and do. And pictures, and videos, and picture posts, and comics, and all image-format content.
If it wasn't worth creating with someone's brain, it is never ever worth my time to consume the prompt output.
Send me the prompt. I might look, if I'm bored.
>Ideas have always been cheap. Now, proof of concepts have become as cheap. I don’t care about your Show HN unless you have spent a month on it.
Yes. I'm as pro-AI coding as people come, but this is the part that bugs me too. If you whip something useful up in a weekend, great!
But you don't have to present it like you are building an actual product. It's fine if no one else knows about it. Because the fact is, most people don't care, even before AI. Building for yourself is fine.
building for yourself (or a few people) is amazing! and AI coding really makes this tractable.
> They get abandoned because they get generated on a whim.
I think it's more than that. These greenfield projects are actually things that, up until the inception of LLMs, they were not worth creating.
With AI code assistants, the cost of developing them is lower, but in the end you still end up with a project that no one bothered to create.
It's very strange to vibe code a project and feel both a lack of emotional investment but also the cognitive overhead of steering an AI.
The process of iteration, or the feedback loop, typically allows space to try things out and experiment and then either drop an idea or refine it more purposefully. And those breaks in between the pure delivery to focus on that gives you room to breathe and also see the progress of your work.
Blatting it out in 6 hours with Fable 5 skips all of that and you have something like an MVP, but you haven't really put anything of yourself into it. So why bother committing unless you can take that further or apply something novel or reflect your own personality in it? Or you genuinely believe you're on to something and the AI approach actually gave you a path to building it?
I've been 'vibe coding' something, I've spent about a month on it on and off along with a fair bit of debugging on some sticky issues. I still think I'd suffer going into that codebase and doing stuff in it by hand, no matter how well I thought I organised it all.
>Ideas have always been cheap. Now, proof of concepts have become as cheap. I don’t care about your Show HN unless you have spent a month on it.
I dunno, this idea guy seems to have some really great ideas, what's wrong with you skeptical programmers who aren't on board implementing his ideas for equity?
https://www.youtube.com/watch?v=DkGMY63FF3Q
Great point. It is simply lame impatient clout-chasing when someone goes out and promotes their project that is approximately as new to them as it is to the people they're promoting it to.
Maybe those ideas aren’t so brilliant.
I wonder how much they spend on this rewrite, in tokens and $ using commercial pricing
I wonder how much it costs them in the long run; the initial number mentioned seemed cheap enough (equivalent to 1-2 developers for a year - and I don't believe 1-2 developers could rewrite it in a year, for various reasons), but if it's a 1:1 "transpilation" to unsafe Rust... was it worth it? Will it be worth it in the long run?
But this is the longer running discourse about AI code's cost / benefit. I keep nagging my work's AI community to show me the numbers, so far nobody has been able to show an increase in productivity, quality, customer satisfaction, or company profits.
it said in the original article on the bun rewrite ~165K.
For that money they could hire engineers to do it without having so many unsafe blocks.
The only gain is speed.
I saw an estimate of around 160k $ somewhere in HN comments about the rewrite.
Not heard sunk cost fallacy described as a feature before. Interesting idea.
Keep in mind logic bug that ai makes are extremely hard and expensive to fix as the clanker needs to parse thousand and thousands of lines of text every prompt while a human tries to explain what it's obviously doing wrong.
I hate ai so much because its so easy to generate quick slop that "appears" functional.
[dead]
> 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 because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
Just search "segfault" on the Zig issue tracker and you'll see why people are starting to be skeptical of the future utility of such a language in the face of something like Rust.
> Just search "segfault" on the Zig issue tracker and you'll see why people are starting to be skeptical of the future utility of such a language in the face of something like Rust.
Zig has 110 open "segfault" issues [1] versus Rust's 175 open "segfault" issues [2]. So, by your logic, Rust is also bad.
edit: I was just trying to point out that the parent's "just search segfault" argument is lazy. Also, Zig is still in beta.
[1] https://codeberg.org/ziglang/zig/issues?state=open&type=all&...
[2] https://github.com/rust-lang/rust/issues?q=is%3Aissue%20stat...
You're not seriously out here posting raw numbers without considering the base rate are you
I think the open to close ratio needs to be provided in any such comparison. It would arguably give a better indication of which project is doing a better job at addressing incoming user issues and bug fixes.
You're not seriously posting about base rates without any form of agreeable evidence around such base rates?
Yeah, well, my not-yet-written language has zero segfault issues raised, so it’s clearly superior to both Zig and Rust. I really need to get around to writing it because obviously it’s a much better design.
It's a bad metric, but also Zig didn't migrate all of their issues from GitHub. Run the same count on GitHub and you'll see the full picture
To make a better comparison, you have to add up Zig's issues on GitHub that weren't brought over and abandoned.
That would be Zig's 700 or so Codeberg issues + the 2,700 or so GitHub issues.
Without base rate you're comparing #X in a city vs #Y in a continent and drawing conclusions from that.
It's not even wrong.
You’re literally agreeing that the parent’s argument is bad. I was just applying his logic, and I didn't draw any conclusions.
No. I just think you're taking judge by number of segfaults out of context. That said, I wrote this before the edit.
I program C for my day-job.
I see Rust encroaching in proposed transitions. It may even happen. That said, it is a poor match for it compared to something like Zig (or Odin). It's hard to make the new Rust code use existing allocator abstractions (so now you have two systems doling out memory, how do you reliably free composite objects with memory from both? How do they share?) and you increasingly have to either abandon any actual benefits of the borrow-checker, or invest increasingly heavily into sufficiently fat bindings to wrap your existing C/C++ in a way where the borrow-checker can assist you. That's before we consider the complexity of the language - I'd doubt a seasoned C programmer has much trouble deciphering Zig or Odin FFI bindings, but in the case of Rust? Yes, there is real friction.
Also if you really value predictable- and higher performance, being in more in control of memory allocations and cleanup is preferable. This is the direction both Zig and Odin cater to.
If you asked me what solves the most issues without adding too many new liabilities, I'd say Zig (or Odin). It would simply be much, much easier to transition a C codebase to either, and either would bring a much improved stdlib with pluggable allocators capable of leak-detection etc.
If you literally want one and only one allocator instead of the Rust's built-in one, that's been supported for years[1]. Almost 8 years, to be precise. It's very easy to implement and works with the entire standard library and all its abstractions, and almost every 3rd party library will support it out of the box too (except the ones that go out of their way not to support it for some reason). Borrow checking and all the other safety features are still fully supported.
Now, mixing different allocators is a different beast, and much less supported. But it sounds like you are very much not interested in this use case, right?
[1] https://doc.rust-lang.org/std/alloc/index.html
C++ programmer here. I've looked at transitioning some of my code to Rust; not particularly out of a dissatisfaction with C++ but more just out of curiosity. I've always ended up deciding against it though, I feel like its safety features just come at too high of a price for the kind of work I do. If I was writing something that needs to be super secure like a web server or something I think it would make a lot of sense, but for most of the things I do memory corruption is relatively easy to avoid with good patterns and a crash just kills a local application. YMMV but I think the "safety" of Rust gets a little overhyped.. most the bugs I run into are not memory safety bugs.
The safety aspects do get very hyped. It's better to consider the language strict about correctness; memory safety falls out of that, but so does other stuff, like less logic bugs.
Thing is, this is from someone that likes Rust, but for various reasons has to reach out to C++ when going outside my daily use of managed languages, while C++ will never be as safer as Rust, there are many tools to get us half way there.
The big problem is that many projects keep ignoring those tools, the way Zig sorts out reporting use after free errors, the same solution exists for C and C++ for about 30 years now.
If you allow, I’m curious: If you felt familiar with the language just as much as with C/Zig/Odin, would you prefer Rust for a completely greenfield project that requires no C interop (or none more detailed than say providing a general ABI)?
Sure thing :)
Just my opinion. It really depends. For systems- kind of software (low-level, DBs, file systems (also user-space)) no, I wouldn’t - if you manage memory with arenas and/or can plug in an allocator to tell you if you leaked memory (provided the codepath is triggered), I mostly get what I want with less mental overhead. Also, I very often want to interface with C libraries.
For games, again, I wouldn’t. I again strongly suspect I would and could organize my use of memory better.
I suspect Rust is best when you don’t want to interface with C code (except through bindings others wrote) and you’re maybe more doing applications development where C++ has also stood strong. I completely see how, theoretically, Rust can make a great language for an office suite, browser and so on.
That’s actually also when I tried Rust for a personal project. I wrote a desktop application and while I spoke to C code, I only did so through bindings others had written.
It was/is fine :) I still got a segfault bug though hehe.
Basically I liked Ocaml so I have huge appreciation for all that Rust tries to bring into the mainstream on that front. I am just not thinking that the borrow-checker makes it well placed to interop with C. It becomes much better for relatively isolated applications work.
[flagged]
I like my datacenters like I like my railway infrastructure - covered in enough protective layer of rust that it will never suffer structural damage even when running for years under extremely heavy load.
[dead]
Why do you recommend the living definition of not having any protections whatsoever for protection?
[flagged]
Is it nonsense to say C doesn't have any protections?
Is there a reason you cannot specify your allocator of choice in Rust? AFAIK, the abstraction exists to do just that.
> I think the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
You hit the nail on the head there. Zig is 10 years old now and it’s pretty clear that the industry isn’t biting, compared to the behemoth that is Rust. Between Rust, C, and C++ there is very little room for another language with a woefully incomplete library ecosystem to establish itself.
A true competitor would need to offer genuine extra value, such as dependent types or other formal verification features, to carve out a niche.
There is also the fact of newer "closer to C" alternatives like C3[1] and Zen C[2], or more intriguing C family alternatives such as Odin[3], Jai[4], or Vlang[5].
Zig is kind of trapped. It can't go "head to head" with heavy weights like Rust, who specialize in safety, are more mature (post 1.0), and have lots of corporate support. Then there are the other C alternatives, who each offer something it doesn't have.
It appears the only way for it to maintain its position, is through heavy hype and marketing, but the whole Bun ordeal and extensive beta issues are subtracting from any such attempts.
[1]: https://c3-lang.org/
[2]: https://github.com/zenc-lang/zenc
[3]: https://learnxinyminutes.com/odin
[4]: https://www.youtube.com/watch?v=IdpD5QIVOKQ
[5]: https://codefreelance.net/apps/vlang.html
The industry isn't biting @ Zig because it's unstable, notoriously difficult to integrate new changes into an existing codebase and because the compiler is a bitch to develop with (hard error on unused variables with no way to turn it off).
Not sure that last one rings true. There are entire languages with no allowed unused variables (some without prepending a _ to the names) that people love to develop with.
In the industry, how often is it that a tool/language is picked up for the ease of developing that tool, vs ease of using that tool?
Go has that same problem/feature
Yes, sadly.
> it’s pretty clear that the industry isn’t biting
Zig isn't finished yet (they still have not released a v1.0). They're still iterating on the language itself and want the flexibility to make backwards-incompatible changes while they do so.
So in a sense, they have not yet asked anybody in mainstream industry to "bite." After v1.0, when there's an understanding of stability and ongoing language support, industry adoption or lack thereof might become a relevant metric for measuring the project's health. But right now that's not relevant at all.
I hear you, but Zig is also 10 years old now. While the authors may not want to signal they're ready, people make assumptions based on age regardless.
Either users think (a) it's actually ready after a decade, since many langs/libs are conservative with jumping to v1.0, or (b) they'll think it's [a toy/a side project/run by perfectionists] that's not ready for production, and might never be.
This isn't exactly fair for those who want to just take tir
> A true competitor would need to offer genuine extra value, such as dependent types or other formal verification features, to carve out a niche.
believe it or not it is generally easy to do this with zig with few modifications (WIP), and the team has said publically that they will be making this sort of thing a supported operation once the IR stabilizes post-1.0.
https://github.com/ityonemo/clr/
This is just a dumb take, hardly any language is immediately popular. Python, Ruby, etc. were still pretty niche 10 years in. Pretty much every popular language is 15+ years old.
Python was invented two years before Java and didn’t move the needle until the mid 2010s.
You are the typical mark for hype cycles. Get a clue will you.
Python was being used as a teaching language at flagship universities in the mid 2000s.
Amazing! So was Scheme.
[dead]
I was getting paid doing django in 2005-2006
> Python ... didn’t move the needle until the mid 2010s.
Nope. I was on a Python project in 2006 and earned a paycheck doing so.
> I think the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C for any serious use
I promise you, hand on heart, that literally no one on the Zig core team is wasting their time on thoughts like this.
> and their flagship project has now abandoned it.
Quoting Andrew:
> So, when the Anthropic aquisition finally happened, we at ZSF breathed a sigh of relief. When the donation silently stopped, our bank account was ready for it. When they neither canceled their monthly meeting with us, nor showed up, we were not surprised. The relationship was over.
I advise you to take this paragraph at face value. Again, I promise you that it is the truth.
> 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.
> Removing #define alone would have been worth it.
If you reach out to any project manager and pitch the idea to rewrite a whole app from scratch because you want to get rid of #define, first you will be laught out of the room and second they will reach out to HR to get a PIP going because whatever the hiring bar they used to hire a developer you clearly are not meeting it.
nice strawman. we're obviously talking about greenfield developmen, and then, probably not in corposlop environments.
I would say the flagship Zig project is TigerBeetle, not Bun.
If TigerBeetle is the Zig flagship then Zig is untenable for almost any team, because Tiger Style is untenable for almost any team. No, I think that Tiger Style makes Zig mostly unimportant.
On the other hand, as a corporate backer for Zig, TigerBeetle is definitely a big deal.
But in terms of exemplary and imitable projects in the ecosystem I would think something like Ghostty is the safer label for "flagship".
[dead]
TigerBeetle has a unique static memory allocation strategy at launch time. It’s a strategy that sidesteps a lot of memory management issues but only works for very specific use cases.
Their success with this strategy isn’t portable to most other projects. I think they really need more traditional flagship projects that generalize to typical memory management use cases. The way the conversation keeps coming back to TigerBeetle as a success story isn’t helpful to anyone trying to evaluate the memory management angle.
I would say the exact opposite, actually - Zig is a language specifically suited for TigerBeetle's all-at-once approach to memory management, and the approach more commonly used in Rust (allocate wherever and whenever) is non-idiomatic in Zig.
> only works for very specific use cases.
It's not clear to me what you mean by this.
> It's not clear to me what you mean by this.
TigerBeetle calculates all the memory it needs at startup. It allocates that much memory once. It does not allocate memory dynamically.
This only works for very specific use cases, like a fixed server size where you know exactly how much memory you want to allocate to a process.
It’s not portable to general purpose computing, where it’s expected that apps aren’t allocating the maximum amount of memory they might use at startup. Their memory usage grows and shrinks as you open and close files or as your documents get longer.
> and the approach more commonly used in Rust (allocate wherever and whenever) is non-idiomatic in Zig
Allocating memory as needed isn’t a Rust-specific idiom. Most programming involves dynamic memory allocation.
I don’t think the Zig developers would go as far as saying Zig isn’t a good fit for dynamic memory allocation. If it was that simple this entire debacle could have been written off as “Bun requires dynamic memory allocation by nature, therefore Zig isn’t a good fit”. That’s not what Andrew Kelley is trying to say though.
It works really well for a ton of use cases (e.g. any data acquisition task, which is mostly what I use C for...)
> This only works for very specific use cases, like a fixed server size where you know exactly how much memory you want to allocate to a process.
So, like, the JVM with its "initial heap size" setting? After reserving that space from the OS on startup, pieces of the space are then handed out by the JVM's internal allocator, where and when needed.
If initial heap size and max heap size are the same, that initial one is the only malloc() call that ever happens. Not as common for desktop software, but a common best practice when deploying JVM applications to servers.
(I think we're perhaps tripping over two different meanings of "allocate" - you can "allocate" in the sense of calling malloc(), and you can "allocate" a piece of that reserved memory to a particular scope/function/object without actually calling malloc.)
> Allocating memory as needed isn’t a Rust-specific idiom.
I never said that.
There isn't such thing as "The JVM", there is a standard with several implementations, which one with their own approach to memory management.
You might be mixing it with the reference implementation for the standard, OpenJDK, and even then, it depends pretty much on which set of configuration parameters are given.
The funny thing is that Rust works perfectly fine with statically preallocated memory. It's not even against its idioms - most code will work with zero changes. In a way, the borrow checker is the perfect tool for this situation, since nothing owns any memory and everything is borrowed from the static allocation.
There's definitely one code change that's needed - you need to override the Allocator being used by standard library containers (or, live without standard library containers) and by any third-party dependencies you have. That feature is not even stable, let alone idiomatic.
Using the allocator interface is only required if you allocate, which in this context you explicitly don't. If you want to use static preallocated memory in Rust, you'd have to use #[no_std] and only have access to the core part of the standard library. On the plus side, this is a very well supported and stable configuration, the core library is still pretty rich, and there's plenty of no_std libraries to choose from in the ecosystem.
I used "most" in the pedantic sense of "just a little bit over 50% if you count individual lines and not whole libraries". Most code doesn't operate on Box, Vec, String etc. directly, and is happy with & and &mut to underlying data. And even when it does, it's usually used for giving static lifetime to data, which is a non-issue here because all your preallocated memory has static lifetime already.
Do they really not have any kind of sub-block dynamic allocator?
Does the program handle character data? It is indeed a rare server app which never handles strings.
some may argue for ghostty but yeah :)
or libghostty
TigerBeetle is hardly a product to drive Zig adoption.
> So they decided to start with just a transliteration and go from there.
Huge problem with this is that typically safe, idiomatic Rust looks nothing like unsafe Rust.
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 embedded niche, aimed at complex multithreaded code that has to combine high performance with not catching on fire because someone fucked up concurrency once again.
But the main issue I had with Rust - that it's frankly a bitch to write, nearing Go levels of awful, only worthwhile if its paradigm is buying you a lot - is diminished if it's an LLM that's doing the bulk of the line to line writing.
And, on the other end, C's warts, footguns and ancient quirks also matter less if you have an LLM plow through it.
So, the niche for Zig does seem to be shrinking. The window for it to establish itself might be genuinely closing now. Which is a shame, because I like the idea of having "better C" a lot. But all of this drama sure isn't helping it gain traction.
> 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.
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.
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.
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.
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:
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.
also, the fact that you can compile to any target from any target
"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.
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.
Yeah, I mean … as a C++ dev I have those same existential “what’s the point” questions about Zig.
AFAIK zig is not trying to be "better C++" (that is Rust), zig is more like "better C". a ergonomic low level lang with very little abstractions. zig explicitly doesn't want to be better C++ or rust
Oh, I get that.
That’s what I’m saying. I hear “Better C” and my initial reaction is “what’s the point”. Like, why would you aim for “Worse C++”?
I mean, compile times. That’s fair.
Even those aren't that bad, when using C++20 modules, coupled with binary libraries.
Granted we "aren't modules" yet, unless being on latest compilers with msbuild/cmake/ninja tooling.
Perhaps theoretically, with good practice, but at my job it’s fucking brutal.
But to your larger point I would much rather work on improving that than let it drive me back to C fetishism.
> 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.
I would go further and say that anyone who doesn't immediately identify this either isn't thinking clearly about this, or is intentionally ignoring it. I have no horse in this race AT ALL and this is _obviously_ the advantage.
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.
This is untrue. You can do a file by file translation by using clone and copy liberally. After you're done, you can incrementally introduce borrowing.
You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did). But either way, you're still stuck with a code base that's going to need extensive refactoring if you want to actually take advantage of rust.
Which is still a step ahead of Zig, which requires an entire rewrite to have the tiniest shred of RAII or borrow checking. What's your point, that if we can't do everything perfectly in one step we can't do it at all?
> Which is still a step ahead of Zig
First off, you seem to be under the impression I'm a rust hater. Noting could be further from the truth. Rust is easily my favorite language at this point, I reach for it for basically everything (except quick scripts). While I do like a lot of zig's philosophy, I think at the end of the day the empirical evidence is overwhelming that manual memory management isn't sufficient.
> What's your point, that if we can't do everything perfectly in one step we can't do it at all?
My point is exactly what I initially said: you typically aren't much closer to a (mostly) safe rust codebase if you've done a line by line port to (partially unsafe) rust than you were to start with. Getting to safe rust is very likely to require substantial refactors either way. This doesn't mean you shouldn't do it (on it's own), but it does mean that the bun team's strategy/assumptions are more questionable than they appear to realize.
> You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did
As in, they did not, which I can prove by using Miri and seeing hundreds of errors.
I didn't say they made a good, safe port. I literally said the opposite ("especially if you're flexible about actually upholding rust's rules"). You can get a line by line port to compile by just wrapping the parts that violate rust's ownership rules in `unsafe`. You won't have fixed the problem, and it won't be memory safe, but you can do it.
Well, only if Clone/Copy is compatible with the semantics of the API. I.e., the called function doesn't need to modify anything. No &mut params (or data members) except perhaps `&mut self` (which would refer to definitions the same file).
That's usually the case for Rust programs because the language encourages it. Are Zig programs like that?
To be fair, you can throw an Arc<Mutex<_>> or Rc<RefCell<_>> at it if you're starting from something that has multiple "mutable borrows", but that adds runtime cost and complexity.
It’s fully possible to have scoped areas of borrow checker influence, which could be introduced after the port.
> clear well-scoped unsafe boundaries
This is not done by blindly porting Zig code 1:1 and calling it a day. You do have to make conscious decisions about code architecture to manage Unsafe code, since you need choose the right invariants for your Safe Rust code to conform inside the module (Note that unsafe pollutes the whole module containing it, not just the code inside the unsafe block!)
No one involved in the port proposed "blindly porting Zig code 1:1 and calling it a day". From the first blog post the creator said:
> We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships.
What the rewrite does is make the unsafe code greppable, which is a necessary first step to eliminating it and one that's actually achievable rather than going straight to idiomatic.
Every successful refractor takes this form of stepwise changes that leave the behavior intact. It just so happens that in this case the first stepwise change was the implementation language.
> 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.
Except the blog post shows that they fixed a hundred or so known issues, patching several memory leaks and making the project viable for Prisma Compute's adoption - which it wasn't before. It's now running in production in two places just fine.
Can you point to an equal number of issue tracker tickets showing novel bugs or regressions in the canary build?
Yes, they have introduced (at least) several times more memory safety issues by violating the rust specific rules. Check how most of their unsafe blocks are unsound and worse, how many are straight up incorrect with a total bs // SAFETY above it, leaving no sensible usage without invoking UB.
We often ensure a project holds water against miri. This one doesn't even pass for clippy.
You realize that what you're describing is inherent complexity in memory management? This is not something that you can dodge by using Zig, it's just part of the domain.
The difference is that in Rust you get strong guarantees for everything that is not inside of unsafe and clearly demarcated areas where things might go wrong. Even if you never eliminate a single unsafe block, the clear demarcation is valuable as an artifact in its own right.
The art of Unsafe Rust is marking the right demarcation with the right set of invariants that Safe code must adhere to inside the module that uses Unsafe. If you do this incorrectly, then even Safe code outside the unsafe block can cause undefined behavior.
Which is why having unsafe code without exactly specified invariants is practically useless: the Bun rewrite code has too many SAFETY comments that are incorrect and misleading, so most of the unsafe demarcations aren't helpful in achieving UB-free code.
There's only one language that's more dangerous than C and that is unsafe Rust. I say that only half-jokingly.
It's true and I write Rust and love it dearly. There is an entire book about working with the unsafe keyword and its aliasing rules: https://doc.rust-lang.org/nomicon/working-with-unsafe.html
Good job falling for the Zig propaganda. I say that half-jokingly.
EDIT: You can't be serious people. Rust unsafe is safer than C, if for nothing else, for knowing which pointers are aliasable.
This isn't propaganda, the Rust compiler's rules when using the unsafe keyword are difficult to uphold, which is why the community wrote Miri.
Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block?
And how does Miri help solve this issue?
> Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block?
By the engineer's wit of course!
> And how does Miri help solve this issue?
By detecting undefined behavior caused by violation these rules
Is there a "Rust compiler's rule" you can point to that's harder than avoiding UB in C or C++ in similar circumstances? They strike me as very similar beasts.
> By the engineer's wit of course!
Seeing how the Rust compiler isn't an LLM, it can't really work on wit.
From the POV of a programmer, how would you implement an unsafe block? What is disabled vs what's enabled?
> By detecting undefined behavior
Say you are tasked with making Miri; how do you detect violations of these rules?
What do you mean?
C is unsafe 100% of the time. Rust is only unsafe in unsafe{} blocks.
This is nonsense. There is quite a subset of C which is perfectly safe and an even larger one which can easily be safe with tooling. You could argue that unsafe keyword is easier to spot than the unsafe features of C, so that makes it somewhat easier to screen for issues. But if you screen for memory safety only, this is problematic anyhow.
There is almost zero reason for a public facing, non-embedded project like Bun to use unsafe anywhere.
You do have to inevitably use unsafe because of FFI (Bun uses existing C++ modules like JavascriptCore for most functionality). Optionally also for performance (at least if you want to win Deno on that front)
> There's so much good stuff in this post.
The post starts off so cynical. I know a few people at anthropic and oai and the simplest explanation also matches my observations that they actually believe what they say. That agents will be doing the bulk of the programming in the not so distant future. They believe they themselves will be out of jobs at that point.
They aren't managing some message and trying to teach the anti AI folks a lesson.
Then they are naive. I've seen this a lot first hand during my PhD. Interpreting results in a way that reinforces their beliefs and ignores alternate hypotheses.
Frequently, those alternative hypotheses are demonstrated to be true. For example, "emergence" as was researched and proclaimed by many labs, including places like OpenAI and Anthropic is due to using too few discrete steps in sampling a continuous phenomenon. See "Are Emergent Abilities of Large Language Models a Mirage?" [1] for example.
[1]: https://arxiv.org/abs/2304.15004
The number of people who think the emergence thing is settled smh... It's been a thing for at least 30yr, answering it one way or the other would be a big deal. It does nobody any favors having these infinitely capitalized hype firms calling themselves "labs".
Sadly, like intelligence and reasoning, I think emergence is a word that people discuss while having different understandings of what the word means.
In the paper I linked, they talk of a particular take on the word that is commonly discussed in the ML research: between one discrete step and the next a phenomenon came into existence without existing before (i.e. it occurred spontaneously). The paper then goes on to refute specific claims. That's all I'm pointing out (I could point out similar issues with research into reasoning).
I think it's difficult to pin down "emergence" in the general sense as it likely goes into a deep philosophical argument like consciousness, so I'm unwilling to state whether or not some notion of "emergence" actually takes place. In that sense I agree with you.
> I know a few people at anthropic and oai
> They aren't managing some message and trying to teach the anti AI folks a lesson.
Unless you know the senior execs in charge of marketing at these companies I don't know how you can make that assertion. I believe that a lot of the folks at these companies earnestly believe in the work they are doing. But a belief held by software engineers is not automatically shared by the marketing department, nor by senior execs.
"Anthropic is a giant company with a lot at stake and will seek to capitalize on any marketing opportunity" doesn't strike me as cynical so much as a statement of fact.
> They believe they themselves will be out of jobs at that point.
now THAT is cynical
I'm sure that Jehovah's Witnesses believe what they say. But thats not a reason to let them in my house.
But it’s really the same old problem we’ve seen for decades. Developers write code. Owners declare victory. Owners rid themselves of expensive opex. Owners sell the division or try to keep the project limping along but all they see is vaguaries from the new cheap guy who they keep telling isn’t good enough for a raise, company hemorrhages money and eventually sells for a song.
They’ve just found a way to explore that logical fallacy even faster.
Owners and developers. I've been thinking about this a lot lately. Years ago, maybe in the late 2000s, when startups were becoming culturally significant, and "Tech" became an "Industry", two books were written and published: Founders at Work by Livingston, and Coders at Work by Seibel. I read both, and recall the Founders-book being a bit of a slog -- I only read it once[0]. The Coders-book, I have been re-reading it for more than a decade. I am sure there are many people who would express the _opposite_ sentiment.
The existence of _two_ books, published by the same publisher, within a few years of each other, is a kind of tacit acknowledgement, that there are two categories of people (Owners/Founders and Developers/Coders), that have a kind of symbiotic relationship with each other. That relationship has always been a relationship of convenience and gain, not resonance and understanding and appreciation.
It is, in a way, similar to globalization: nations will support it, only to the extent that it can make them (or their elites) wealthier, and not because they actually care about peace, or the magnificent diversity of human culture and creativity.
Just as the globalized economy is fraying, so is the symbiotic relationship between Founders and Coders. I think it started with the pandemic, which caused (without pointing any fingers) a tension between Founders and Coders, and has been accelerated by LLMs. In some sense, the tactics that were use by Tech companies to wow and win customers outside of Tech, are now being used by Tech companies on other Tech companies. And those tactics involve making grand promises to people who have knowledge-gaps, and are otherwise easily impressed.
I did not realize that there even was a symbiotic relationship, until I analyzed US degree-completion-rates for 1970 to 2011[1][2]. I suppose it should have been obvious, but these things are difficult to perceive from the inside (even if you've been working in the industry for an entire decade). The big problem is that the symbiosis is asymmetrical: founders get the money, and pay the coders, and are able to fire and replace coders at will, while coders can do none of this to the founders. This may have been fine, in an era where layoffs were rare, and getting a replacement job was less uncertain. But I suspect that the contest we are going to see in the next few years is: can Founders out-code Coders, or can Coders out-found Founders. Note that the Viaweb story (the archetypal startup-story for HN), is a story of Coders out-founding Founders (the equivalent of the late 90s era, did not found companies so much as administer small parts of them).
[0]: This is not a criticism of the author/interviewer, nor the interviewees -- the subject matter simply did not intersect enough with my own obsessions and fixations. I wish it did. It feels like I have some kind of color blindness, when it comes to "founder-y" things.
[1]: You can find a (fair warning: long) PDF here: https://galacticbeyond.com/pdf/two-percent-programmer.pdf
[2]: If you do not want to read all of that, here is a TLDR. The percentage of informatics-degree-completions never drops below 2% (which confirms an informal observation Knuth has made many times -- see his 3 or 4 oral histories and his interview in Coders at Work). The percentage of informatics-degree-completions rises and falls with business-degree-completions (the symbiosis is visible here). It never exceeds 4.5%, and such doublings coincide with bubbles (the dot-com bubble, and the 1980s AI-bubble -- there is a history section that helps narrate these numbers). Most intriguingly, informatics-degree-completions are _perfectly inversely correlated_ with healthcare-degree-completions -- their first-derivatives are nearly perfect mirror images. Also, the majority of graduates are business-graduates (accounting, administration, etc -- economics belongs to social-sciences instead of business), and their numbers have doubled since 1970, at the expense of social sciences and education (I suspect that this has had an impact on our (both global and American) culture akin to the impact that climate-change has had on our planet, but I have no data to put behind that suspicion, yet).
That was an excellent thoughtful comment, thanks. I'm going to be thinking about this part particularly:
> I suspect that the contest we are going to see in the next few years is: can Founders out-code Coders, or can Coders out-found Founders.
the rust is merged into main https://github.com/oven-sh/bun
and the rust version has been live in claude code since june 17th.
> 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.
I'm not convinced this explanation is self-evident enough to assert without any justification. I can think of at least one other plausible one, which is that maybe most side projects in general get abandoned after a certain amount of time, and being able to write the code a lot faster means that the point of diminishing returns for personal utility, enrichment, or pleasure are reached a lot faster.
I read a decent chunk of the rewrite.
It’s inaccurate to call it a rewrite. It’s more a transliteration - it matches the original Zig almost exactly but the syntax is different.
And yeah, unsafe blocks anywhere that rust would have complained
So it’s highly likely that the “rewrite” is exactly as reliable as the original.
(It sure feels like this was done for Anthropic marketing reasons, the more I think about it.)
> 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.
> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.
Rel: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
As entertaining as that article was when it came out, I think its apparent wisdom should have been reevaluated for at least the past two decades. Even back when it was written, its pertinence was questionable, since it hinged on the perception that written code has particular value, to justify much of the failures at Netscape and Borland, neglecting many of the other -- probably more relevant -- business and human factors that were at play within the two organizations and their surrounding ecosystems. But lessons learned from watching startups fail in trove in the following two decades have mooted many of Joel's arguments. With the vantage of hindsight, if you read JWZ's account of what went on at Netscape, some of the dysfunctions become glaring.
Making software projects successful has always been about a lot more than just writing code. People have been "rewriting code from scratch" successfully even before LLMs. We just don't tend to call it that. We call it "cloning", "competition", "copy", "alternative-to", "reverse-engineering", "x-written-in-language-y", etc.
It's funny, but I think the article is showing it's age. It's no longer true.
In hindsight having automated auto complete rewriting your code base wasn't something on 2000's radar.
Now switching from language to language is much easier. Just for Rust, there was Ladybird and Bun complete rewrite, that ran into zero things that Joel rallied about.
> It's funny, but I think the article is showing it's age. It's no longer true.
Joel argues 2 effects:
# Developer & time-cost of a rewrite is a big unknown. That's still true, but LLMs may cut that down by a factor of 10x or more. You cut time & developer-hours by throwing tokens ($) at it. An optimist might say this cost has vanished.
# Shipping a rewritten product is -by itself- an unknown risk. That still holds. You can do all the testing you want, but your test suite != your clients environment(s? multiply by number of users or target platforms).
A single bug that pops up in the rewritten codebase (which wasn't in the old one) can hurt a vendor's reputation badly if the stars align just right.
All in all Joel's article held up pretty well (esp. given how long ago it was written).
> Developer & time-cost of a rewrite is a big unknown... An optimist might say this cost has vanished.
I wouldn't say it vanished. I'd say it moved from unknown to known. It's highly likely that for code the size of Bun the price is around 200k dollars of tokens + a month of programmers time to monitor it.
> Shipping a rewritten product is -by itself- an unknown risk. That still holds. You can do all the testing you want, but your test suite != your clients environment(s? multiply by number of users or target platforms).
Fair point.
That said, it seems the number of relevant platforms is shrinking. Both on the hardware side - x86_64 AMD, x86_64 Intel, and aarch64. On the OS side, you have Linux, Mac and the dying Windows.
Still, it seems with enough tests and original source code, you can limit this risk to a few edge cases.
> All in all Joel's article held up pretty well
Aside from the fact that it mostly applies to commercial endeavors[1], it still missed the mark on old code decaying over time.
Turns out being exposed to the Internet has a chance to turn even old code sour.
[1] If you don't care about your users, or you care more about pleasing/attracting new developers, then points made in his article don't make rewriting it that bad.
I think it was always hyperbolic to call rewrites the single greatest mistake (I can think of worse) but I think most of the wisdom still holds. And AI generated rewrites are arguably riskier because now NOBODY is familiar with the massive codebase.
>I don't think Zig community should get triggered on any of this.
As far as I can tell No one from Zig community got triggered by this other than the Zig team. People were angry about Bun switching to Rust not because it is abandoning Zig, but this reckless behaviour of not letting users know up front, no migration path or two parallel version testing and basically trust AI on everything.
The internet was pretty much on Zig's side or at least between Bun and Zig they were Anti-Bun for a lot of things. That was until Zig's reply.
Agreed. That seemed to be the consensus in /r/rust
>Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?
Because most projects are abandoned within months. Why should they be any different in that respect?
> Are Bun users happy with this?
I've gone back to Node.
There was a poll on r/bun with about 2000 votes and only about 30% of users voting they were going to use the Rust version. Can't seem to find it now.
Edit:
The poll was deleted
https://www.reddit.com/r/bun/comments/1u3j4d7/are_you_going_...
Yeah, I was just commenting on a LinkedIn post[0] (don't hate the player, hate the game :) ). In it, someone talked about the difference between creating software and owning it.
Creating software with AI is super easy--plan, prompt, test, go, go, go!
Owning software means you're responsible for maintaining it over time, fixing edge cases, operating it well, and more.
If you're building a one-off custom webapp to meet your needs, create away. If you're writing software for a business to run on, you're owning it. My fav article on this topic is this post[1] on durable vs disposable software.
0: https://www.linkedin.com/feed/update/urn:li:activity:7482123...
1: https://www.honeycomb.io/blog/disposable-code-is-here-to-sta...
I don't think Zig community is triggered, I think only Zig's creator is triggered because he is afraid of people interpreting this as "Zig is unsuitable for X".
I think a lot of people will, but those who do probably weren't the target audience for Zig in the first place?
Context matters. Big announcements and uninformed blog posts can kill your momentum.
I still remember the Twitter dev blog where they abandoned Ruby/Rails and the damage that did. It turned out Twitter was doing a lot of stupid things and there was a mismatch of tools and their goals. They loudly blamed the tools and people ate it up because Twitter was big, visible and adored at the time. Their conclusions bypassed most people’s ability to reason.
Anthropic/Bun are big, visible and adored…
I remember that. It was the first time I heard about Scala.
I saw a lot of RoR companies/users thinking “should we do the same?” without even realizing that they do not have the same twitter scalability problems.
It didn't even end there at Twitter.
The same engineer at Twitter decided early on that no distributed messaging technology was good enough for Twitter, so they wrote their own. It fell over and they threw it away and wrote their own again. It fell over and they threw it away and now they use mainstream tools.
Similar to Discord's migration from Go to Rust. The measurements and reasons they gave were true but even by the time of the migration, Go had already moved on and improved. They were using an old version of Go.
Rust might be the right choice for Discord, I've no idea about that, but the problem is that the blog post lives on and influences people to this day.
I've run into a bunch of segfaults in Bun whenever I went slightly off the beaten path, probably from the "horrifying" Zig code. A huge test suite + a clean rewrite with a path towards more safety is how I would go about it too, personally. Now whether I would do that rewrite in Zig or Rust, I'm not sure. But I have high hopes it's going to work a lot better, especially since Anthropic uses Bun heavily.
Are LLMs better at writing Rust than Zig? I'd assume so, there's way more Rust open source code than Zig. And if so, that's a very solid reason to switch IMO.
I think the mistake people are making currently is that they publicize stuff way too early. I.e. they make a prototype and then put that out there. Possibly with a full product page and all.
People did this also before LLM, but the difference is that now the prototype is a fully functional product in the technical sense whereas before it was little more than a glorified Hello World. The human effort and calendar time used remains roughly the same.
There's gonna be amazing products made with LLM, but it'll take some time. Not as long as it did before, but still significant time.
> There's gonna be amazing products made with LLM
You think more amazing than what was made without LLM?
There is going to be something that would not have existed without LLM because there wouldn't have been enough resources to create it before. Probably already is. Some of it will be amazing, although most of it probably not.
Example: Qobuz has no official Linux client, but there's https://qbz.lol/ which it seems to me is mostly vibecoded. It's not perfect, but it works pretty well and can do some fancy stuff like bit perfect DAC passthrough up to 192kHz/24bit.
I hear you, and those are good applications of LLMs: create something that didn't make economic sense before.
But I'm asking something slightly different. I'm asking about something that's amazing, not due to a different economic calculus, but something that's AMAZING that would not be possible to create by humans.
> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.
No, this is a classic mistake. The value of a project is in the instantaneous utility it provides integrated over time. Some things are valuable because they are throwaway single shots that do a thing that's hard. In the past, making those was too costly for the value, but as software drops to near-zero in marginal cost they're worth doing.
e.g. the costco receipts site involves clicking through to view receipts and only 10 'view receipt' buttons per page. I might have stuck it out in the past, but instead I just described the problem to my claw-like and gave it my user/pass and it found it for me while I was dressing the baby. It wrote some Playwright code and this and that and drove the browser interactively.
That code is throwaway code but it was quite useful.
> To me it reads like Bun was forked. Will the Zig version survive? Will the Rust one? Both? All options ok.
Maintenance of the zig code was abandoned, while the port continued in the same repo, and it's unlikely any work on the zig branch will keep momentum. So yes it forked, but more in the fork+exec sense (or maybe just exec, the analogy's not that great).
According to Andrew, bun-zig is not something some brave soul would be eager to maintain.
> We became increasingly horrified at the programming practices we saw in Bun's codebase. Hacks on top of hacks. Abuse of assertions. Most of all, recklessly speeding past feature after feature with very little time taken for reflection and elimination of bugs and technical debt.
Just "1MLOC JavaScriptCore wrapper" is enough to figure out why.
How many lines of code is Node, which is a wrapper for v8? I'm aware bun is not great quality, I tried and abandoned it myself, but Andrew's consistently bitter and spiteful tone makes him the worst conveyor of his own message.
> How many lines of code is Node
src/ 143k
lib/ 127k
test/ 716k
deps/v8/ 3.6M
I think the line is between AI-generated and AI-assisted - I have AI assisted projects that I have happily been developing for several months and they are going fine, I feel just as engaged with them as I did with my hand coded projects, but also I am more engaged insofar as I actively manage the architecture and the code, and see to it that the AI is following the plan I have in mind.
people chasing after "one shot" code certainly aren't helping, I agree.
This is why IBM still sells so much ancient z/OS mainframe code, things like CICS are the most tested code in existence.
And you can even program for z/OS and Aix with Go and Rust.
https://www.ibm.com/products/open-enterprise-sdk-go-zos
https://www.ibm.com/products/open-sdk-for-rust-aix
This is the kind of industry support Zig is still years away to get, and in the AI age, most likely will never happen.
> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.
It is in the marketing. Most software engineers are not skilled at marketing, do not have a large audience, and are not willing to spend money on advertising. It has nothing to do with code quality.
Its true about the battle test
I wonder if new version of Bun has the same emotional values in Jarred's mind, I mean he did write it by hand and struggled for a long time and invested a lot of energy.
Meanwhile the rust rewrite just magically appeared to replace it.
Which one is more valuable for a person? High Effort or low effort?
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.
> 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".
Another definition: Rust is a lang to "Run fast and low-level software/firmware, with nicer tools, features, and syntax than the other langs which can do this"!
Obviously, the value proposition you find in this case depends on the subjective nature of that regarding rust vs zig!
I don't think I agree with this framing because "definition" implies comprehensiveness in a way that "here are some properties which may not cover everything that's relevant" does not. Your "definition" implicitly ignores the safety mechanism that Rust has and Zig lacks, which does a lot of rhetorical work into making it seem like the only difference is in "flavor" rather than "substance". My argument that there is a meaningful difference in substance, just not the one that the parent comment (and plenty of others) expected.
Semantics on "definition".
"safety" is not why I use and love it. I brought this up because someone who hasn't used Rust, but reads about it may assume it's a "safe" language; I would describe it instead as a nice all-around language.
I don't know if I totally agree with your characterization here either. I'd argue that if you're not actively writing unsafe code, then you are using it as a safe language, in the same way that Python and Java are also safe languages. Yes, I also think it's a quite nice language, but safety is important enough that any time you're comparing a language that can be used safely to one that fundamentally can't enforce safety, framing the choice as purely ergonomic (even implicitly) is misleading.
I think their original post lays out the benefits pretty well. I think the realization of some of these benefits is debatable (for example, they probably could have made their existing Zig code faster), but others are straightforward (like having fewer crashes because more of your code is provably “safe” in Rust terms).
(I think wrapping a large, complex C/C++ codebase is where Rust often shines, if you build the right joiner abstractions. PyO3 is a really great example of that.)
> making sure the JIT doesn't emit anything broken or naughty is completely outside the scope of Rust.
It's also outside the scope of the project if they're using Webkit's engine for that part. Which means Bun itself isn't a JIT, it's all the stuff built around the Webkit JIT, so whether or not Rust is useful for the JIT is entirely immaterial to the question of if Bun would benefit from Rust.
They listed some of the memory bugs they had in the blog post, I just looked at three of them, the first one was this:
> heap-use-after-free crash in node:zlib when calling .reset() on a zlib, Brotli, or Zstd stream while an async .write() is still in progress on the threadpool
https://github.com/spaceraccoon/vulnerability-spoiler-alert/...
If you look at the fix you can see its all in their zig codebase:
https://github.com/oven-sh/bun/commit/621c4016218bb782e05907...
What is kind of funny is that nodejs also had a basically identical bug with an almost identical fix:
https://github.com/spaceraccoon/vulnerability-spoiler-alert/... https://github.com/nodejs/node/commit/53bcd114b10021c4a883b0...
But now the interesting question, how does the code look like in Rust?
https://github.com/oven-sh/bun/blob/8f1a9540fdff25410506de76...
It has the same guard in place as the zig and c++ versions, the rust code also just calls into the zlib bindings after the "write in progress" check.
So in this case at least the same exact use-after-free would've happened and they don't win anything from the rust port.
Another one was this:
> crash and out-of-bounds read in Buffer#copy and Buffer#fill when a valueOf callback detaches or resizes the underlying ArrayBuffer during argument coercion
I think ths is the fix:
https://github.com/oven-sh/bun/commit/79522ab6c579736dc239fa...
But the bug here is in C++ bindings, Rust wouldn't have helped here either.
Last one:
> double-free crash in the CSS parser when background-clip had vendor prefixes and multi-layer backgrounds
Fix: https://github.com/oven-sh/bun/commit/912970c98437e418a95b6b...
Code side-by-side:
Rust: https://github.com/oven-sh/bun/blob/8f1a9540fdff25410506de76...
Zig: https://github.com/oven-sh/bun/blob/912970c98437e418a95b6b5b...
I can't judge the Zig code, perhaps someone could say if this was a "beginner" mistake.
But this is at least one case where Rust would've helped, although even that is a bit complicated considering stuff like bun_ptr:
Which is a bit concerning?I've always viewed unsafe Rust as a sort of last resort you use when you just can't do something safely. Porting something to "unsafe Rust" to me feels pointless, and of course this hasty rewrite was probably not the best idea from any perspective.
If the end state were unsafe Rust, you'd be right, but that's explicitly not the intended end state. Unsafe Rust was the reachable first step. Now they have a Rust version and can iteratively remove `unsafe`, which they couldn't do before when it was in Zig.
It's the wrong abstraction though and I am kind of not surprised the Bun maintainers went way. The correct abstraction would be to translate into Rust while using `clone` and `copy` liberally and then iteratively converting to a borrowing model. Nowhere at all was an introduction of the `unsafe` keyword needed.
That's only the correct abstraction if you intended to hold off on releasing the rewrite until you were completely finished, because there's no universe where Bun of all projects releases a production version that uses clone and copy liberally.
Unsafe in theory in a transliteration is only as unsafe as the original Zig was, which makes it a perfectly reasonable place to land as a transition point in a way that introducing large numbers of allocations simply isn't.
[flagged]
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.
That battle tested bit is so true, always was. It’s hard for engineers to admit their hard work is worthless until they have let other people use and shape it.
Honestly I also think most vibe-coded projects are just.. kind of bad ideas. Which is fine! It's good to be able to determine an idea is bad quickly, there's value in that, but I think people ignore a really important aspect of creativity: the insights you need to have a good idea come from struggling in the muck and struggling in the medium. It's really hard to have good ideas from an ivory tower, you need to get into the details.
> 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 suites).
Not taking a side here in the whole Bun vs. ZSF dispute, but isn't the entire selling point of Rust that you get a bunch of battle-tested guarantees simply from compiling the program? Is there even a metric for battle-tested? I would say something like sqlite is battle tested vs a vibe-coded network server in c, but does that mean rewriting anything in rust truly mean starting all the way back at square one?
Also, didn't Anthropic roll out a version of CC using the Rust rewrite of bun? Surely they didn't just say "works on my machine" and chuck it into production?
> Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?
That which can be created with little effort can be dismissed with little fanfare, since it can easily be recreated later if there's a need.
The other category of AI abandonware is one-off stuff. It did its job and there's no further use for it.
That's such a bad take. You mention some good things they need to do but ignore the part that those are next steps and will take time.
You are acting like they need to complete everything at once...why?
Bun (rust) is not even released as stable yet and getting extensive usage on Claude code. They are making improvements and fixes. So what's the issue here?
> Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?
Because we have a near infinite number of artificial monkeys figuratively typing at a computer keyboard and, once in a while, they spout out something that looks like an acceptable program.
But it's not acceptable: it's sloppy-pasta.
> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.
Yeah. I don't know if we live in the same world as some other HNers: I pay not one but three AI subscriptions: Google (through Google Workspace), Open AI and Anthropic. I'm switching from Claude Code to pi.dev atm.
I'm using LLMs daily. The person next to me too.
LLMs produce shit code. Pure unadulterated shit.
They're extremely useful for many things, including finding bugs. But, to me, they simply suck at fixing them. They write horrible, verbose, code full of bogus assertions and cases that are not handled or not handled correctly.
I do verify the output they produce: the number of time it "works" but I look at the code and see sheer horrors and say stuff like this: "wait, if you replace A by B like you suggest, shouldn't thing X that A makes be done too?". (it's a rethorical question: I know I'm right).
"good catch".
No. It's not a good catch. It's a totally obvious catch that any programmer who's been in this since more a few years (a few decades for me) would catch instantly.
Now if there's one area were they're semi okay'ish is for porting code from one language to another. At least you get a base to start from: if you're lucky. And I suspect it's only looks good if you don't know much about the target language.
Also don't be fooled: we're talking about a company with tens of billions investments that fully knows AI is not enough. You can be sure there are countless programmers fixing, behind the scene, the sheer mess that their AI (with unlimited budget btw) is creating. And then they pretend it's a 100% automated AI rewrite.
AI is not only definitely not enough: it's useful for finding bugs, it's a good rubber duck, but the more and more time passes, the more I'm appalled by the shit code it produces and by the errors they make all the time.
If I wanted to be facetious I'd say that at least we're already --how things moves fast-- long past the point were the kool-aid drinkers explain to us that these thing are intelligent.
It's summer 2026 and, as I type this, the SOTA models all suck at writing code.
Am I still deep into it? Sure am. For basically everything but coding (finding bugs, documentation, translation, generating assets, automating dumb stuff, ...).
Oh well, going back to pi.dev facepalming myself and rolling eyes. I know it's going to be "good".
[flagged]
It's more than just the battle testing. Things that are not wanted by a community or by users are not important. AI delusion memes are fairly reductive but a commonality I see in many overtly ai evangelistic groups is an urge to build without motivation and agreement. The yes we can answer AI gives to user's every question is a failure mode trigger. LLMs are missing the filter an engineer with a human body may give you to an idea...
- Why would we do that?
- This seems pointless.
- This is fucking dumb.
Totally disagree that the value of a project is it's durability. The value of the project is almost entirely disconnected from durability. Value is simply the ability to solve a problem for you. I'll use a bad screwdriver before I use my fingers, even if I prefer good screwdrivers.
Claude Code was a vibe coded experiment, a "what if", that basically consumed software engineering in six months flat. Not because it's durable (it's not), but because the value it provided was so overwhelming.
People will use bad software if the value it provides is high. People will avoid the most durable and battle-tested software ever written if it doesn't actually provide value (solve a problem for them).
I guess the Rust rewrite is the exit path of the Bun's author so that the others could "handle" the code base.
> How is that better than the Zig codebase you started with?
It's not better, it's worse given the average bear's assumption about a rust project.
"How is that better than the Zig codebase you started with?" - It will be worst, as this will not be idiomatic Rust. That's kind of interesting, BTW, as in next iteration LLM will be trained on tones of crappy code, created as some random rewrites, AI slops, etc., I am curious if someone will be able to curate this or it will be the same process of crapification experienced by Google Search that finally lost the battle with SEO spammers.
> How is that better than the Zig codebase you started with?
It's worse, and I say this as an avid Rust fan and programmer. Try Miri with the new Bun project. It's currently blowing up. The Rust compiler's non-unsafe aliasing rules still need to hold during unsafe, which are far more complex than writing correct Zig code. That's the trade-off about Rust: The compiler has a ton of clever proofs for safe code, but if you're on your own, you'll have to do the work yourself.
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, might subject me to this kind of article from their BDFL. I can’t conceive of the leadership of the Python or Rust or any other community I’ve ever worked with doing something like that.
>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 more welcoming community, the remainder will be more concentrated.
> 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.
Not GP, but I don't think a specific other community was being specified. It's more like some hypothetical other community whose primary characteristic is "not Zig".
[flagged]
>What Bun did here is basically a sabotage of Zig's reputation.
No a single soul thought Bun was doing anything against Zig's reputation apart from a few people in Zig. They are the one being over sensitive. When the whole internet was on Zig's side and not a single soul which are normally on Rust came it to support. But somehow it is sabotage of zig?
There is a whole lot of different between being rude and direct to a person on technical issues, such as what Linus used to do on kennel list, and a personal attack that goes beyond the initial point.
And why use a new account?
who let the dogs out?
> ONE angry blog
It's not the first. He recently called GitHub employees "monkeys".
> What Bun did here is basically a sabotage of Zig's reputation
How?
[flagged]
> You know Github sucks, right?
You say that as though it somehow justifies the comment.
Github employees are just that: employees, of one of the biggest companies on Earth. Someone who would call them "monkeys" is telling us that we shouldn't listen to him.
Which is the right conclusion here. Don't use Zig, don't use Bun, neither are mature products from mature teams. Problem solved.
> perpetually offended snowflakes
This attitude is so precious to me - "Sorry guys, you can't criticize my criticism."
> What Bun did here is basically a sabotage of Zig's reputation
If Zig's reputation was so fragile that Bun migrating to Rust caused this kerfuffle, then Bun isn't the issue.
[flagged]
> and I believe it was premeditated
So in other words you're just vibing conspiracy theories and will believe whatever makes you feel better.
The only example of thin skin I see is the character assassination attempts and petty attacks by the Zig team.
[flagged]
There seems to be a team sport mentality with AI topic in HN these days. Almost feels like people are picking sides, and thus not being very thoughtful or rational.
Sigh, there definitely an attitude creeping into the community and it's a huge turn off unfortunately.
Yeah, I think AI could well destroy this community. There’s a lot of personal identity tied up in being a hacker (broadly defined), and only some aspects of that identity will be strengthened by AI.
Similar to Go and Chess, AI might make “programming for beauty” more accessible and popular. However it will almost certainly make the act of writing “code for money” much less valuable, which means many people will stop getting paid exorbitant sums to do what they love.
Personally what I loved was never the typing characters or optimizing algorithms; building is better than ever. But I really empathize with those who loved the craft of code golf, algorithms, literate programming, the elegance of micro structure of programs, etc. and who see their world under threat.
> However it will almost certainly make the act of writing “code for money” much less valuable, which means many people will stop getting paid exorbitant sums to do what they love.
Most programmers are not being paid "exorbitant sums". Maybe if you can put up with working at Meta or something. I hate how VC culture is pretending that paying skilled people a fair wage is some horrible imposition on the poor millionaires and billionaires.
>I really empathize with those who loved the craft of code golf, algorithms, literate programming, the elegance of micro structure of programs, etc. and who see their world under threat.
I love all of those things but don't feel threatened by AI. I do weird microcontroller things, I have dweets on https://beta.dwitter.net I have a website for making animations using 50 characters of a custom stack expression code. Algorithms, code golf, asm, inventing instruction sets, working on my own 8 bit cpu design, all that stuff is what I choose to do with my time.
I don't feel like it is in conflict with AI generated code. There's still plenty of uninteresting code that it can do.
I see some people disliking AI because they like solving problems, which I also don't really relate to, because AI presents entirely new classes of problems.
I'm not sure how much of this is just dependent on what kind of person you are, I find it quite amusing to see the ways in which LLMs get the wrong end of the stick and find it fascinating to analyse and counter the things that lead it to go off the rails. Some people seem to have the same experiences but completely different emotional responses.
I have made things with AI that I could not have made without using it, but at the same time AI could absolutely not have produced it without me directing what needed to be done.
I think the animosity to AI is more complex. There's combinations of anger about wealth disparity, a loss of trust, another of Sagan's great demotions, and this weird anticapitalist embracing of a hypercapitalist notion of Intellectual property.
Adding to this is, I suspect a few actors spending money to muddy the waters, from the Russian government, to the discovery institute, to people who just seem to like the sound of their own voice.
Keep responding kindly, respectfully, without assuming you know the internal thoughts of others, and you can influence things in a healthier direction.
> I think the animosity to AI is more complex. There's combinations of anger about wealth disparity, a loss of trust, another of Sagan's great demotions, and this weird anticapitalist embracing of a hypercapitalist notion of Intellectual property.
I think a lot of the animosity is fear. For decades, software engineering/development/programming provided good wages,relative stability, and often satisfyingly challenging work. You saw a lot of people from secure parts of the economy being told to "learn to code," to secure their futures. Now you've got business leaders racing hard to push us into economic obsolescence or precarity (because that's where they want all labor).
It's not some bullshit about "personal identity tied up in being a hacker (broadly defined)" or liking code golf.
I think a lot of the enthusiasm of AI is from people who are too arrogant to read the writing on the wall, and it doesn't help that software engineers were paid so well for so long that many of us forgot we are laborers and confused themselves for billionaires (and adopted billionaire ideology, like libertarianism and opposition to unions).
I was thinking of the Zig community but I agree that there seem to be some tribalism on HN as well.
Possibly the thing that will determine the long term survivability of each will be the respective attitudes of dang compared to Andrew. Putting out flare ups may be a fairly thankless and unending job but it probably is more protective than pouring gasolene over them.
Maybe one day dang will pop and it will all come out in a spectacular rage.
>There seems to be a team sport mentality with AI topic in HN these days. Almost feels like people are picking sides, and thus not being very thoughtful or rational.
If you are financially set for the rest of your life - Pro AI
If you are not financially set for the rest of your life - Anti AI
As someone in the "not set for life" club, I worry a lot about my peers who are blind to the reality of AI progress. You don't have to believe AI is entirely hype to be anti-AI. It can be bad AND real.
We've had this discussion since the first beta of chatgpt was out and you "completely rational" people keep insisting AI is 100% perfect and better than any software developer.
Just because it's better than you doesn't mean it's better than everyone else :)
>and you "completely rational" people keep insisting AI is 100% perfect and better than any software developer.
I don't think I know of a single person who has seriously suggested that.
I think the most optimistic I have heard is that it might be the case that they will be better at some point in the future, with unrealistic timelines suggested,
"These days"? Only if "these days" start in 2022 when LLMs first hit the scene. Everyone recognized in their gut, pretty early on, what they were and what they represented.
I honestly hope that isn’t true. I’ve interacted with some Zig projects (and some people I’d characterize as Zig evangelists, in a positive way), and my experiences with both were very good.
> 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.
my instinct is to step up and defend Andrew: to say that truly, he has strong opinions -- which is to say he _cares_ about doing things right -- but that he's more patient and accommodating than you're judging him to be from this 10,000ft view.
that's kinda weird: you might view this as a personal attack _from_ Andrew against Bun and i might view the reactions as personal attacks _against_ Andrew. viewing it through this lens without our preconceptions ought to make either both parties or neither party look bad, i think? i don't know the solution except to highlight the outsized impact that our individual preconceptions play when judging a situation from 10,000ft away.
I want to be very clear: I don't dislike Andrew (or Jarred). Everything I've seen about him suggests that he's a bright and motivated person, and (like a lot of people, including myself) I suspect he struggles with how is tone is read online versus IRL.
I'm not judging him as a human being. I just think the post does not accomplish his goals, unless his goal really was to write a personal attack.
I think it's weird to say crap like "So and so was a stinky manager" and then be like it's not a personal attack!
I liked Zed Shaw. I liked Ted Unangst. They made solid technical points and they were kinda mean about it. They didn't act like butter wouldn't melt in their mouths at the same time.
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.
It's the "Bun is better in Rust" section which is misleading, where most things could have been done in Zig as well with a comparable amount of work (if we don't count the rewrite itself).
This section can also give the impression that the LLM rewrite itself brought those improvements, which it didn't.
Nor the LLM rewrite nor Rust in itself brought these improvements, extra work did.
The fuzzing thing also does looks bad and nothing was refuted: just by reading the bun post one could think they've been fuzzing for a long time, but it started only a few months before the rewrite, which makes it almost irrelevant: the result never shipped, or only for a short time. The whole thing looks like this: technically correct so hard to criticize because people can tell you "well no, the post doesn't say this!", but deceitful, with important omissions.
https://news.ycombinator.com/item?id=48891496
But even the dates they’re pointing to as evidence of fuzzing in that post pre-date Andrew Kelley’s accusation that they weren’t fuzzing.
When it gets to the point of having to click HN links to other HN posts which link to a reply in a thread on Mastodon which is splitting hairs over dates that are still prior to the accusation, you’ve lost me.
At best it seems like a more accurate outcome would be to update the original blog post with an edit saying that he meant they only started fuzzing recently and acknowledging the PR from 8 months ago?
I am struggling to even understand what are they trying to achieve? Or do they need a dozens of lessons on basic PR. Especially this is coming from VP of community.
As of this moment, even with all the new evidence being provided on Bluesky / mastodon, it doesn't amount to anything.
Kelley's blog post reads as follows:
> The post implies you were diligently fuzzing your Zig code, while during our calls the Bun team told us that they were not fuzzing anything.
That's not compatible with saying that Kelley made the misleading claims. Bun told him they were not fuzzing. If they brought receipts later that indicate they lied, what should we be left to believe?
[flagged]
No where did they show it makes Zig looks bad. And neither did any Reddit, HN, Twitter thread by a large have anyone said anything like that.
I think we can quibble about the Bun post’s factual claims. But I don’t think the post was deceptive or dishonest in its claims. Like most technical writing, it represents a vantage point.
As for ghosting in meetings: sure, that seems bad. I would also be upset if someone did that to me. But you can state that factually without making it into a personal attack. It would even be more convincing.
> Like most technical writing,
I think you've missed the core thesis of the article. That post _wasn't_ technical writing. It was marketing disguised as technical writing.
It’s marketing that is also technical writing. Most companies do this, and IMO we should prefer this over the alternative (which is corporate blogspam).
Compare Cloudflare, the Google Chrome Security blog, etc.
It was way too technical to disqualify it as not being technical writing. Writing can serve multiple purposes.
> I don’t think the post was deceptive or dishonest in its claims
Presenting only one side of argument (only pros, no cons, etc.) is deceptive and dishonest. The fact that they were incredibly focused on build time in Zig and didn't even talk about it as a tradeoff going to Rust is very telling.
Are we talking about the same post? This is the one I’m talking about[1], and I can’t see where it’s claimed that Rust’s build times are better. Apologies if I’m missing it.
(The one reference I found to Rust’s compile times is them talking about how they had to split their Rust rewrite into 100 crates. A plain reading of this is the opposite of what you’re saying: they’re pointing out that Rust’s compile times are slower, but that this wasn’t an overriding negative.)
You don't have to claim that they're better, but making a big fuss about them in Zig - to the point of maintaining a compiler fork - and then not talking about it at all in the Rust doc (where it's apparent to anyone who's used Rust that compilation there is guaranteed to be slower) is dishonest or at least massively hypocritical.
The bun team made no mention of compile times in their post. The author of this post points to other work by bun that was hardly making a big fuss. It was just a Twitter post about parallelizing some things to make builds faster.
Where are they making a big fuss?
I knew that LLMs had caused reading comprehension to tank, but I quite literally already directly answered that question - as did the original article under discussion here.
You haven’t answered it, and I can’t find a fair reading that would lend itself to that interpretation either. You can easily correct me by quoting the part of the Bun post that you find to be “making a big fuss.”
(Surely a relatively bland technical criticism of Zig - one that gets couched with praise - does not count as “a big fuss.”)
> making a big fuss about them in Zig - to the point of maintaining a compiler fork
Literal quote (and again, appeared in the original article as well). Forking the compiler to try to get faster compile times is a significant effort that absolutely counts as raising a fuss.
The word “fuss” doesn’t occur in the original Bun article.
I also don’t think that forking the compiler is a big fuss. Large companies do that all the time, to carry whatever patches they haven’t upstreamed yet (or can’t). It’s really not that big of a deal.
> But you can state that factually without making it into a personal attack. It would even be more convincing.
I 100% agree with this.
I was just saying that you are probably less at risk of triggering people if you don't politely lie about stuff they make. I don't 100% agree with Andrew's response and I think he should apologize or explain more.
> I can’t conceive of the leadership of the Python or Rust or any other community I’ve ever worked with doing something like that.
At least for Rust, part of this is because there is no BDFL, by design. Python has moved away from the BDFL model as well, IIRC. Individual contributors can get mad and write angry personal attacks, but there’s no face of the language like there is with Zig.
Yes, I think this is a good thing about Rust.
(It’s of course a tradeoff, since Rust moves more slowly than I think a lot of people would prefer.)
It might be helpful to read the latest revision of Andrew's post, which may address this concern for you. It received several revisions: https://github.com/andrewrk/andrewkelley.me/commits/master/p...
To me, this addendum makes it worse. Making small edits to a post like this makes it seem like you're doubling down on the original resentful points, especially with all the new justifications like "a trillion dollar company fired the first shot." Should have just deleted the blog post in its entirety imho.
>outstanding relationships with essentially everyone who openly uses Zig and talks about it publicly
Essentially everyone? more blogposts incoming?
>>outstanding relationships with essentially everyone who openly uses Zig and talks about it publicly
> Essentially everyone? more blogposts incoming?
Andrew is explicitly saying the opposite, but you're entitled to your supposition that that is bluster, I suppose.
I don't think the style of multiple revisions to walk back the most problematic parts really helps the case. It very much leaves me with the impression that the original version is the one that the author really meant, with the revisions being just a weak attempt to deflect criticism.
So if you leave a post unchanged, it's proof you meant what you wrote; and if you edit it, it's even stronger proof you meant what you wrote, even if the edits signify some change.
I understand that many interpretations are open in such things, but this kind of logic seems ridiculous.
That's even worse.
> I can’t conceive of the leadership of the Python or Rust or any other community I’ve ever worked with doing something like that.
I'd be prudent to use a clear faux-pas by a BDFL as an argument to push for an alternative, seemingly more consensual, leadership style. I'd also be careful to fall for the apparent lack of overt aggression in the latter type of structures, as a necessarily positive signal. I've seen people in various such communities (including the two cited languages) that have chosen not to interact with their steering committees, because of perceived toxicity.
This can and does happen with any kind of structure and can take many shapes, some of whom are too subtle or passive to even accurately pinpoint, in the way you would for example directly index a BDFL. In The Tyranny of Structurelessness Jo Freeman made the case that the lack of a clear structure in the make up of a movement presents with opportunities for very fuzzy power dynamics and related abuses that are also much more challenging to deal with.
Yeah, I don’t mean to detract from the serious communication issues that other ecosystems have.
(I don’t think committee/unstructured/BDFL communities do better as a rule, it’s more about the culture that’s promulgated by whoever is at the top, regardless of how many of them there are.)
I appreciate having an opinion vs a bunch of safe words saying nothing. Most CEO communication probably isn't even written by them and has a person-less touch.
It's totally fine to get a negative reaction and avoid the project. It's called having human emotions, which is actually healthy. Getting feedback is how you learn and grow as a person.
There’s a difference between having a negative reaction, which is a natural human thing, and talking out of both sides of your mouth. You can also have negative things to say (or just strong opinions) without being indecorous or unkind.
To me it's just highlighting the reality -- Anthropic fired the first shots. I think it's reasonable for people to say, hey, if you're going to trash the reputation of Zig (in a pretend-objective way) then it's entirely fair for people to put in important context that Bun was not written well.
I really struggle to find a plain, non-motivated reading of the Bun's post that could be fairly described as a "trashing." It's a very bland post.
They're suggesting that the bugs are endemic to using Zig and couldn't be prevented by a modified coding style. Then they point out that the well known way to avoid the issue (defer) is "not ergonomic" (really one extra line is that bad?) It seems like a lot of misinformation couched in a reasonable sounding tone, which is par for the course for how these labs operate.
I don’t think the basic idea that Zig is less safe than a language like Rust (and therefore has different classes of “endemic” bugs) is controversial among Zig programmers.
The points they make around explicit defers are a lot more subtle than it being too many lines. Quoting:
> For Zig code, when exactly should we be running the cleanup code? If we're passing the same *T to many different functions, how do we know when it's no longer accessible and can be cleaned up? How does it work when some functions need to continue to reference the memory after the function is called?
I've seen plenty of projects in C with way more complexity and far fewer issues than Bun, and C is definitely less safe than Zig. Memory management strategies are not new things! Professional developers learn to use their tools effectively. After reading the article and the connected context I just get the sense that this is a poorly developed codebase. A bad carpenter blames his tools and all that. I agree with the article that this seems to be about culture. A vibe coded port that explicitly uses unsafe in Rust is not going to be any safer.
I mean look, I'm sorry, but at this point I cannot take the Bun project seriously. If people are bragging about not-bothering-to-read-the-code and practicing atrocious engineering with LLMs, and then they're like "it's the language's fault!". Yeah, no, I don't buy it. Plenty of people can write applications in languages without automatic memory management without endemic use-after-free issues. As vibe coders like to say: skill issue.
I don’t have an opinion about whether Bun is poorly coded or not. I also don’t have an opinions on it being a good project or not.
I do find these kinds of “get good” arguments tiresome, though. Our job as responsible engineers is to develop strong and safe abstractions for the next group of engineers to use. Rust is one such abstraction.
>I think it's reasonable for people to say, hey, if you're going to trash the reputation of Zig (in a pretend-objective way)
what specifically is this referring to? Not aware of any comments from Anthropic on this topic.
Andrew didn't make the hit piece out of nowhere, unprovoked.
Jared, using Anthropic's multi-billion dollar microphone, painted Zig in a bad light with their first (denied) attempt to merge a vibecoded PR to improve Zig's build times.
Then very shortly after that failed attempt, about 11 days later I gather, Jared (again with help from Anthropic's very big microphone) made public the Zig-to-Rust port.
So unless you're planning on getting acquihired by Anthropic _and_ planning on porting away from Rust using their tools very publicly, I think you'll be safe from such pieces.
What exactly is Anthropic's multi-billion dollar microphone here?
[flagged]
It’s a huge stretch to call Bun’s post slander. It’s a relatively bland technical post with an extremely contextual negative opinion about Zig.
I read both posts, and didn’t leave the Bun one with a negative opinion of Zig. But I did leave the response post with that opinion.
Is it true that Jarred and the Bun team at large engaged in "outright fabrication" in professional business discussions? What do you think of that statement made by Andrew?
It was serious enough that Jarred showed up to post receipts with very little commentary, so as not to distract from the receipts. The charge of professional dishonesty is very strong.
Of course you'll buy that because "receipts" were only half the story and posting little commentary gives him an edge.
See: https://hachyderm.io/@kristoff/116898483283387067
There's literally nothing in that post of substance, other than the fact the Zig community is obsessed with trying to "prove him wrong" or some other such nonsense. Jarred's responses have been composed and civil, while the Zig team has been petty and vindictive.
Who knows? I certainly don’t.
I think there were valid technical and professional criticisms in that post. For example, “Oven’s working culture was poor” is an excellent thing to communicate that I otherwise wouldn’t have any sense about.
At the same time, I also think they were essentially wrapped in an insult sandwich: the post starts with personal swipes against Jarred (who, again, I don’t know) and end with an insult to the reader (who is expected to not believe their lying eyes about all the personal attacks they just read).
Yet one is technical and the one you actually got a negative opinion about a programming language supposedly isn't?
I knew it was gonna happen at one point, guess I didn't believe it'd happen so soon, but I still can't believe that nowadays people make choices about what programming language to used based on what semi-celebrity they like the most, and it's all about emotional arguments. What happened and since when is this the way people make technical choices? I feel like I woke up in an alternative universe.
You are reaching quite a bit, and misrepresenting too.
But it's actually as simple as: Jarred's post was mature and didn't throw shade; Andrew's threw quite a bit of it while insisting it did not.
I and many others don't want to be slandered or trash-talked if we moved away from a language we previously chose. That can and has had actual business impact on projects / companies in the past. So naturally, people will judge you if you cannot be mature when responding to an event that made some splash in the ecosystem.
> what semi-celebrity they like the most
The language in question here is maintained by a BDFL, which means that one person has outsized influence on the language, and it's direction.
In this context, I find it reasonable that if someone is ticked off by that BDFL, they might second guess the direction of the language itself. Since the opinions and emotions of that BDFL _will_ end up in the language and it's community.
This is different than some un-associated influencer having an opinion, and using that to choose a language.
> The language in question here is maintained by a BDFL, which means that one person has outsized influence on the language, and it's direction.
Seems like a strange perspective, isn't it expected (and even wanted) that if you have a BDFL, they have the most influence on the language and its direction? That's why they're BDFL, that cannot be outsized, it's perfectly sized for what it's explicitly trying to be, that's the entire point.
> In this context, I find it reasonable that if someone is ticked off by that BDFL, they might second guess the direction of the language itself. Since the opinions and emotions of that BDFL _will_ end up in the language and it's community.
Yeah, I suppose in the new daily reality where we care more about what opinions people hold, rather than what quality, reliability and so on they actually produce, this does make a lot of sense. Personally I never used Linux because of how much I love/despise Torvalds, I've basically never cared about what he thinks, never thought it was important either, as long as Linux continues to work for me.
I didn’t say the other wasn’t technical.
(I also don’t have any opinions about micro-celebrities or whatever else. I don’t know Jarred or Andrew, and I have priors about JavaScript that in any other context would naturally bias me against Bun. But the Zig post’s flaws are, in my opinion, not ignorable.)
> I didn’t say the other wasn’t technical.
What was the technical parts of Zig's post that made you leave with a negative opinion of Zig then? Something doesn't add up here.
The technical content of the Andrew’s post didn’t leave me with a negative opinion. To quote my original comment:
> 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 can’t conceive of the leadership of the Python or Rust or any other community I’ve ever worked with doing something like that.
This is the negative opinion in question.
Yet one is technical and the one you actually got a negative opinion about a programming language supposedly isn't?
Yes, on the one hand here's "Structure and Interpretation of Computer Programs" and on the other hand here's my blog "embedding-shape is a stinky slop beginner shit show"
And yet you got a negative opinion of me from the "embedding-shape is a stinky slop hack beginner shit show" post rather than SICP? I feel like I woke up in an alternative universe!
It's insane that you think there's any moral problem with using a LLM to rewrite a FOSS software project in another programming language, regardless of whether or not Anthropic employees are doing it. This is the kind of thing that every free software license worthy of the name allows and encourages anyone to do for any reason.
I didnt say that there was a moral or legal problem with rewriting FOSS in another language, I said that Anthropic doing so in this instance was a direct act of hostility aimed at chilling critical discourse about their products and marketing narrative, and I’m shocked at how many people (maybe) are rushing to their defense.
BTW the rhetorical device of misrepresenting what someone else says as something much weaker or incorrect and then arguing with that is usually called “strawmanning”. Just thought I’d point that out to you in case you weren’t conscious that this is what you’re doing.
I think it is insane to characterize Anthropic, or Jared Sumner in particular, using Anthropic's LLM to assist with rewriting Bun in Rust as a direct act of hostility aimed at chilling critical discourse about Anthropic's products and marketing narrative. I'm defending Anthropic because I think this is an okay thing for anyone at all to do, and I would defend anyone at all doing it. If any criticism of Anthropic can in principle be chilled by an Anthropic employee using an LLM to rewrite a piece of open-source software in Rust, then that criticism cannot possibly be good.
Slander? Are you serious?
> We wouldn't have gotten this far if not for Zig, and I'll always be grateful. Until very recently, programming language choice was a one-way decision for a project like Bun.
https://bun.com/blog/bun-in-rust
[flagged]
I actually don’t work for the PSF, and have never received any money from the PSF. Thank you for imputing bias into my motives rather than responding to the comment, though.
[flagged]
Yep. If anything, this ought to bias me against Anthropic. But I don’t share my employer’s opinions about everything, as I assume you don’t.
(Edit: I don’t understand the relevant of these links, to be clear. PyPI is a PSF-hosted project, but that’s because PSF is a legal and fiscal umbrella, not because they pay me for my contributions to PyPI. They don’t.)
[flagged]
Someone pays your living, I’m guessing. But I trust that you aren’t unduly motivated by their interests, because you’re a human with your own thoughts and opinions. I ask you kindly to grant me the same presumption.
Nah, I would not comment on things related to my employer's business because that might mean they could sue me for damages or insider trading or all sort of things.
I'm sure the same applies to you.
Everyone is motivated. It seems to me that Anthropic went out fishing for something to blow up. As Ray puts it: "Management eagerly approved the Rust rewrite option because it was a great marketing opportunity to showcase their new Fable model, Anthropic already uses Rust, and Zig is openly against using Anthropic’s products." Sounds spot on.
Others have pointed to some plausible technical benefits from the port, namely that it forces an enumeration of unsafe code boundaries. There's probably something to that, but the big idea is that Anthropic bet that its models could do a big job, and they needed to both demonstrate that and make hay of it. Everything aligned. They did the port. The artisans might call it slop, but it runs, they did it like 2 weeks, and they stuck it to the guy that shuns AI.
If you're the type of manager who picks farming out work to a body shop with 100 unskilled workers instead of hiring 2 legitimate FTEs, then this is speaking your language.
none of this justifies a nasty mean spirited blog post.
I didn't say or imply that it did. I just don't believe that the decision to port bun was based on innate technical merits of zig vs rust. I also don't think that it is entirely meritless, as I mentioned, because now that there's a par rewrite, there is clear delineation of the areas that need to be ported to safe rust. Still, does anyone really think that this would have happened without Anthropic's provocation?
I see it like this: Anthropic saw an opportunity to make a splash. Jarred made it happen without directly disparaging zig, but the implication is that zig couldn't cut it. Andrew made it more personal.
I don't understand how a port is a "provocation." That's a very cynical and transactional way of thinking about open source.
(As for Anthropic's motivation: only they know. But I suspect that they saw Zig's AI policy as a potentially existential risk, and moved to de-risk their position. That is a technical decision, just not one rooted in the merits of any particular language.)
By provocation, I mean what motivated the port. I'm not suggesting that it was "provocative" like with intent to bother the zig team. That's why I ask if anyone thinks that bun would be ported to rust if not for the Anthropic deal. I doubt it, and I think that's why it took everyone by surprise.
Regarding zig becoming a risk: that's a reasonable line of thinking that I hadn't considered. I don't know how likely it is that zig will fail to progress and fall behind as a language compared to others that are assisted with AI, but it's a possibility.
Ah yeah, I agree with you.
I had this exact same reaction. Agreeing with the substance of the critique of approach etc but not at all its tone nor of the underlying elitism that lays there.
This is not how professionals behave in a profession.
Decorum actually matters.
Anthropic is doing bad stuff. They clearly have a broken internal engineering culture. Hence I don't use their products. But I expect to see this laid out in a structured argumentation that doesn't go after people and their personalities.
I stand with Andrew.
As someone who's been following Sumner's work closely for years, Kelley's accusations are very much true even if unkind. While the results are useful and cool, it a wankfluencer op from start to finish. I dare you to refute thus.
And I say all this as someone who does agentic development 8hrs a day and someone who always pestered my team to opt for Rust and Deno instead of Node. Call a spade a spade, the rewrite was poorly justified and one in a long lines of successful psyops Dario and co. cooked and delivered.
Now, would Andrew's message have been better received if it had better "decorum"? Maybe. But I'm glad he stayed honest to himself instead and didn't have a PR team ghostwrite his thoughts. You have to appreciate that.
> But I'm glad he stayed honest to himself instead and didn't have a PR team ghostwrite his thoughts.
If there's one thing I learned in this debacle is "I should spend 1-2 days and send to a close friend before hitting publish on a firey reply." The way Andrew rephrased the closing section is the kind of thing I should publish on the first edit in similar scenarios.
Early on in my career I wrote a highly critical email - I asked a coworker for his opinion before I sent.
He said “there’s just one thing that would improve this” and hit the delete button.
That intervention saved me, and everyone I was working with, from a lot of unnecessary stress.
Venting is great - get it out of your system. Then take a deep breath, go for a walk, and then decide what to do.
Abraham Lincoln used to write angry letters and stow them away, unsigned and unsent [1]. The book "How to Win Friends and Influence People" claims he stopped harshly criticizing people publicly after being challenged to a duel [2] by a government official he had attacked anonymously in the press.
1. https://www.battlefields.org/learn/primary-sources/lincolns-...
2. https://www.battlefields.org/learn/articles/abraham-lincolns...
Unlikely a useful lesson here. If it would have been written as "political correct" version up to the point of not calling Jarred out at all would have missed the core message. The fact that it was written blunt is the reason it went viral.
Viral is not an inherently good thing unless you're an influencer. Not all publicity is good publicity.
uhhh, that's not how the how that figure speech goes. There's a reason why people say all publicity is good publicity, and you can't just flip that to fit your perspective.
People repeat that figure of speech because it's a meme (in the original sense of the word), not because it's unconditionally true.
No, they repeat it because it's literally true.
Let me guess: you know that it's literally true because everyone repeats it, right?
I also don’t really like his closing section, it has a big “sorry but not sorry” feeling to it.
I read that as him beginning the healing stages. Acknowledging his flaws as soon as he could even if he couldn't change what he already said - because that post did blow up, if he had taken the whole thing down it may have just exacerbated things.
I think if the last decade has taught us anything, its that decorum has zero to negative value in public communication. People pay attention to drama, and you need attention to be heard. When the penalty for rudeness is gone, just go for contention.
> penalty for rudeness is gone
I assume Andrew's goal isn't to be a viral influencer but to achieve some type of long term impact or goal. Programmers don't pick languages based on maximal vitriol and if anything do the opposite.
Wankfluencer has now been added to my lexicon. It's a word that feels like it should always have existed, but didn't. So very aptly describes these personas who would pimp their own mother for a t-shirt with a logo on it.
The fact of the matter is, the reason Bun chose to go with Zig in the first place was for clout and clout only. Bun is a textbook case of a wankfluencer operation: unnecessary rewrite of an existing useful project using the latest hot language or ecosystem to get lip-service by influencers and get easy VC buy in.
There's nothing wrong with chasing a little clout really but I was not surprised to hear Bun's engineering itself wasn't up to par. A single person was shipping not just a runtime but half the ecosystem/tooling justified by sketchy benchmarks? As someone very familiar with the effort it takes to ship solid code in Node and Deno and the ecosystem writ large, their early claims of performance and being production ready were very suspect and it was unfortunately proven false once it duped real projects into getting adoption.
Again, there's nothing wrong being overly ambitious and failing. But I dare anyone to refute that in Oven.sh and many other twitter first projects today (usually in the Js ecosystem), solid engineering and actual usefulness takes a backseat to being viral and being featured in some idiot's weekly roundup news segment.
If you're familiar with Kelley's and the Zig Foundation ethos, it's not surprising that there was internal clashes and drama with such a project.
It was poorly justified up-front but frankly I did not need the examples to understand Jarred’s frustration.
What I found helpful were his explanation of how the interaction with JavaScript’s garbage collector created unique challenges for Bun. Andrew did not address this point at all. It was also helpful to understand how the test suite covered the new code - many people had assumed the tests were also vibe translated and couldn’t be trusted. Andrew pretends he didn’t understand that tests don’t catch all bugs, which is true of all software including Zig.
To me this whole exchange is mostly the typical “memory unsafe languages lead to time consuming and disruptive defects that can be almost entirely prevented with a choice of programming languages” versus the “git gud and don’t write bugs” response.
Layer on the AI tension, Anthropic’s involvement and Andrew’s classic Linus impersonation and of course its viral.
>Call a spade a spade, the rewrite was poorly justified
In what world do you think they have to justify a rewrite to anyone outside their company? Bizarre mentality.
They didn't have to but Anthropic chose to open their mouth and announce their "reasons" for the rewrite. Don't blame anyone but Anthropic for this, they didn't have to try to justify it, but they decided to anyway.
Sure that had to justify it, people were writing all sorts of posts about how Bun was no longer trusted since it was rewritten with Rust.
Bun's post was explanation of that process that was (IMHO) pretty reassuring in that the new version of Bun is not 100% garbage.
(Now in the ideal case that post would be released before, or at the same time as, rust-based source code on github... Then there would be much less drama)
Exactly. The people criticizing the rewrite for the most part are just trying to exert power from the wrong end of a parasocial relationship. And then they get upset when no-one takes them seriously.
i appreciate people saying it like it is.
like linus lol
i hate marketing pr speak when it comes to technical things.
save that for the non technical customers
>like linus lol
I am not even sure if that is an insult.
Linus attack on "things" he dislike and call the person out on it. I don't believe Linus has ever call out on that person's other non related behaviour.
People keep using Linus here as if they are the same. They are not.
What is the behaviour that Jarred was called out for that was not related to Bun?
Being a bad manager. That’s a very personal attack.
if he actually was, then it's not a personal attack but stating facts about a person - there's a meaningful difference.
A personal attack has no informational value (about the accused), while bringing to light bad qualities of a person does - especially if those qualities are related to the issue at hand, which in this particular situation seems to be the case.
Again, the distinction between a personal attack and proper characterisation of bad qualities rests on actual facts i.e. was it slander or was he really a bad manager?
I don't know but I personally give less probability to the former than the latter.
Managing a very public project that advertises Zig and doing so poorly is a matter of fact, is it not?
Didn't Linus famously say that he regretted his behavior, that making things personal was not okay, and that he needed to change some of his behavior?
what exactly is technical about personal attacks?
[flagged]
> psyops Dario and co. cooked and delivered
Does that include Claude itself? Half joking aside, my main concern remains that both OpenAI and Anthropic practice this fear mongering as strategy at the executive level because they have to. A corporation is a different beast. Not human, exactly. Not AI either. What happens when a corporation starts being informed by the AI it is building?
If you want a lens into master craft corporate human slung bullshit, read this: https://www.theverge.com/podcast/944138/microsoft-ai-ceo-mus...
In this, not only did the interviewer admit he knew Suleyman had written about the issues he talks about in his rebuttals, he then says he's only asking (the hard question) because the "audience" wants it.
Suleyman's response talks about taking "accountability for the things that we build" and the "types of problems that we choose to work on," it highlights the fundamental flaw in the cloud-rented AI model.
In that ecosystem, "we" means a handful of corporate executives deciding what tools the rest of the world gets to use, how they operate, and what data they extract. All based on the profitability of the corporation. It is the absolute antithesis of a sovereign architecture where execution happens locally and the user dictates the terms of the system.
They are coming for open models. It's time to harden the gates.
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.
> 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
Anthropic absolutely is in the programming language market. If/since AI makes rewrites to certain languages relatively easy, a success story will tie the given language(s) to the given AI company.
Rust may have a tremendous success in the future, because it's much easier to write it with AI (ignoring for a moment whether that's really a good thing). The implication is that Anthropic has a stake in Rust's success.
Also, to be kept in mind that devs advertising successfull rewrites often hide some aspects that are unfavorable to the narrative; typically, how bad was the code before the rewrite), although there are other (significant) aspects that have been omitted.
> Zig's response is a sour opinion piece full of personal attacks.
I take you haven't read Andrew Kelley's article (here: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...).
Summary:
- Jarred has written Bun with very bad engineering standards
- Jarred has managed public relations very poorly (e.g. ghosting the Zig foundation)
- When they rewrote the project to Rust, and described Zig as poor choice, there has been a negative fallout for Zig
- The ZSF is obviously upset because of the poor publicity
This is summarized at the end of the post:
> Zig users who knew next to none of these facts and have only the surface level understanding that an ex-Zig-user is getting trashed by the language creator. Such people might reasonably worry that might happen to them
As a matter of fact, I also believed the same after reading's Bun's post. This is undeserved though, and that's what Kelley explains.
There's definitely a personal attack somewhat, and this is addressed in the last (added later) section.
> I also believed the same after reading's Bun's post.
This doesn't even make any sense. The part that you're quoting[0], is Andrew commenting on the fallout from the blog post he made. How could you have thought something about a blog post that hadn't come out yet?
Also, if you are talkinga bout the post Jarred made, it was extremely charitable about zig: "Zig made Bun possible. I would never have been able to build this much in 1 year if it wasn't for Zig."
[0] "The other critical mistake I made with this post was failing to consider the rather obvious and important point that this might affect Zig users who knew next to none of these facts and have only the surface level understanding that an ex-Zig-user is getting trashed by the language creator."
- When they rewrote the project to Rust, and described Zig as poor choice, there has been a negative fallout for Zig
- The ZSF is obviously upset because of the poor publicity
No where did they describe zig as poor choice, and there were zero evidence ZSF was getting poor publicity.
Had whole of HN, Reddit and Twitter all laughing at Zig this would have make more sense. But that was not the case. As a matter of fact I don't even record a single comment about it. If anything a lot of these "poor publicity" and "Zig as poor choice" were completely fabricated.
Had the internet turned against Zig, the response may have deserve a lot more weight.
I mean, does it even matter?
It's not Bun's or anyone else job to care about Zig's or the ZSF's feelings or publicity.
A project who switches programming languages or frameworks or whatever doesn't need to be afraid of offend anyone.
> I take you haven't read Andrew Kelley's article
Yes, that's the sour opinion piece full of personal attacks.
>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 hate about ornery IT people.
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?
That is an absolutely foolish position to take. Basically, when given proof that agents need improvement you're sticking your fingers in your ears and going "nuh uh, it's not their fault".
> since AI makes rewrites to certain languages relatively easy
This premise makes no sense. AI makes rewrites to any language easy.
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 should worry all of us.
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.
I never said it did.
My comment shouldn't be read as an explanation for why Anthropic chose Rust in this case.
I was simply disputing the claim that LLMs are good at all languages, and that their biases--both intentional and otherwise--will swing the entire industry.
That's not all there is to it, to be fair. Rust seems to work particularly well for LLMs in part because it's better at catching their errors.
IMO there is no reason to believe llms create equal quality code in all languages.
They really don't. Even per-project it can be a shitshow. For instance, while I use LLMs to write some typescript, when I'm writing code for Unreal Engine in C++ & Blueprint I pretty much do it by hand because it absolutely can't do blueprint in any meaningful sense. Even the most basic requests result in an absolute mess. (I imagine it's also very hard to train on since its stored as binary data). Even the C++ code it generates is pretty rough -- regular linker errors etc.
This isn't true. AI couldn't rewrite Firefox in Brainfuck.
easy or good?
Both!
>Jarred has managed public relations very poorly (e.g. ghosting the Zig foundation)
I actually love the use of ghosting in this post. It is almost a Freudian slip about how Zig looks like from the view of outsiders. Zig moves exactly like how toxic exes do. They point fingers, make passive-aggressive statements, unnecessarily air out dirty laundry, and downplay all of the good their partner has done during the relationship.
> Rust may have a tremendous success in the future, because it's much easier to write it with AI (ignoring for a moment whether that's really a good thing).
It’s interesting that Rust could become the most deployed but the least written (by humans) programming language if the dreams of AI bros come true.
If AI gets good enough to competently translate other languages to Rust then there is no point writing in Rust (a language with a steep learning curve and is high friction in use), you can just write in a low friction language like C, C++, Odin, Zig, … etc. and have AI translate it to Rust catching all the memory bugs in the process.
C/C++ is low friction compared to Rust? Wow. We have very different experiences.
If your objective is just to hack something together quickly to test an idea, and doesn't care if the application segfault 6 hours later (eg. a prototype game engine), C++ is definitely the superior choice to Rust.
Rust is like the instructor demanding that you build your house up to the national code, down to the choice of nail for your floor board. Your house will be perfect, but building it is extremely difficult and high-friction. In many cases this is unnecessary.
I can get cross platform rust up and building and running with 5 minutes. It’s probably half a day at least for c++ and a more significant maintenance burden.
Also, I think the “quick to prototype” only is beneficial if you know c++ and don’t know rust. I know both and I can say that Rust is much faster to prototype in precisely because
a) tests are trivial to add meaning it’s trivial to add test coverage vs in c++ you have to integrate gtest and bother to set that up which no one does B) many initial startup bugs are prevented. It’s not segfault after 6 hours but spend hours getting it to work correctly after it compiles vs it runs mostly correctly from the first build.
Even if Rust is slower to write (which is only true if you don’t know Rust and don’t have AI) it’s still overall faster to develop in. I can’t recall if MS or Google have written up their experience on that side or focused only on impact to vulnerabilities.
You can hack things together pretty effectively in rust if you put your mind to it (so many things that bog people down in rust are due to focusing too hard on premature optimization of either performance or correctness), and the easier to use tooling really helps with that kind of thing. I use Rust for small one-off projects frequently just because it's easier to work with.
> doesn't care if the application segfault 6 hours later (eg. a prototype game engine), C++ is definitely the superior choice to Rust.
I wouldn't say "definitely", given Rust deps management is way more streamlined.
> translate it to Rust catching all the memory bugs in the process
That's not possible. If it were, you'd just fix the memory bugs directly in the original language.
Your best bet is to have a translation littered with unsafe blocks, so you still have to do the work of nailing down the specifics to make them safe. There's no magic "unsafe language" -> "safe Rust" pipeline, even with GenAI.
You really think AI can't convert unsafe blocks to safe code?
The reason AI can't fix memory unsafety in the original language is the same reason humans can't do it. There isn't enogh feedback from the compiler.
I imagine it could, eventually, if not now. The Bun translation used Anthropic's best model, cost hundreds of thousands of dollars, and still contained a large number of unsafe blocks. Maybe if they left the agent running for longer, using Miri for verification?
i’d rather have a run time than this way of working.
We've read the andrew blog. It is a personal attack a very petty one, you're clearly a biased fan of his and of zig probably if you cannot see the obvious, but we're telling you as outsiders how poorly it reflects on andrew and the future of zig, and this is coming from someone who originally had a very good opinion of zig and andrew, now not so much. You can choose to ignore that and engage in the massive circlejerk zig fans are engaging in during this or maybe take a second and reconsider
Wow yall really act like grade schoolers arguing about Pokémon cards
[dead]
Yeah, exactly. It's weird that Zig even responded to that. Imagining that your studio switched from Unity to Unreal and Unity proceeded to release a hit piece attacking your codebase quality and workplace environment.
But that hit piece would be an answer to the (multi-billion dollar) studio saying how much better the result is after the rewrite to Unreal, except it's not because Unreal is better (which it could be btw, or not, or more probably it depends on the use case), it's because the studio worked hard to make it look better, which they could have done without the rewrite.
Anthropic does this to sell LLM rewrites and make them look better than they actually are, Zig being the source language, they are a collateral victim of that misleading advertisement. Of course it's unfair to them and of course they should highlight this.
> But that hit piece would be an answer to the (multi-billion dollar) studio saying how much better the result is after the rewrite to Unreal
this in fact happens all the time and engine creators dont come out with bitter blog posts about it
There was an almost exact example of this: City Skyline 2. It's (was) a poorly optimized game and they said Unity's DOTS didn't match their expectation, making Unity look bad, while some issues (like they didn't use LoD where they should have) weren't Unity's fault.
And even in this case, it'd be extremely weird if Unity published a blog post about how City Skyline's studio is a "Just a total shit show, from an employment perspective" (quoting Andrew word by word here).
This is actually is an interesting example, because Cities Skylines 2 has been handed over from Colossal Order to Iceflake Studios recently and since then they have (in my opinion) quickly been able to improve and fix a lot of things that CO weren't able pull off for years. So perhaps CO's development was somewhat of a "total shit show"?
I'm not saying Unity should publish PR about how Unity is working well and this handover and subsequent fixes proves it, but I think you could argue that they could and that they would have at least some facts to back it up with.
>except it's not
Except it is. The people using it told us.
Anthropic is massively bigger than a studio, Zig is massively smaller than Unity, and it wasn’t a quiet switch, it was a huge publicity event. It’s more like the #1 movie of the year being “The Profound Joy of Finally Leaving Unity”. Sometimes things are big enough to warrant a response.
It was a pull request and a blog post which HN et al. collectively foamed at the mouth about. You’re acting like Anthropic sunk millions into a marketing campaign.
The entire country is watching companies like Anthropic, openAi, etc.. right now... A pull request and blog post is a big deal.
[dead]
For what we know, probably around $200,000 to run the rewrite and rewiew it, + whatever was involved in writing the blog post and advertise it.
Anthropic produced the tokens. They don’t have pay themselves retail API rates for them.
The cost was only provided as an honest estimate of what it would have cost someone else at time of writing, which I thought was fair.
The number is peanuts relative to the cost of engineers working on the project. I find it odd that so many people think this cost number is some sort of smoking gun.
At the same time, Anthropic is still running at a loss, so should this actually be 300k? 500k?
Anyway, the exact number doesn't really matter in the context of my comment anyway (which was meant to facetiously note that the marketing campaign includes the Bun rewrite)
Well if the whole thing is a marketing ploy and it did cost them millions...
People were for a few weeks commenting on why Jarred didn't write that Rust blog post.
Here are the comments:
https://news.ycombinator.com/item?id=48251340
https://news.ycombinator.com/item?id=48241734
https://news.ycombinator.com/item?id=48240996
Now he published it; it's a hit piece. Damned if you do, damned if you don't.
It’s not weird considering what we’ve learned through this: the Zig project is driven by people with fragile emotions and egos who lash out at people personally when they feel threatened.
We’d like Zig to be a project with steady and technically driven leadership like Rust, but Kelley has made clear (many times) it’s more of an egoistic vanity project like Elm, designed to cater to the emotional needs of the BDFL.
Calling them egoistic is quite a claim - do you have facts to back that claim with?
Andrew Kelley described Github employees as 'monkeys' and 'losers'.
https://news.ycombinator.com/item?id=46065366
Yes, I’ll cite “the juicy grapevine” and that should be enough given the evidentiary standards people are setting here.
[flagged]
Ehr, they weren’t the ones personally attacking others in a public blog post, were they?
If Unity had 2.5 users anyone had heard of before the switch you can see where the motivation might (at least emotionally) come from.
It's not really this though. It's about the user leaving throwing misleading shade. Politely, of course.
Well, if your game would be one of very few AAA games written in Unity (actually, the only game written in Unity people reasonably familiar with the subject would be able to name off the top of their heads), things might look different...
[flagged]
> I talked to those who interviewed for a job at Oven. I talked to people who worked there. Those people talked to each other. Everybody talked to everybody. The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show, from an employment perspective
Yeah, exact words you would expect from someone who is happy about a win-win situation.
Andrew is bitter (or something related) about this whole situation, that's no question, he writes it in his updated post (he doesn't say "bitter", but he speaks about unprocessed emotions).
People are entitled to their emotions. The question is whether the bitterness is warranted. I think it is.
Yes, people are entitled to their emotions, but the ways they behave in public and express their emotions reflects on them in a major way. The Bun blog post focused on the technical reasons to change, and was complimentary about Zig. The Zig blog post was heavy on personal attacks, with some technical claims that the Bun blog post had mostly addressed already. Between the two, the Bun post is a lot more compelling from technical and professional perspectives.
I'll admit to thinking that the Rust crowd often has a toxic atmosphere, but Zig came off as worse in this exchange.
[flagged]
When accusing someone of "good looking lies", it would help to provide an example or two with an explanation of why you think they're lies (rather than mistakes, oversights or differences of opinion). Complaints that the post "subtly and misleadingly throws shade at Zig" are hard to accept without that kind of support.
> Of course when you are the creator of Zig, that may feel quite unfair and you should highlight it.
Then highlight that, don't repeatedly insult someone. If Andrew thinks the same kind of ai-assisted improvement would be possible in Zig, and that avoiding the kinds of errors migrating to rust achieved would be possible in Zig, he should demonstrate it. And I don't necessarily mean rewriting all of Bun in "better-zig", but like, if you're going to say "this project is bad because it is badly maintained, not because the language has limitations" then demonstrate something to that effect.
The only technical detail I recall from Andrew's post is that zig has faster compile times, which may well be true but what do I care?
Why not? Sharing your experience with working with people is fine, they're subjective opinions. Does this mean it's slander and/or a hit piece? Seemingly a lot of people would say so, personally I don't think people sharing those sort of experience publicly are doing so out of spite, some of us are just still used to the old-internet where you can share stuff like this in public, without getting piled on for not "thinking/writing the right way" or whatever people are complaining about.
> Incredible the different takeaways people get from text content on the internet
It is incredible isn't it.
"Jarred was already writing slop well before he had access to LLMs"
"The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show, from an employment perspective."
"at some point they would sell out (let's be honest, their vague "sell some cloud something" business plan was a farce from the get-go"
"he was essentially groomed from a young age into uncritically embracing the Silicon Valley mindset"
There is more but I'll stop quoting to not end up copying the whole thing.
Well at least he didn't call Jarred a monkey and a loser so Jarred is better off than the Github devs.
> There is more but I'll stop quoting to not end up copying the whole thing.
Yeah, and perhaps also because your point(s) wouldn't make much sense if people ended up reading the whole article, rather than your cherry picks ;)
The article wasn't very long and had little of substance besides these personal attacks. So...no.
nah. I have no horse in this race in fact before this blog I had high regards for andrew and zig, less-so after this blog.
You're accusing me of cherry picking, can you explain how these are cherry picked ? do you even know what cherry picking means ? maybe explain the important context for "Jarred was already writing slop well before he had access to LLMs" that I omitted apparently.
...Unity made a blog post saying they were happy about you moving to Unreal, publishing they think it'd be a win-win, then outlining why they think so
I mean, that makes it all sound very polite and dispassionate, but Andrew's piece was anything but. I have no dog in this fight, I don't use Zig, Rust, Bun or Claude, and initially I thought the bun rewrite sounded like a terrible idea. I changed my mind after reading the piece about the migration - it was very interesting and the process was obviously quite thoughtful. Andrew's piece made me want to take a shower afterwards.
[flagged]
>talked about what they didn't like with how Jarred acted and worked
Gossip and hearsay; the "grapevine".
Besides, what does it matter how a language user does business?
Here are the highlights of the supposed "they work in a way I don't like" disagreement:
> I described him as someone who had strong "beginner energy"
> groomed from a young age into uncritically embracing the Silicon Valley mindset
> Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show
> We became increasingly horrified at the programming practices we saw in Bun's codebase. Hacks on top of hacks
> Jarred was already writing slop well before he had access to LLMs
> While I resent Jarred for making Bun into an embarassment for Zig
And what is even the point of saying that Andrew dislikes how Jarred acts and works?
Let's say the supervisor wants you to write a new microservice. Do you refuse to do it because the supervisor smokes cigarettes and you're an anti-smoker? I think that if you have objections, you should refuse only on technical grounds, not personal.
[dead]
It is in there nature. They (specially zig creator) were so jealous about about vlang getting traction and getting $800/month donations, they made it their core mission to attack vlang and spread hate.
Vlang is a ridiculous project that was entirely driven by hype that should have been easy for all to see straight through. It is ridiculous that it got $800/month with nothing to show for it. I haven't seen any hate spread for it by Zig.
> Vlang is a ridiculous project
With over 37,500 stars, over 2,300 forks, 826 contributors, books written on it (in Japanese and Portuguese, besides English), and a Wikipedia page; vlang is clearly a significant and successful open-source project.
> entirely driven by hype
People can plainly see Zig (and other HN pushed languages) directly engaging in marketing propaganda and hype (with HN accounts clearly stating they are from those projects) using social media (including HN) at levels way beyond anything anyone could accuse the V project of doing. The creator of vlang is also not a native English speaker, where the creator of Zig (and other competitors) have no such excuse. They know exactly what they are saying, the connotations of it, the cultural nuance surrounding it, and what it means in English.
> ridiculous that it got $800/month with nothing to show for it
Jealousy over vlang getting as much (or more) donation money (in 2019) from its supporters was a central theme in numerous social media and website posts made directly by Andrew Kelley[1]. Even to the extent he and the Odin creator[2] were asking people to give them money, instead of to the V project. Many would consider such behavior as extremely bad and unprofessional. Also note, there is no reverse of such behavior to be seen by the V community at them, instead we see uncalled for conduct and statements being directed by them towards the V project.
Donations that vlang had received and continue to receive, is from their supporters. Some of these paying supporters have even come to HN, to publicly express their support[3][4][5] against competitor false accusations and disinformation. Competitors should have nothing to do with someone else's supporters giving donations, in the same way that vlang's creator does not speak on who donates or supports their projects.
> I haven't seen any hate spread for it by Zig.
It is documented, on HN no less (and elsewhere), where people can see Zig's creator directly slandering vlang's creator[6] and this kind of unprofessional behavior encouraged followers to do similar.
[1]: https://news.ycombinator.com/item?id=39495369
[2]: https://news.ycombinator.com/item?id=20231704
[3]: https://news.ycombinator.com/item?id=31801287
[4]: https://news.ycombinator.com/item?id=31801262
[5]: https://news.ycombinator.com/item?id=31812189
[6]: https://news.ycombinator.com/item?id=20230351
I don't see any hate in these references. Perhaps just truths you don't want to hear. I've seen your name pop up multiple times in past conversations about V in response to anything less than positive. What's your involvement with the language to watch its discussions so ardently?
> I don't see any hate
People know what jealousy, slander, and unprofessional behavior are. Including how the V project is treated, regardless if certain others pretend not to or try to blank out others for noticing.
> What's your involvement with the language
Just responding to the comments of others, like the truthful one made by f-serif.
Not part of any V organization, just use the language (and some others). Which is more than I can say for a number of accounts where their profiles clearly say they are directly part of or work for the Zig organization.
Yeah this is why Vlang is banned from discussion on HN; any time it comes up people have a critical thing to say about Vlang, these guys descend with paragraphs, links, and a list of grievances about how their language is slandered and hated by people fueled with envy. Doesn’t matter if it’s buried in a thread in a comment section in an unrelated story, these guys rush in to defend the honor of Vlang.
Meanwhile, years later Vlang still have not delivered on the initial claims that made the language even remotely interesting.
It's the old craftsmen vs industry issue, Andrew comes from the craftsman tradition that prefers all other people developing to also be proud craftsmen.
What Java, JS, Python and C# all did to conquer the industry from a C++ dominance was to provide safety harnesses for less "perfectionist" workers to fumble around without causing a mess, to write C and C++ in an increasingly hostile world we realized you needed a lot of craftsmanship, the performance benefits outdid and kept the latter languages relevant for a long while.
Still, the performance/predictability penalty didn't give way so Rust (and Swift) came into play. They don't have as many unpredictable performance characteristics as the previously "safe" GC languages but still provided more or less the same guarantees (in some ways perhaps even better for Rust).
The brilliance of the Rust ideas did start a bit of a cambrian explosion of languages in that niche, most of them however targeting a bit more of a craftsman position than Rust (that came out of distinct industry needs).
The problem as the article illustrates, in car terms.
If Java,JS,etc are mostly "regular safe cars" and C/C++ a two wheel motorcycle.
Rust is perhaps a rally car (fast but still a car so occupants inside are well protected) whilst Zig really is a quadbike or open wheel cart, not as unsafe as a two wheel bike since you won't slide for the smallest oil/ice patch but flipping over is still dangerous as hell.
And that takes us to the crux, so many developers who love the craft and perfection (and don't live under- or perhaps care of- financial constraints) think that "good careful" developers is all that's needed and don't see dangerous language designs as a problem.
I'm an older developer, and given that I can write "good careful code", but 90% of the time it's also a matter of time and financial constraints so I wouldn't trust mine (or anyone elses for that matter) code written under those "industry" conditions.
I think Zig has a lot of nice perks, but it was obvious from day 1 that it's very much for people that love their hacking freedom over writing code for todays hostile world.
All I’ve seen is there is literally no programmer smart and careful enough to never create a use after free or out of bounds read in a sufficiently complex codebase.
The state of computer security has moved on from the old model of just patching bugs when you find them. To now where we need to systematically prevent them from happening to begin with.
Have you heard of TigerBeetle? Being smart enough doesn't seem to be the primary factor. It's about having a strategy and the discipline to follow it. No type system will ever free you from the burden of doing the actual engineering.
I find TigerBeetle very impressive. One of the impressive (and correct) decisions it made was to use an allocate-up-front pattern, which makes certain classes of temporal memory corruption harder to write.
At the same time, TigerBeetle can do this because it’s solving a specific shape of problem that’s amenable to that allocation strategy. Binding a third-party runtime written in C++ (TMU, this is what Bun is) is a pretty differently shaped problem that doesn’t easily admit that style.
In other words, discipline isn’t always enough (although you do certainly need it). Sometimes the shape of the problem makes environmental constraints (like the kind Rust offers) important.
[dead]
- types rarely catch the interesting errors
- any GC'ed language can manage memory for you if you want
- My first rust project (a gui app in GTK) managed to segfault just fine in spite of Rust (no unsafe blocks on my part, not deliberately trying to break anything).
- I think the state of computer security has moved on still, we now rely on LLMs armed with various tools to pick apart and try to break our code AND to generate our code -- it is not at all obvious to me that banging your head against the borrow checker is a worthwhile tradeoff in this new world.
That was a pretty good car analogy. Thank you.
Edit to add: I'm unsure where assembly would sit in this analogy. Skateboard? Monocycle? Perhaps ice skates.
Ice skates with a rocket engine on your back?
Surely assembly language is like moving with your legs? A Flintstones car, and machine code is walking?
I trust myself to write good code, but I’ve been under pressure to rush things and extra features in Java, C#, TypeScript are really great on those occasions. I love C and Perl, but as you say, there’s not a lot of safety harness. A lot of trust is required for those in a team.
Where is D-lang in your car analogy? Would it be a Ferrari? :)
Can't remember the exact featureset of the popular D one (because boy, was there many languages called D and E and so on over the years in the 80s/90s), I'd say to be a car it needs both temporal and bounds safety at the least but faintly I remember D being a bit of a kitchen sink? Wasn't there 2 standard libraries for a while? Were they even coherent in style/used language features?
There's one standard library now, it has great C/C++ interop, and the language features make more sense to me than C++, go, rust, Java, even Python.
If Rust is gaining popularity because it is an alternative to C++, D-lang needs to be included into that conversation, IMO.
The results improving the end user experience didn’t have much to do with the rewrite. Improvements in binary size and speed could be had with similar efforts on the Zig codebase. They spent extra effort to get those metrics to look good to sell the rewrite.
The memory safety aspects could be discussed. Arguably they could have had equally good memory safety by employing AI, tests and fuzzing (the Zig integrated fuzzer that the Zig team suggested they use, not just the high level fuzzing they were doing)
For this kind of project I do think using Rust is a good idea. At the very least because a project like Bun probably can benefit from a more mature language.
But I also think Andrew’s perspective of this process has been essential to understand what happened here, and though he could have been nicer with his word selection in a couple of places (he doesn’t have the clout of Linus Torvalds to get away with it), what he wrote absolutely needed to be said. I find it annoying that people dismiss it as personal attacks. If being a bad manager is the direct cause of a poor working relationship and bad engineering results, pointing it out is not a personal attacks. It’s essential context for understanding what happened.
> If being a bad manager is the direct cause of a poor working relationship and bad engineering results, pointing it out is not a personal attacks.
The post did no such thing — it spread rumors and leaned into gossip. There’s no proof or evidence or examples whatsoever offered by Kelley except Jarred’s own public words, which means the post didn’t reveal or expose anything about his management.
It doesn't need to expose something as new to point out a causal link?
Someone saying that work-life balance means all work and no life, and then producing substandard quality at said work seems worth pointing out.
A trillion dollar company vibe-porting a vibe-coded low quality product for clout/advertisement seems worth a call-out.
No causal link was demonstrated, only gossip. Maybe if evidence was provided you could say that, but that’s not what happened.
> Anthropic is not in the programming language market
Arguing that a product that sells itself as improving programmer productivity by writing the code for you has no stakes in "the programming language market" because it doesn't sell a programming language of its own is impressively shortsighted. Especially when the leader of a programming language has openly stated their dislike of vibecoding, critisized the industry, and the language project itself rejects PRs made with the product being sold.
Yeah I don't understand these myopic takes.
Jarred's post about Bun-Zig-Rust post was technical and polite.
Andrew's post in response was anything but that.
I'm starting to think that a way we can easily filter what's being heavily composed by (SOTA/mainstream) LLMs or not is by how "polite" the public sees their published blog post.
If everyone sees the post as "polite", most of it probably been written by LLMs, as they remove anything that could be seen as "nonpolite" and human. Meanwhile, engineers who just want to publish their own thoughts and feelings on a subject, will be filled with stuff the public sees as "nonpolite", and since those hard edges weren't trimmed before the publishing, we can then assume this is actually a genuine person's thoughts and feelings.
Your post seems pretty polite. Did you have Claude write it for you?
That'd have been fun, wouldn't it? No, I'm too lazy for that, HN gets my raw and unfiltered disgustingly human thoughts and feelings, unfortunately for all of you.
For shits and giggles, I asked Sol xhigh what it thought about my previous comment, giving it a "6.5/10 for politeness", saying "it’s polite in tone, but somewhat provocative and reductive in substance.".
Maybe this filter should also include provocativeness and reductiveness, and if it isn't provocative and reductive enough, surely it's a LLM? ;)
To be useful the filter should give a positive on content I personally disprove of.
Polite but misleading in a way that makes zig look bad. So of course the response is sour.
Yes, it’s a misleading, self promoting marketing piece, of course the tone is different between them - I’m struggling to believe some of the tone policing comments here are entirely honest
IMO if Jarred wasn't literally working for Anthropic and using their tools to do the rewrite, the whole thing would've been much more well received. Imagine if he'd used Sol to do it (while working for Anthropic – impossible of course), or GLM 5.2, etc.
Instead, since he does work for Anthropic, it just looks like a big marketing gimmick that was going to be done whether it was the right thing to do or not.
Yea, but he was the one who started Twitter war on Zig. He framed Zig is bad because zig wouldn't accept my slop PR etc...
I'm a heavy Rust user who doesn't like Zig all that much.
I browsed through the Bun code following Kelly's post, and decided to have Codex replace all my Bun usage with Deno.
Care to given an example of the egregious code that led to such a drastic personal shift?
Did you use any specific tools, like ast-grep, or did it manual way?
> Anthropic is not in the programming language market;
No, they're intentionally in all the programming language markets.
Maybe. But they don't particularly care about one programming language over another.
Just like Google might sell ads on (approximately) all the websites, but they don't particularly care which website you visit.
> Maybe. But they don't particularly care about one programming language over another.
Other than JS (which they obviously do prefer), this rewrite would have taken place no matter what programming language was originally used for Bun.
The reason for the rewrite was marketing, not engineering. The justification after the fact can be done no matter what language they were rewriting from.
Zig -> Rust : "We had all these memory errors"
Rust -> Zig : "We had poor iteration due to compile times"
Java -> Anything : "Memory is at a premium when we're trying to run a fleet of agents"
Anything -> JS : "We wanted a single language to optimise our agents for"
You get the idea.
> Maybe. But they don't particularly care about one programming language over another.
I mean, they did buy a JS runtime, so surely they must care more about JavaScript and TypeScript than other languages, right? Otherwise that move makes 0 sense.
Maybe this part from their marketing post about the acquisition is just a straight up lie I suppose?
> Together, we’ll keep making Bun the best JavaScript runtime for all developers [...]
> Anthropic is not in the programming language market;
Did we just read the same blog post? I see no assertion in it that Anthropic is in the programming language market, rather that this rewrite was a marketing opportunity for them they were happy to lean into.
> For context, I'm using Codex and have no interest in either Zig or Rust, so just observing this drama from the sidelines.
The latter part of the post is much less about Anthropic and more about AI coding in general so I’d say it’s still very relevant to your interests.
Did we read the same Anthropic and Andrew Kelly's posts?
Anthropic's posts were sanctimonious, self-serving, tone-concealed delegitimisation of Zig. Kelly's post was a strategically poor but sincere individual understandably frustrated at this concealed attack, expressing his honest feelings about the situation.
Yeah and Bun and Zig are not competing in anyway as well. Zig blog post has been updated as well recently btw.
> Anthropic is not in the programming language market;
The article by Ray Myers makes the case that Anthropic is in the programming language market by way of them having a clear monetary stake in making their agents look supremely capable of all tasks, up to and including rewriting an entire Zig codebase to Rust.
From TFA:
> Anthropic is actively campaigning to end software engineering. They need you to believe they can do that. Well, maybe it’s not you that they need to convince. Maybe it’s your C-Suite, various world leaders, or the manager of your retirement fund. They’ve raised $132 billion in investment, and are approaching an IPO valued over $1 trillion. Since they cannot show profitability, this depends on selling their hypothetical future impact.
> In literary terms, Anthropic is an unreliable narrator.
> One of their key narratives is: Coding is going away, then the rest of software engineering, and eventually most other human labor. This kind of money behind this kind of story has an impact, regardless of how true we think the story is.
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.
Andrew Kelley mentioned that the rewrite did bring technical improvements, however those were not tied to Rust and could've been made in the Zig codebase.
> Zig's response is a sour opinion piece full of personal attacks.
Not sure; it has some elements of personal issues, but they're followed by a rationale from the author.
Honestly, seeing the project lead (Andrew Kelly) take a stand against poor engineering practices without any equivocation makes me more inclined to want to use Zig - their values (in this regard, at least) align with mine.
He also substantiates what many of us are saying to all these "Very Senior Chief Engineer with 40 years experience" who are boasting of 10x productivity: these people aren't reading the code they are generating, and were producing slop even without AI.
You mean Anthropic has no agenda on its own? That seems a very biased analysis here. The response by Zig could be flawed (speculation, I have not reached this conclusion yet) but I don't see how this offsets Anthropic wanting to promote its AI slop here in any way, shape or form.
Stating you use Codex does not add any meaningful information to the case.
I think the point of mentioning Codex was that the author of the post has no relationship with Anthropic, even as a user.
It's said to imply they have no bias. But someone using Codex or AI agents heavily already have a bias here, just to be clear. Because the discussion isn't just about bun/anthropic/zig/rust, but also between AIs role in coding. So them touting their use of Codex, while not Claude, can still be a bias, especially in the direction they're trying to absolve themselves from.
It reads as "I don't use Claude Code."
I'm using Arch Linux btw
Meant to imply he's not a Claude fanboi.
What I have been missing in all this debate is substance. I don't care that Bun was ported to Rust; I don't care that Andrew wrote a hit piece about it; I don't care that Anthropic sells shovels in the gold rush.
What I do care about is technical details. Jared shared some motivation as to why they ported to Rust, and I think they look valid (even if provided with sparse evidence). But I have not seen any sort of refutation from Andrew that these are not actually issues or how they should be solved in Zig canonically. I'd really like to see an exploration of these arguments, specifically pertaining to the Zig code as it was written for Bun.
The facts as presented from the Bun side show a lack of technical merit for the rewrite. This shouldn't be surprising, because rewrites are bad engineering, in most cases.
The Bun project was started in Zig by someone with a lack of experience using the language, despite the massive scope and complexity, and was effectively a rewrite from another language in the first place.
From the Bun post:
> Bun started as a line-for-line port of esbuild's JavaScript & TypeScript transpiler from Go to Zig.
Then, a few years later, the entire codebase was thrown out to do another rewrite in another language.
What is there to address?
Porting TypeScript to Go in 7.0 doesn’t seem like bad engineering. Neither does this port, given that that Bun started out in a somewhat buggy state.
Completely different approaches. The TypeScript Go port was done responsibly, reviewing every line ported, publishing both runtimes in parallel to give it time for real-life battle testing, with plenty of communication to the community about what was happening.
The Bun Rust port was irresponsible and unprofessional, merging a million lines of unreviewed code while gaslighting the community, relentlessly casting shade on Zig while pretending to be neutral and objective. The Bun rewrite was not just bad engineering, but also (one might say "stinky") management and community relations.
It's no wonder the author of Zig blew up emotionally - which was also unprofessional but at least it was honest and human, unlike Bun's author.
Relentlessly? Where did he post about this and how often?
> Porting TypeScript to Go in 7.0 doesn’t seem like bad engineering.
They needed 10x speedup and it was not possible with the current language. And they chose Go, because they could retain 1:1 architecture in most cases. So whether or not it was well engineered, is not so clear. They did not choose Rust because they would have needed to redesign the whole architecture.
In the case of Bun, it smells more like bad engineering, so I am not sure if these are comparable.
> rewrites are bad engineering, in most cases.
I think this situation is a referendum on whether that is still true—or, if it is true, whether the proportions on “most” have changed significantly due to AI.
Andrew essentially wrote that “bun code was bad anyway”.
And also he implied he doesn’t even want to engage with anything relating to this since Jarred is toxic and there is no value in the debate.
I think these points are fairly clear from his blog post
> And also he implied he doesn’t even want to engage with anything relating to this since Jarred is toxic and there is no value in the debate.
If he doesn't want to get involved, then why even write this piece?
He essentially was having a tantrum
You're allowed to have a tantrum when a 10 figure company is doing a marketing stunt and shitting on your life's work to do so.
If you spend X amount of years building something, and someone you know to be a mediocre dev trashes it in an effort to enrich themselves, you're allowed to expose the things you know about them. End of story. I wish more people would throw a tantrum. We should expose all these charleton and thieves.
Kinda like how the Bun team spent years building their product then this guy trashes it? Except for real?
And he didn't "expose" anything but gossip.
the best way I've seen it described is like this: Bun wants to move fast and breaks things, Zig forces you to move slow and carefully.
Bun wants to ship new features ASAP (a shell lang, sqlite/pg client, etc), so they'd really want stuff like memory management out of the way. Zig forces you to think and deal with memory management, lifetimes, etc. Rust is just a better fit like w `Drop`, and Zig explicitly won't add `Drop` or anything similar.
Just like I wouldn't write a SQL database in Python, Zig is not the right tool for Bun. So there isn't really anything that "should be solved in Zig canonically". I'd say it's more in how Jarred want the project to move forward. Move fast and break things.
[dead]
TFA article addresses this directly. The write up is good but it is selectively written to contain almost exclusively positives.
Like build times: they rewrote the Zig compiler to improve them, but Rust build times are typically much slower. Why no discussion of that at all?
> I don't care that Anthropic sells shovels in the gold rush
The people selling shovels are the ones building data centers and energy. Tokens are the "gold".
> What I have been missing in all this debate is substance.
That’s strange because in this (and Andrew’s in lesser extent) post there’s plenty of substance on both technical, management and corporate influences like the difference of styles guides vs agent instructions, binary size, compile time, Anthropic’s marketing and incentives, etc. It’s hard to miss.
A few of which are on HN front page.
I agree with some of Kelley’s takes, but the issue is the tone.
Does anyone think that if Bun had been rewritten from Rust to Zig that a member of the Rust core team would have written a personal hit piece against Sumner (while pretending it isn’t a hit piece)? Probably not.
Kelley can write what he wants, but as the BDFL of a rising programming language, people are allowed to react if they don’t agree with the public image being portrayed by Zig.
> Management eagerly approved the Rust rewrite option because it was a great marketing opportunity to showcase their new Fable model, Anthropic already uses Rust, and Zig is openly against using Anthropic’s products.
Yeah, don't discount how powerful "marketing" is to management/executives, and also don't discount how absolutely ridiculously petty people can be, especially people who end up like CEOs and similar, requires a particular person. I can definitively see reason #1 and #3 from that to basically already set in stone that Bun had to be rewritten in Rust.
I don’t understand why anyone thinks management of any kind was involved in this at all. It seems much more plausible to me that Jarred just does what he wants. He has said as much.
> don’t understand why anyone thinks management of any kind was involved in this at all
Because it’s marketing gold? Any marketer worth their salt would be super keen to get their claws into a project like this.
Anthropic and friends are in then business of selling LLM’s. This is a demonstration of LLM capability, they’d be foolish to not even try to cash in on it.
Think about what you’re saying. If Jarred does it because he wants to, what does marketing have to add? How do they “cash in on it”?
Why take what he said at face value after "Calm down; this is just an experiment... but actually I'm gonna merge this huge thing in a week"?
Seems like if the experiment didn't work, nothing to lose. But it did and he capitalized it in the most in-your-face possible. it would be interesting to line up the timelines of the Rust experiment vs him joining Anthropic.
Devs need to start realize how people in power take advantage of them. If you already have a bright starry-eyed Peter Thiel acolyte, it's not hard to see how they can be taken advantage of. Especially when it's a multibillion dollar company that stands to give you literally multigenerational defining amount of wealth.
They hired them because they already agreed with them. Reminds me of that Noam Chomsky quote during an interview:
> Marr: “How can you know I’m self-censoring?”
> Chomsky: “I’m not saying you’re self-censoring. I’m sure you believe everything you say. But what I’m saying is if you believed something different you wouldn’t be sitting where you’re sitting.”
Thank you. I was left confused after people praised the Bun to Rust blog post eventhough it contained very actual technical substance. No clear evaluation of options, very biased report on impact, missing figures. It absolutely didn't feel like an engineering blog post.
Maybe people were more interested in the agentic part more than the actual rationale for the port in the first place, because it was very disappointing from a technical standpoint.
>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 did they not go for it? This is the technical substance I'm looking for: an engineer explaining what options have been considered and what wanted and unwanted tradeoffs they present.
Also only mentioning figures for the platforms that saw an improvement is sketchy. "With ICU and code folding Windows and Linux get 20% smaller", what about macOS? Why did it not see the same gains? The fact that they don't mention it makes me think that they don't KNOW, and isn't confidence inspiring coming from the engineer who SHOULD know.
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.
Yeah since my whole point is about the technical merits of the rewrite article, I don't count that as justification.
Why is just a wrapper type "less ergonomic"? Everybody does that all the time in every language. And then if you can convince me it is less "ergonomic": why does it matter if it solves the problem? And that is considering humans write the code manually. Why does it matter if agents write the code? This makes no sense.
The example shows three extra lines of code, two of which are `defer`s. I'm not an expert in Zig and can't tell you whether the example they give is contrived, but the claim they're making is way more than "a wrapper type".
> And that is considering humans write the code manually. Why does it matter if agents write the code? This makes no sense.
Because the particular form of non-ergonomic code that is demonstrated here amounts to a quadrupling of tokens. That's a substantial hit to the context window for safety that isn't even statically enforced.
A wrapper class if you want, a wrapper type with methods / dedicated functions. Still, seems pretty ergonomic to me. Yeah we went from one line to three, but the three lines guarantee safety whereas the one doesn't so?
Also I'm not sure the token count is very relevant for an Anthropic employee who just spent 165k worth of token rewriting the whole thing in Rust. Sprinkling a few defers here and there and swapping types surely would have been immensely cheaper in tokens.
You're failing to distinguish between token count spent and context window used.
You're correct that the former is not a concern for Anthropic, but it's also not the problem I'm pointing out.
The actual is not token count, it's context window. Your context window is finite, and every token you add to it reduces the model's accuracy during inference.
As the article mentions, the follow on question from that is: why does that matter if your codebase is written exclusively by AI agents?
Because if you have to quadruple the number of tokens in your code base in order to make the Zig provably safe, you have 1/4 of the context window to do useful work.
So why not say that? Perhaps because it highlights a flaw in AI agent workflows?
Because what they did say is true for both agents and humans. Which makes it a more compelling argument than just emphasizing the specific aspect of that limitation agentic workflows.
In one comment you are presuming that agents can just ignore ergonomic problems, which would be a kind of magic if it were true, and in the next you are saying that their inability to digest enormous quantities of unnecessary tokens is some kind of flaw that needs to be called out.
Enormous quantities of unnecessary tokens are bad ergonomics for anyone, agent or otherwise.
Every blog post has infinite things it does not mention.
"Technical substance" simply requires that some technically substantive things are mentioned. Which was indeed the case.
Not about the things that matter.
If you write a blog post about "I switched from X to Y", I expect the WHY: the pros and cons of X, of Y, and of the alternatives that were considered and dismissed before considering Y.
This is more a blog post about how to use Fable to switch from X to Y, than it is about X or Y.
Why are we even discussing stuff like work hour expectations in a story about language switch drama?
Even if the guy is a terrible manager this still comes across as a determined attempt to find something negative to say.
To me it’s telling how little focus there is on the technical merits of the rewrite from zig side. Anthropic claimed a bunch of victories and as best as I can tell nobody has even attempted to refute them.
If I was running a project and someone threw it into an LLM rewrite and it comes out with improvements and silence on downsides I’d be pretty worried and try to address that. Instead we’re talking about working hours somehow
I really don't understand what Andrew Kelly hopes to achieve here. Even the non-programmers at r/programming who usually piles on any type of anti-AI posts called it out.
I'm trying to not let this affect my thoughts about Zig as a language but it's hard.
TFA has an odd perspective.
> Views are my own. I have no history with Zig. I’ve never spoken to Andrew Kelley
There are better primary sources to explain what ZSF is trying to achieve with its AI stance. Kelley's rant [0] was a bit much but the ZSF AI Policy [1] and Kelley's interview on it [2] are interesting and informative.
[0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...
[1]: https://ziglang.org/code-of-conduct/
[2]: https://www.youtube.com/watch?v=iqddnwKF8HQ
I think the only point that matters is that having Anthropic owning a project which is written in a programming language where the community (or at least the leaders of it) have come out as openly hostile to AI generated code is a clear conflict of interest. I think Andrew Kelley might have been better to say just that and leave it - the comments about Bun's founders energy and motivations don't really add anything worth adding in my opinion.
Yeah, hard to imagine opposing AI absolutists settling their differences.
IMO all the technical arguments and attacks are post-rationalization; different orgs, different contexts, different goals.
I think Kelley saw this, but couldn't resist muddying his point. I give him a pass. The rant [0] is too much, but the addendum about moving on is healthy, and I'd rather the BDFL be too spicy than not spicy enough.
[0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...
> From my perspective, Anthropic is the party we need to hold accountable here.
It's insane that Ray Myers thinks that Anthropic did anything related to this port that requires holding them accountable; the fact that he used those words makes me want to prevent him from having any influence over AI policy.
Funding and owning something makes you accountable yes, that's how it works normally.
Also pushing it for marketing purposes and giving free preview to Fable might contribute something.
For what, rewriting an open source project in a new language? It’s insane that in 2026 this is seen as controversial.
No, for repeatedly using such low quality rewrites as marketing for your upcoming IPO, to convince people to evaluate your company more.
It's insane that in 2026 we are still falling for these tricks really.
Why shouldn't people evaluate Anthropic more after seeing this technical achievement using their software product?
Seriously, let's say that every single instance of people using Anthropic LLMs to translate code in an open-source software project from one language to another was deliberately orchestrated by Anthropic's marketing department, with the aim of increasing their stock price at IPO. Even if this were true, why specifically would that be bad? Why would that be some kind of offense that Anthropic as a company committed, that they would need to be held accountable for?
If you think that Anthropic's stock price will be overvalued at its IPO because too many other investors are looking at uses of Anthropic LLMs to translate code in this way, drawing a flawed conclusion from them, and then using that flawed conclusion to bid up the price of Anthropic stock, then you can trade against them in the market. Short Anthropic's stock. If you're not sure enough about this thesis to actually make this trade, then why should anyone take you seriously when you claim that this is some kind of "trick" on Anthropic's part?
Inconceivable
> It would be inconvenient if maintainability still mattered because their products default to making it worse.
I think this is the most important line from this piece.
Incentives matter. The AI companies are incentivized to have us believe that LLMs are the new compiler. That’s ridiculous (a coding LLM is a very very leaky abstraction) but I hear coders, especially coders with poor fundamentals, say it all the time.
This entire AI period has been a study in marketing disguised as futurism.
I say this as one who uses and teaches AI. What fantastic, amazing, unreliable tools. Extraordinary in the right hands, but engines of cognitive and technical debt.
The thing is, it's possible to call a spade a spade without resorting to ad hominem. Andrew's post would've been more effective if he focused more on the Rust port being for marketing, and the shortcomings of Bun's Zig implementation.
Instead, the first half of it solely consists of personal attacks.
Every one feels a bit wrong here.
Zig’s author, Andrew Kelley is out of line here.
> We made futile attempts to guide them towards better programming practices. There were a few exceptional heroes who did their very best in a dysfunctional company. You know who you are. But you can't stop a rising tide.
https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...
So not only is Zig written by amateurs, but these amateurs also don’t know how to run a company?
Who is Andrew to say this, Oven got an exit. As far as their investors and owners are concerned that’s the only real reason to exist.
Assuming ( big assumption to be fair) all the early Bun employees got a fair amount of equity they’re all rich now. That’s a much better outcome than most startups.
At my first startup we had 6 day work weeks. I still remember staying up until 2 or 3am manually installing Postgres again and again. All we got was a paycheck. Although for me I went from a minimum wage earning college dropout to a 6 figure software engineer( at a new company).
As for actual coding… LLMs will always do better work in a well known stable language than something relatively new.
I had to give up on trying to get LLMs to write working Haxe code. Haxe is too niche for LLMs to handle.
I personally can’t stand Rust, it feels like it’s designed for machines to write. Zig is designed for humans. Outside of a 200k+ job offer you won’t see me learning Rust.
Zig is rather pleasant. I can imagine writing a side project with it.
Finally, my QA background is screaming in rage. You expect me to trust a project that you basically vibe coded in a week as a key part of my workflow?
You know it works because the automated tests ( which I guess you also vibe coded) pass ?
By that logic say I don’t like Rust, can I spend a few thousand in Fable tokens and ship DinnerRoll( Bun in D).
Is that enough to raise a VC round?
>As for actual coding… LLMs will always do better work in a well known stable language than something relatively new.
Say that louder for the people in the back, who still think that LLM companies don't influence the entire programming language and framework field, by merit of the fact that LLM's can only perform at scale after lots of training.
And when we reach the point where source code doesn't need to be read, said companies will vendor lock you even harder by marketing their own LLM-optimized language and framework, promising everything and the moon in terms of productivity gains. First class support was the reason they acquired Bun.
> can I spend a few thousand in Fable tokens and ship DinnerRoll( Bun in D).
Probably. Likely would work with sub fable class model too.
> Is that enough to raise a VC round?
Doubtful. Think this move only works for someone with an existing product and following
> Doubtful. Think this move only works for someone with an existing product and following
So what you’re saying is actually build it, get it in the hands of end users and then find co-founder who does nothing but call his VC friends.
Maybe this co founder will be merciful enough to let me keep a 5% stake. Although in all seriousness, given Oven sold for ( Google AI estimate) hundred of millions that would still be more money than I’d ever need.
> get it in the hands of end users
That’s the tricky part. Bun has a pretty big following. If you can replicate that at similar scale then yeah maybe there is a vc cheque for you in the future
| how their AI was powerful enough to do this rewrite (even though it was not powerful enough to catch a use-after-free)
This, I don't think enough people pointed this out. We have been sold the "coding is solved" and "software engineering is over" shit by Anthropic folks for a while now. The discourse should have revolved around claude's capabilities and instead it became a Jared vs Andrew thing.
I think two things can be true at once....It was obviously a great marketing story for anthropic but that doesn't automatically mean that engineering work had no value. Companies have always turned interesting technical projects into marketing.
I really don't understand what's the big deal here. Anthropic converted Bun from Zig to Rust using Fable and used that for marketing, but do people blindly trust them? Also isn't Zig still unstable and from that perspective regardless of how they did it, wouldn't it make sense to migrate it to a stable language?
> but do people blindly trust them
Judging from internet posts and HN comments, many do.
>Judging from internet posts and HN comments, many do.
Judging from the HN comments in the past on Bun's rewrite. I wouldn't even use the word "many". It was literally all Anti-AI comments and reckless engineering behaviour complain.
Then that's their own fault. Nothing to do with Anthropic, it could have been any other company putting out marketing material and people blindly trust them.
I don’t understand the distinction you’re trying to make.
Yes, “it could have been any other company”, but it wasn’t, it was this one. Had it been any other company, we’d be talking about that other company; because it was this one, we’re talking about this one.
My point is that the article starts with > Anthropic is actively campaigning to end software engineering
But that's true only if one believe what they are putting out blindly. Why not just call it a bluff and move on rather than making a mountain out of molehill
>that's true only if one believe what they are putting out blindly
That's true also if we see the impact their (and other frontier AI) tools have on employment and development practices.
It's a big precisely because so many people are blindly trusting AI company marketing. It blows my mind how many people, especially here on once-subversive hacker news, are not just swallowing the marketing but they are doing the marketing for these companies for free. That's why it needs to be talked about!
I'm not involved in this community, but I watched Andrew's interview with JetBrains a few weeks ago and I was really impressed. I don't currently have a project that would benefit from zig, but it's a language I want to explore when I have a good use case for it. I view his take as blunt but entirely reasonable.
Bun's rewrite has made me nervous about using it. I do have a project that would theoretically benefit from it, but that amount of vibe coding just makes me nervous. I'm not saying I'd never use it, but personally I'd rather wait for the dust to settle on it a bit. I feel like rewriting to a new language is going to be buggy no matter what (even if the tests pass), but an AI rewrite in a very short time makes me extra concerned. Just my 2 cents.
Also, one thing I want to highlight in the article because I agree hard with it:
> My advice? Don’t work for people that brag about 90 hour weeks. Work for people who will defend your ability to sleep at night.
I used to work in the games industry, where crunch was the norm, and I don't think crunching really helped at all past a couple weeks. I'm not particularly old (early 40s), but my performance falls off a cliff if I sleep poorly or don't practice self care. To me, people working ultra-long hours for marathon periods of time are making a grave mistake. It usually ends up being productivity theater rather than real productivity. Taking care of yourself is really important for being productive.
If left to my own devices, I can code 12-16 hour days. Have a crash day every 4-5 days, and then go back. It would be extremely unwise to merge even half of that stuff. I would frequently throw it away. Even before AI. It would be extremely naive to think that I am productive/efficient or responsible or a hard-worker for doing this.
Hey, I can party the way I like to party.
(I am old enough to catch myself and stop this cycle now)
Edit: I was super impressed with him in the first 10 minutes. It’s very Knuth-like to create a programming language because you had trouble building an audio system.
Andrew may be a little bit grating to some (including me at times), but I value the perspectives that he brings.
There is a lot of discussion about the exact tone and phrasing, etc, of Andrew's post. There's something there - we expect perfectly composed writing, never getting emotional, never saying how we actually feel about a specific individual's behaviour. Meanwhile, in private, we often let those emotions fly, name names, etc.
I think Andrew gave us an actual look into how he feels about Jarred -- ambivalent, largely.
Anthropic migrated Bun from Zig to Rust, they probably tried writing it in Zig using AI and ran into issues because there isn't enough Zig training data. A year ago, most LLMs couldn' t code reliably in Rust, But were fluent in Python, C, and web tech.
Nobody and nothing is fluent is "web tech"!
web tech - HTML, CSS, JS, and based/derived frameworks
Yes, but your reply has now also recharacterized my original comment. I wasn't being pedantic.
I was saying that LLMs even worse at writing for the web than humans, and humans are pretty bad! I'm saying this as a web developer.
oh, it is subjective and depends on use cases, for most of my use cases in web dev , it did work really good
>I'm saying this as a web developer.
Do you think this gives your claim extra merit? You understand it does the opposite, right?
What it actually achieves is that it makes you look like you're raging against the dying of the light, in utter and complete futility.
Yes, LLMs are especially good at the web stack, given that training data is overwhelmed with enormous volumes of such data. It is the one realm that has been completely obsoleted by modern AI, while a few other realms at least have some resistance.
The only dead end is this argument.
There are a lot of posts going on, but let me just post this link to a specific file of the bun zig code base so you can have your own impression:
https://github.com/oven-sh/bun/blob/bun-v1.1.42/src/bundler/...
My take is they vibe coded too close to the sun
I'm left with a good impression.
Lot's of comments on the whys and historic context.
Backed by tons of tests.
Yes the file could use some modularisation and splitting into smaller parts but maybe the gains were weighted and judged against.
That file is a great example of KISS.
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!
Determinism is a feature.
Sarcasm hat off: that was the joke
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. and here is that token heavy story!
so weird people are not commenting on this.
it's like.. I dunno, rewrite linux in rust, because bun uses glibc, this will somehow make it better, so claude code somehow can run better?
hell, start with UEFI.
I think this post completely destroyed anthropics narrative
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.
This paragraph is written by AI. I did not notice it earlier in the piece:
> The piece about the migration process is very cool, with details that are reusable. No complaints, I think that’s the real contribution here. I particularly like the honesty in explaining that this was a port to unsafe Rust, allowing a literal file-by-file migration to minimize risk, paving the way for redesign in future steps. That’s a sensible move explained well.
Pretty sure this section’s title was “Say something nice”
…he had to resort to AI for this part.
Why would the author write this paragraph alone using AI?
I doubt that is what happened, but this is where I quit reading so I did not evaluate the rest of the article. I'm assuming the previous section was either largely written by hand or it was much more carefully edited.
The thing is - is it a self fulfilling prophecy?
We already know junior hiring an are down. And how many people are now excited to learn to code compared to 5years ago?
How many of those excited people are ACTUALLY learning to code and not just learning to prompt?
LLMs/agents will take over (or at least dominate) software dev even if they don’t get any better because humans will just get old and there’ll be no new humans who know how to do it.
Well, I see LLM coding capabilities as a great enabler for people who have some codeing-like skills or needs, but were not sufficiently skilled to do something more complicated. Think of people who are good at Excel, who use statistical tools like SAS, SPSS, other analytical software. Now they can ask LLM to create a Pandas/SAS lang script and do much more advanced stuff.
People who were in the marketing data analysis (like sentiment analysis) - 5 minutes and they have a code that uses Hugging Face model suited for sentiment analysis, zero-shot classification, etc. No need to pay for expensive online services or expensive NLP software. It's here for free or $20 a month.
Still, it does not mean you will be able to code database engine with LLM, application server, rewrite Django in Rust, etc. So software engineers still will be needed to do ambitious, complicated stuff.
So, I kind of see it backwards, real skills, like knowing algorithms, understanding performance (including hardware stuff like processor caches, etc.) will become needed, as other, simpler jobs that needed only a "coding monkey" will be gone.
We no longer need to dig ditches manually, we have machines for that, but the purpose of the ditches is still planned by man.
If you push that ditch analogy though. Yeah we no longer dig ditches manually - but we also then all got overweight and weak because people aren’t doing any physical labour anymore. (Most people anyway)
And diggers absolutely do have a monopoly on digging ditches now.
I don’t see how someone learning to code now will ever be as good at coding as someone who learned before LLMs.
Just like right now no-one is gonna get better at digging ditches than people were before diggers - it just doesn’t make sense for someone to put the time and effort into that.
This is quite true. Also, there is no project you can make as a junior to demonstrate your unassisted competence because 10 other people used AI for a similar project
Not to "glaze" the author as the kids say but this has to be one of the best written musings I've read on HN in a long time. I'm likely bias because it's written in "my style" but I feel like it's a rather fair and balanced approach to a nuanced and socially difficult topic.
Zig creator's article seems to have changed? I don't remember the bottom bit being there when I read it a few days ago.
> Ray’s story: Faced with a legitimate challenge of memory bugs, there were several viable options. Management eagerly approved the Rust rewrite option because it was a great marketing opportunity to showcase their new Fable model, Anthropic already uses Rust, and Zig is openly against using Anthropic’s products.
Kinda makes sense. They also tried to make a C compiler earlier in the year. Idk what happened to that.
I guess it's an experiment without much downside for Anthropic, if it works use it to make a point about AI assisted coding - if it doesn't bun users will learn a costly lesson but who cares, it will just be another case study to make their product better.
That said, I think it'd be great to see this actually work out.
> Zig creator's article seems to have changed? I don't remember the bottom bit being there when I read it a few days ago.
Yes, Andrew edited it. Diff here: https://github.com/andrewrk/andrewkelley.me/commit/8b86ac915...
I agree that both Andrew, and the author have numerous good points, and yet I see things differently.
- I too am a fan of Andrew, and Zig, although all of my future plans currently are tied to Rust.
- I think the crux is that we are talking about 2 Vibe-ish AI rewrites, one to Zig, and another to Rust. I believe the investment in both reasonably minimal beyond the cost of tokens.
- I think that more adherence to a Zig style guide would probably have been very beneficial to the final work product.
- I have high expectations that the Rust rewrite will yield a more stable work product out-of-the-box. I am looking forward to the post-analysis.
Wow. Wonderful post; best read this year so far. Lots of gold in this one. I like the way the author slowly undressed the - social media influenced - hype to reveal both Anthropic and Bun as they are: awfully basic
By far the most satisfying piece I've read in this saga. Favorite line:
> I’m not the one saying that their environment resulted in a buggy unmaintainable mess, Bun is the one saying that.
> we still need good judgement and communcation in deciding where to go
I want to emphatically endorse this statement.
This is where the human workload will shift to: making good decisions... understanding why one path is preferred over another. And collaborating and communicating in constructive ways. More to the point, humans excel at being able to recognize when a chosen path is no longer fruitful, or where a conversation devolves into the unproductive.
We are constantly making decisions based on tradeoffs. We choose one approach over another, not so much because our chosen path is obviously superior, but because the peril on our chosen path is preferential to the peril on a different path.
I have used ai to great utility in my design process, to help me understand the tradeoffs within any given endeavor, greatly helping in choosing which path to take.
Thus far, I haven't seen an AI which can unilaterally be relied up on to always effect "good judgement" for the work it is tasked with completing.
But once good judgement, and the correct path, is codified in markdown files, ai can be exceedingly efficient in carrying it out.
People have got to stop falling for exaggerated rage bait.
But, but, how do we get to experience emotions otherwise? We have no life!
> Anthropic is actively campaigning to end software engineering
While this may be slightly overstated, my take on this is that AI progress should have us upgrade our view of the human brain rather than the opposite.
Wrote about it the other day:
https://livingsystems.substack.com/p/ai-progress-should-upgr...
I have found myself wondering a lot lately about the alternative universe where all the effort and resources devoted to developing and using AI coding and debugging agents were instead simply dedicated to fuzzing human-generated code. How would the code quality and total usefulness of the results have compared?
It should have been possible to build a new LLVM alternative, a new chromium like browser and some other similar things imo and that would have been definitely more impactful for me.
It is unimaginable how many static analysis tools or fuzzers could have been created with a fraction of LLM investment too.
For example honggfuzz was created by a single engineer possibly in less than a years’s worth time
The more I interact with the real world and mature as a person the less respect I have for temper tantrums such as these. Even if everything you say is correct, coming across as emotional and petty just does not help your case. This just makes Zig look like a zealot fighting a turf war rather than a serious ecosystem.
> The more I interact with the real world and mature as a person
I don't think this statement has the effect you want it to have. You're not laying out the experience you're speaking from. You're just setting it up so that no matter how reasonable the next thing you say is, it will appear maximally arrogant and condescending.
I disagree. It's fine to contextualise that an opinion solidifies over time.
And your parent is right to point out that emotionally loading posts tend to be a disservice to the message being carried.
Good grief! I can count at least 6 logical fallacies in your 3 sentences.
I remember the uber db migration post and I can't help but wonder if the tone of these conversations would be different for bun if AI wasn't involved.
https://www.uber.com/us/en/blog/postgres-to-mysql-migration/
> I remember the uber db migration post and I can't help but wonder if the tone of these conversations would be different for bun if AI wasn't involved.
Another point of view is that, if AI wasn't available, pre-port Bun wouldn't have been such a total mess that even Fable couldn't unfuck it.
IOW, the Bun codebase was being vibed well before the port; if AI was not available, would Bun have been in such a poor state that a rewrite was even necessary?
The AI panic has infiltrated the space now, and it’s just as bad as the AI hype. Half formed ideas, emotional posts with personal attacks and arrogant language, exaggerated claims, posturing, etc.
In the meantime, most of us are just using whatever tools are at our disposal and minding our own business.
"We wrap LLMs in Agent harnesses because AI isn’t enough."
This feels equivalent to saying you're not a real coder if you need a compiler to hold your hand. What, a human coder isn't enough?
Of course we're going to improve tools by building more tools on top of them. That's how we went from punch cards to assembly to high-level languages!
Anthropic isn't selling that, that's the point. Anthropic is selling "coding is solved", worth $1tn.
If they keep hiring developers and LLMs need huge procedural harnesses, then the hypocrisy is open for all to see. And worse for them, it probably means their business model is worth maybe 5-10x what Jetbrains is worth, not $1tn.
I agree that "coding" isn't solved but LLMs needing a harness is not necessarily a huge hit on AI
As for valuation, it's all a grift, always has been for anything hip in tech. SpaceX should've been in the $500b range and they have an actual rocket and working satellite constellations
LLMs needing harnesses is a hit on AI because it means LLMs can't be extended a lot (or indefinitely as AI boosters hope). We're back to (enhanced) expert systems from the 80s and nobody is excited about those.
And regarding SpaceX, SpaceX even without xAI didn't make a ton of money and it's business initiatives are super long horizon things. Moon bases won't be profitable for at least 10 years and Mars bases probably for 20+.
Also, even though they are behind, competition is moving. China caught their first rocket yesterday (and we know they can move fast), BlueOrigin is behind but they have the money to keep going. The EU and India will keep investing and developing as rockets are a core concern for both, at some point they will have reusable rockets.
These huge valuations for SpaceX are predicated on winner takes all mechanics, which are mostly software based. Many markets don't work like that since the cost to get another unit of revenue increases linearly with that unit. Not like software where extra copies and customers are basically free.
Coders needing compilers is a hit on coding because it means coding can't be extended a lot?
I'm just not following the logic at all.
We build vastly more ambitious software today than we did in the 80s
That's an intentionally obtuse comment.
Compilers are widely available as open source software not coming from companies that need to justify a $1tn valuation ASAP for their development of LLMs.
Also the LLM = compiler comparison is generally just ridiculous. Their complexity, both internal and in usage for coding are multiple orders of magnitude apart.
Oh yeah, nothing complex about a compiler, that only takes 4 years of college to understand. That's soooo much simpler than typing "make me a Tetris clone".
Literally no one has 4 years of experience with LLMs, because they haven't existed for four years. Today's experts are tomorrow's college graduates.
ChatGPT was released November 30, 2022. GPT-2, before that. So we're right around 4 years.
Umm, yeah.
Obviously the neckbeard who wrote C in vim and compiled when he is done is a better coder than the one who kept compiling and fixed issues when told by the compiler.
The neckbeards that wrote C did so precisely because they saw how C was a better way to get things done, and they were probably the first people to start using compilers, because, again, they're the ones that built them.
The neckbeards that wrote C tend to view LLMs as the obvious next step, and a lot of them actively use them for hobby projects even if they're not quite "maintain the Linux Kernel" tier yet.
In this whole discussion of what can be done with AI, I think a lot of people are missing the distinction between:
A. making consumer end-user apps, basic enterprise applications (making end products)
B. making tooling, libraries, languages (making things people build on top of)
What is the "software engineering" that AI will replace? A? Or both A and B?
Just because people can get away with using AI to make A apps that are "good enough" or pass test suites, does NOT meant that therefore people can get away with doing all software engineering with AI. B products require a whole other level of quality, stability, and extensibility.
I'm not saying doing A with AI is a good idea either, I just think that it's a fallacy to say that because you can do A with AI, you can do B.
> Just because people can get away with using AI to make A apps that are "good enough" or pass test suites
That requires some proof, because the trend is that users of A apps dislike the lack of engineering that comes with AI involvement.
Yes, I agree. I'm just trying to be charitable for the sake of the argument. I think it's better to make nothing with AI.
I think Anthropic is putting too much time and energy into marketing (and politics) while competitors are catching up on the engineering side.
But what do I know, maybe your CTO bought this and now wants to fire half of the dev team and use Claude to convert your COBOL codebase to Rust...
BTW a quick question...
Isn't it a case of "SVN trying to be CVS done right", as Linus Torvalds famously explained during his talk about Git at Google: SVN was doomed from the start because it's not possible to do CVS right.
Is this Typescript Zig any good? (don't know anything about it) Is it even worth porting to another language?
And why not an entirely new project? Ain't it an admission of failure of LLMs at writing new code? (porting ain't the same thing at all as writing a new project)
No dig at Zig: I just want to know if it's not yet another turd of the extremely turdy JS ecosystem.
Interesting article, seems more balanced than Andrew Kelley's one that it links to.
The thing I still think is wrong: why are Anthropic rewriting a Javascript runtime from Zig to Rust? Why not rewrite Claude Code itself in Rust (or Go or whatever, lots of options there) and drop Bun completely. That actually seems like an easier solution (rather than having to create a performant, correct Javascript runtime, just rewrite your CLI console app in something else) and the final result is better (smaller and faster) although likely not on the most critical axes for them.
> why are Anthropic rewriting a Javascript runtime from Zig to Rust?
there is a chance they tried..
I think Zig being a new and a low-resource language (not enough training data) is also one of the reasons Bun decided to use Rust as large language models will simply not be as good no matter how good the model is.
My experience was that LLMs performed at Zig and Rust at about the same level? That is: worse than at something like JS or C or Python, but well enough to write code that works. And they only got better since I first tried them.
Intuitively, Rust would perform worse because ownership is a different paradigm, while Zig is far more similar to things like C/C++. But I guess that's canceled out by the disparity in the language resource base.
Anything that can be written in Rust will be written in Rust.
I'm using Rust as a placeholder for a language with excellent performance and safety characteristics. It may not be a good thing, but there's no way around it.
If we expand the placeholder, I think "Anything that can be rewritten in a language with excellent performance and safety characteristics will be rewritten in a language with excellent performance and safety characteristics" is a desirable state of affairs.
if I had to pick a side, I would pick Andrew but I don't think his side matters as much. IMO, it doesn't matter the technical reason why Jared ported Bun, it's his project, his wanting to do so is enough. I think the issue is that Jared turned it into a technical subtle reason of why "Zig is bad" without meaning to, and Andrew goes on the defense.
All that said, the coolest thing is that Jared did so, I don't care if it came out a bit worse with Rust, the interesting thing is here is what can be done with AI/LLM/Agents today. Yes, it might be worse, but on a reasonable enough timeline, it will get better. Folks get upset about these things. I did AOC in 2024 with LLM, my goal was not to top the leaderboard, but to see how good LOCAL LLMs could keep up. I did it with Qwen2.5-Coder-32B locally, and solved about 50%. Folks were often upset when I shared that, called it cheating, etc, even tho I often started about 8hrs after the competition due to timezone. It was so good, I suspected the cloud models would probably solve 75-80% and I concluded after my experiment that in 2025, LLM can solve it 100%. I didn't bother to try and the models were an order or magnitude better locally.
No matter the take on AI, they are very capable tools and we are only beginning to figure out how they can be used. I don't think we should stop, surely it's frightening on what that would mean if it can really "takeoff". This fight is multi layered, Zig vs Rust, Writing good code vs bad code, having good development standard vs not, being honest and transparent in technical disclosure, attacking Zig vs attacking Jared, AI good vs AI not, etc.
Oh, they're converting Bun to unsafe rust. That's easy, but useless. That's the sort of thing c2rust does - transpile to an low level language which is unsafe Rust with a set of functions that unsafely emulate C pointer semantics. You don't need an LLM for that.
There's no point. It's not doing the job DARPA's TRACTOR program is trying to do - translate C to safe Rust. I've used c2rust. It works, but what you get out is like compiler output, not something you can work on.
> Oh, they're converting Bun to unsafe rust. That's easy, but useless.
You really need to escape the Zig vs Rust language wars bubble to get a real read on what Bun was doing.
They started by attempting a more direct translation. Not quite transliteration but close. At this stage they wanted to bootstrap the codebase into Rust as quickly as possible using parallel agent sessions, which requires minimizing the number of refactors that cut across the codebase. After it was bootstrapped into Rust they continued on the rewrite to take advantage of Rust’s features.
The anti-Rust side has been clinging to that first step as evidence that it’s all broken, ignoring the fact that it was an intermediate step.
The “unsafe” part is also confusing a lot of non-Rust devs who don’t understand that unsafe is used in cases of crossing FFI boundaries, which Bun does a lot of by nature
> ignoring the fact that it was an intermediate step.
They are going to release the "intermediate step" with all its issues as v1.4. I think that says a lot about which party is ignoring facts. (hint: not me, not you, not Andrew)
> The “unsafe” part is also confusing
They are right in this case. The code base contains thousands of the most unsafe unsafe blocks I've ever seen in Rust.
Isn’t the point that it doesn’t matter if humans can work on it, as long as the AIs can?
> That's easy, but useless
The Rust toolchain is a delight in comparison to Zig's, and the unsafe code only need be temporary until humans (or, gasp, AI) address each class of underlying issue.
This is a no-worse-off state to improve from.
Great Article. I appreciate the amount of detail you went into here to give everyone a fair hearing. Will there be a recording of your talk at the software should work conference next week? Thanks!
"A lot of reasonably good coders have never seen an example of a good manager, and have all kinds of weird ideas about what management is."
Banger of a quote that one.
I don't agree that Anthropic's position is AI is all you need. My interpretation is that it's about developer acceleration. I've been following their messaging closely and it's not that you can fire all of your developers. It's mostly their developers saying they are somewhat more productive. They have published papers showing that productivity gains are uneven.
There are billions of lines of garbage code out there written in C, C++, Java, you name it. So much garbage, it has driven people to create languages with tighter guardrails to help programmers.
Yet, I've never seen those language creators blame anyone else. I don't recall Bjarne Stroustrup lashing out at people migrating from C++ to Java, Rust, or anything else.
Maybe humility is just a generational thing.
I think I got all the information I need to be able to judge that article from seeing that the author calls themselves a "Retrofuturist Software Mender".
[flagged]
Not sure what you mean, I have one account. Did someone else express this opinion?
What opinion? Ad-personam attacks against the author and not the actual content of the link?
Like any hype cycle some of it is… hype
And like anything in the world things change.
So will there be change in the way we code? Certainly. Are some claims overstated? Certainly.
Bravo for Andrew! We need strong leaders, not weak ones.
> The Bun code is a mess because of their engineering decisions, including overusing AI agents to write and review everything.
Life would be paradise if people were just good for each other. They are not though. So you need a system for that case. Rust is a system that fits the modern real world software development dynamics than Zig.
Related:
My thoughts on the Bun Rust rewrite
https://news.ycombinator.com/item?id=48843352
Rewriting Bun in Rust
https://news.ycombinator.com/item?id=48837877
Languages do matter.
And I think the only sensible backend languages when starting a new for-profit project is Python, Go, and Rust for 99% use-cases.
In other cases, third-party packages, tooling, integrations, and telemetry starts to suffer.
Keeping it to the most mainstream, Java is a mighty fine choice as well, with even better options for third-party packages, tooling, integrations, and telemetry than most of the above.
I think most organizations don't want to increase their Java usage.
And the reason is not technical. Technically, it is a great language.
Legally, it feels risky to most.
I think that's absolute wrong.
The situation with Java is absolutely clear.
I think Odin's batteries included approach have a chance to achieve escape velocity.
Specially if their community and their BDFL continues to be welcoming and fun to interact with.
Their 1.0 roadmap announcement is cool: https://youtu.be/dLPAqXi9In0
Here's most of the language in a single demo file: https://odin-lang.org/docs/demo/
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.
Why would you need any of those listed capabilities these days? Just generate them with 100x AGI
There is going to be a lot of this kind of thing as AI makes writing manual code optional at best. A project that bans use of agentic coding is going to have a slower development cycle, as Zig is already fairly pedestrian (for said reasons) it's going to become less and less relevant i'm afraid.
There will be a group of programming languages that become the main choices, (Rust, Go, Typescript, C++, Java, C, Lisp and Haskell) for agentic coding, Zig was slightly too late to the game, the great LLM cutoff has happened.
Andrew is trying to fight the tsunami here with a paddle boat as his vision of Zig was conceived before LLM's landed on the scene and is likely unable to accept it.
I love how many people are tech prophets now
Do think the majority of SWEs will be hand cranking out code like it's 1999 in a few years?
No, because nobody has been coding the same way since 1999. But that has nothing to do with LLMs
Andrew Kelley's thoughts on Jared Sumner is insanely savage.
But fair?
I wonder how AI is going to affect language development and discussions like this. Zig taking anti AI stance is commendable, but it’ll surely hurt adoption.
Interesting thread. On the verification side — do you think formal methods or fuzzing scales better for catching the class of bugs LLM-generated code introduces?
Those problems are partly attributable to Zig itself. If the project accepted AI-assisted contributions, this controversy might never have happened. Completely shutting out one side of the industry and taking a dogmatic position is not helpful, especially for a pre-1.0 language that is still relatively immature.
Now the Zig community is attacking one of the largest and best-known codebases ever built with the language. Anthropic’s motives are clearly promotional, but even so, I would not choose Zig for any project.
> Completely shutting out one side of the industry and taking a dogmatic position is not helpful, especially for a pre-1.0 language that is still relatively immature.
It is useful, you just have different goals in mind than the Zig leadership. Zig shared their detailed reasoning for that decision, which is mostly about the development and protection of the community
> If the project accepted AI-assisted contributions, this controversy might never have happened.
Had I given my wallet to the thief, this controversy (me getting stabbed) might never have happened.
This 100% was a way to getting back at Zig for not allowing their parent company's product, and a marketing move for Fable.
I'm on the same page with you that their AI stance is probably harmful for them -- but I think they wrote those as a reaction to the contributions from Bun and others. So your implied timeline is not entirely correct.
Nobody should feel insulted simply because a project decides to port its codebase to another language. It is a technical decision, not a personal attack.
Zig’s response has been a serious mistake. The TypeScript team ported the TypeScript compiler and language service from TypeScript to Go for TypeScript 7.0. Did anyone interpret that as the team insulting TypeScript itself? I certainly did not.
They don’t care about the switch and it seems they’re actually happy with it. What they care about is the implied messaging that Zig has issues that the rewrite in Rust solved. Andrew highlighted that they had bad engineering practice, the rewrite did not solve anything, and they invested a lot of engineering with Rust to try getting things to work, engineering effort they have not invested in Zig.
> Did anyone interpret that as the team insulting TypeScript itself?
No because Go and Typescript have wildly different use cases, and they explained in details the rationale for migrating the compiler, and why Go versus Rust. Their rationale makes sense, and did not throw Typescript under the bus (obviously).
I don't know, sometimes programming language choices seem to be in the realm of theology, not computer science or engineering.
What is more hurtful than somebody else making wrong religious choices?
Yes, why would Zig respond seriously to a company that has proven to have utter complete disdain towards humanity? Why would anyone be upset that a company is ruining workers lives, poisoning innocent civilians, and being used to kill school children?
That's just not fair!
> In the AI bubble, we are pressured to build things nobody wants, poorly. Pop the bubble.
I'm sooo waiting for this to happen. I miss the old times where simplicity, clarity, and good architecture mattered.
Agreed. The outrage around what Andrew said was performative and melodramatic. I remember the "no work-life balance if you work here" thing, and then I remember Bun's CEO last year complaining he might not be able to get H1Bs anymore...
And this whole thing reeked of a publicity stunt. Show people you can use $$$ of tokens to vibe code a refactor. The headline is how great anthropic - bun's owner - is.
A lot to unpack here, setting aside the drama I get a few takeaways:
- Your AI code is probably as good as your human user's skills and attention:
Seems pretty likely they were shying from style guides because the AI use was itself sloppy. I'm not a big AI user but if I just ask a chat model for some code it will give it to me, then I have to go over it and fix the code for our check-style. Without deliberately aligning all your AI use to enforce it style is hard to maintain. Existing lack of style was a technical debt they didn't want to pay.
- The most popular language is probably the best language:
I suspect the amount of training data on Rust is several orders of magnitude greater than Zig. I suspect they could have gotten there simply asking the LLM to rewrite the Zig thing in Zig, however I'm betting LLMs write much better rust code so why not take the opportunity to move to a language that will get all-around better results.
- Technical bankruptcy is more favorable than paying technical debt:
These migrations we're seeing seem to point to a future where it's simply easier to burn a code-base to the ground, take the test suite and re-implement rather than actually pay large amounts of technical debt. I think this is a pattern that will come up more often with heavily AI written codebases that become untenably noodley, or brittle.
One of the things I find so disappointing about Kelley's behavior here is that he falsely accused Jarred Sumner of lying about fuzzing Bun, and then when Sumner showed evidence[0] that they've been fuzzing Bun for months, Kelley just silently edited his post[1] to walk back the accusation and never apologized or admitted he was wrong.
I commented on Mastodon[2] to point out to Kelley that it's dishonest to silently remove the accusation, as so many people were already talking about it, and it confuses the conversation if Kelley retroactively edits it, and he replied[3]:
> the false claim is in the bun blog post not mine. I only changed the text because it's easy to lazily argue against it. Please read more carefully. They are the ones being deceitful not me.
Loris Cro, Zig's VP of Community, gave a slightly clearer response[4]:
> Jarred's post has a section about what they "were already doing" to maintain their Zig codebase, which includes "24/7 fuzzing", which will make the average reader assume that the codebase has been fuzzed thoroughly, while in reality it has been for, what, 2 months before the rewrite?
Even then, I find it so bizarre that Loris thinks that if someone says, "We've been fuzzing Bun," and shows evidence of months of fuzzing, then that person is lying because "We've been fuzzing Bun" somehow implies something longer than two months.
The duration is irrelevant. If you say you've been fuzzing it and you've fixed bugs that your fuzzer found, then clearly you're fuzzing. The Zig team doesn't get to arbitrarily move the goalposts of what "fuzzing" means.
[0] https://news.ycombinator.com/item?id=48845652
[1] https://news.ycombinator.com/item?id=48854921
[2] https://m.mtlynch.io/@michael/116896188093796421
[3] https://mastodon.social/@andrewrk/116897155344411469
[4] https://hachyderm.io/@kristoff/116898483283387067
> The post claims they were fuzzing their Zig code, while during our calls the whole Bun team told us that they were not fuzzing anything
If you read the post again this sentence is not removed and Sumner did not refute that
Right, that part is not in dispute.
If Sumner says today, "We do X," then Kelley can say, "Nine months ago, Sumner did not do X," and both can be correct. What Kelley can't do is say, "It's an outright fabrication that Sumner does X today," based on an observation from nine months ago.
Now you've misquoted me. Actual quote[1] is: "This appears to be an outright fabrication."
To quote yourself[2], "The honest thing to do is acknowledge that you were mistaken and apologize for the false accusation."
Are you going to do that for me now?
I don't expect you to, because I don't think you are being dishonest. I think you are earnestly trying to untangle the facts from two parties for whom you have no bias one way or the other, which is commendable.
Like you, I am an individual attempting to paint an accurate picture of reality for my readers.
Anthropic, on the other hand, is not an individual nor trying to be accurate. They are doing exactly as they are supposed to: maximizing value for shareholders. To do this, they need to make this rewrite appear successful, so they need to retcon this idea that they were doing good engineering practices in their zig codebase the whole time, including fuzzing, even though that is not the case.
[1]: https://github.com/andrewrk/andrewkelley.me/blob/c39f868e578...
[2]: https://mastodon.social/@michael@m.mtlynch.io/11689618811296...
Dude just stop. This has been embarrassing and damaging enough to your reputation, you should just give it a rest for now. Your friends have made you self-aware enough to realize you have unprocessed emotions about this — process them. Best to get out of the comment section, and your head. The saying is if you’re explaining you’re losing. I’m not a fan of Bun or Jarred but of your Zig work. Stick to that, it’s where you serve the community best. In the future, just present the verifiable facts and you’ll be okay.
"Anthropic is actively campaigning to end software engineering" - good but are they the only ones? I do not like Anthropic after their recent locking mechanisms. I use opencode with GLM, Mimo, Qwen, and what not. I use Codex as well.
Anthropic does not need to tell me that much of software engineering is being re-written. In my opinion, the costs have crashed. I build commercial projects at 1/3rd my earlier costs. I started build everything I can in Rust and I am still doing that. My projects have only gotten more ambitious, latest being https://github.com/brainless/akar - a WIP, please don't scream at me.
Many folks have publicly said they want to keep AI agents away from their works. Good for them. I want to accelerate software engineering, something I have done passionately for 20 years, with all the agents I can use. And I make my own agents, constantly experimenting to push local llm based agents.
If engineers want to stay behind, good for them. Not everyone does. Andrew Kelly's post read like an attack, IMHO. But why care about me? I am just a farmer (https://www.instagram.com/curryhostel) who uses AI to now build ambitious software.
I’m puzzled by how many people seem to be convinced (deluded?) into believing that their productivity has been multiplied and costs have become fractional to build things, why don’t I see any of that productivity gain or cost reduction out in the world? What has become cheaper or better engineered? If you believe posts like thsi, we should be living in a golden age of prosperity, when it seems that aside from getting better lots of products and companies seem to just be getting worse? Like seriously, to a normal person, putting aside from the benefits of using LLM’s directly for the LLM user, what things in the world have gotten better thanks to this abundance and oversupply of “intelligence” that is supposedly mutiplying people’s productivity?
A lot of those products are from big companies who seem to be struggling the most. Software does not solve bureaucracy. As an indie engineer, I have absolutely no doubt what I am doing myself.
But that change does not mean my products will become popular. That is a lot beyond software. Also, the tooling is just barely 1.5 years old and people are already asking for world-changing results. All the while totally ignoring what indies are saying.
I kind of disagree that asking for world changing results is setting the bar too high, people’s claims about their personal experience are that the world changing results are already here, productivity has been multiplied and costs have been reduced by some factor, and AFAICT everyone is using these tools, with many reporting a similar experience.
The fact that people’s personal experience using the tool don’t cohere with the impact the tool has had in the world to me doesn’t suggest a slippage between how long it takes for productivity multipliers to be felt, it suggests that these tools might actually be better at delivering the perception to the user (and where relevant, the user’s manager) of increased productivity while real productivity gains are lower, or maybe zero, or maybe negative in some cases.
The key word is "already". I myself absolutely expect world changing results. But that will need time. I can only say what I know. My own experiments in building nocodo, a coding agent are 12-13 years old. Pre-LLM. I used template based code generation and related ideas. Template processors and what not. nocodo.com is with me since 2013 maybe, you can verify.
I am a software engineer, most of my experiments are on GitHub. I would not have ventured into building the UI framework before LLMs.
And this is what bothers me - people are not looking at the generated software. Indies like us are experimenting like crazy. I live far outside the tech scene, in a small Himalayan village. But I resonate so much with the experiments, the methods, harness engineering and so many other topics. I see the benefits in how ambitious my projects are becoming.
I teach an online course on coding agents as a co-mentor. 600 young professionals join each month for a 2 week course. The joy of people, who did not know much technology, when they create a simple project management software by just typing English does not lie.
We used to write software in a very different manner. The entire mental paradigm has shifted. Many of my friends and acquaintances are on the fence, still! Some are internally giving up - unable to cope with this change. But the change is happening - the tooling is only going to get better.
Give it time. That is the opinion I hold.
Interesting! I am curious to ask someone who has been working on no-code tools for so long: I've been reading about no code platforms from the 1990s, and how all of those ended up failing. The reason I've seen cited most is that the tools/platforms did not allow for enough variability to do the jobs that people wanted (without becoming a full programming language themselves). What do you think about that in the context of the past ten years, pre- and post-LLMs?
And what do you think about coding agents in the next few years? Will we see a variation in agent capabilities? E.g. a company makes and distributes a specialized coding agent for CSS, or even serving up a kind of library that's language-agnostic, since they seem to be best at translation rather than creation?
"company makes and distributes a specialized coding agent for CSS" - weird that you think this is a path because I think this is not as appreciated as it should be.
No-code has been in a poor state for many reasons. I agree that people want more generic software to be built and the platforms did not allow for enough variability. This is what being better enabled with LLMs.
I think coding agents, particularly Claude Code, makes people think that models are the key. Some people disagree. I disagree as well. I think small models with lots of deterministic code is the way. But this will not fill Anthropic's or OpenAI's pockets.
Using an LSP, for example is recent in coding agents. But if you think about it, we should have started with that. Most agents expect LLMs to know too broadly. I would instead create 40 (random number) agents - one for each language and part of the stack. This is why your CSS example is interesting. I create just an agent for the ORM related code in a Rust/Diesel based coding agent. It worked with a 4B parameter model!
People will fight over "worked" but basically what I did was create deterministic code generator for the ORM layer - schema, model and model accessor or mutator functions and then asked the tiny model to fill in the code with lots of code example straight from the official docs. It played well for many different kinds of prompts - all focused only on model related changes.
What if we create many layers of this - a higher level agent breaks human prompts into an intermediate language and then tech-stack focused agents write the code within deterministic tooling. Agents cannot read or write any file they want - they are specific to that part of the stack, linter, compiler, etc. kick in automatically.
You get the idea.
> it suggests that these tools might actually be better at delivering the perception to the user of increased productivity while real productivity gains are lower, or maybe zero, or maybe negative in some cases.
Or that the gains are in niche applications (like the GP's) that don't translate at scale.
> Like seriously, to a normal person, putting aside from the benefits of using LLM’s directly for the LLM user, what things in the world have gotten better thanks to this abundance and oversupply of “intelligence” that is supposedly mutiplying people’s productivity?
For the normal person, they now have more choice. To businesses it is an even more fierce competition. There is an illusion of productivity since everyone using LLMs can’t stop because their competitor is also moving faster with LLMs.
So everyone is so “productive” in “building” anything at the third of the cost, it also means that even the customers that the builders are selling to are also building their own solution themselves.
Customers turn into competitors faster and those in pure software are now making even less money. Except for companies in frontier AI, infrastructure and hardware.
You have a very fitting username
I am not sure if you mean good, bad or ugly but yeah this username is perhaps with me since 1998. I used to hang around in MIT, Stanford and many other Uni IRC rooms. I was this odd username from a far away city. Tim Berners-Lee once asked me about the real person behind the username. I almost shat my pants but somehow I answered.
I am sure you have a great story for your username and the blank HN profile too.
It was a tongue in cheek joke.
Looking at your profile it's clear you're heavily invested in passing the idea that "AI is going to take our jobs" as if you have some money in the game ...
Yes, I know that is how it would seem in this ultra-capitalistic world. But no. I am a believer, follower of Sci-Fi and a dreamer. I see AI as way to tear down structures - "When everyone is super, no one will be".
The next 10 years of software can either centralize power, like we have done in the 10 years past. Or, we could open up for everyone - every mom and pop business can run their business with the best software - their own workflow.
I do not believe in the systems that have led us here and I see AI as a chance to rectify. I live in rural India, by choice. I am 44 and kicking. Have a farm, dream life and a chance to bring change I have dearly wanted - true empowerment. Big Cos/SaaS have brainwashed people away from what software for people could have been. Time to change that.
Great article.
Makes me glad I still write C!
programming language creators have now fully pivoted from 'my language is faster than yours' to 'my corporate criticism is sharper than yours' and honestly it's an upgrade
All I can say is... Wow, what a clusterfuck.
Wow, it's unsafe Rust? That seems... like the worst of all worlds.
If nobody knows why the unsafe is required there's no way they'll be able to unwind it. If they can't unwind it then they're in a worse version of C (+ cargo).
Not a lot of it is unsafe, I think they said 4%?
It's practically impossible to write safe Rust when you are calling external libs written in C/C++, like they do for the Javascript engine.
Sure, but you cordon that stuff off into small, bounded unsafe surfaces. My bet is the new bun is a crashy pile of garbage if they've just translated Zig spaghetti into Rust unsafe spaghetti with an LLM. Hadn't occurred to me.
4% is a lot in my world.
IIUC that was meant as an intermediate step (which isn't uncommon), which IMO makes the translation way less exciting.
The interesting part will be whether they can transform that "mechanical Rust" into something idiomatic. I'm waiting ...
Fair, but that's also kinda like saying "we translated it to ASM as an intermediate step to C". The hard (and valuable) part is safe rust. If unsafe is everywhere, there will be abstractions that simply have to be reengineered to use safe rust. Maybe it's a way to hit the "finish line" quick in terms of using Rust but a pure unsafe translation seems almost as far away as the original Zig project.
Unsafe Rust makes me think they did this entirely because LLMs are better at Rust than at Zig, but let's see what happens next.
All right there is so much hate for this rust rewrite, but I'm going to tell everybody that people are way way underestimating how sucky the Zig codebase was.
Basically all the time people were having horrid memory leaks and stuff that they couldn't even figure out.
So yeah, I get it, people are frustrated, but stop pretending Bun was this battle tested mature thing. It was a prototype, and still is.
Switching it to Rust is understandable since they just couldn't fix the memory leaks. It was and still is in beta, because anything with memory leaks is beta.
So yeah, I understand the concern but nobody would ever use it in production anyways for a server now because of the leaks so treat it like what it is - beta software and a cool experiment.
Thanks all!
> The marketing needed to focus on how their AI was powerful enough to do this rewrite (even though it was not powerful enough to catch a use-after-free).
ding ding ding!
> The hearsay is essentially repeating what was announced publicly. Their job listing might as well have said, “now seeking applicants for total shit show”. It’s bad form for us to say this out loud.
It's a good thing to point out these unspoken truths explicitly. As people internalize the norms that make it bad form, it becomes easy to skip the mental step of acknowledging the problem. Even internally. But that quiet acknowledgement is necessary to keep oneself sane. Without it, the best case is someone steers away without good reason, at worst it leads to experienced and expressed frustration that doesn't add up and can snowball into the wrong places.
There's so much weaselling in this post. His suggested solution to Zig memory errors is to never dynamically allocate memory? I mean... come on.
He complains about the lack of motivational blog post until after the merge, but a) they aren't obliged to do that (where are all the "it's free so you can't complain" people now?), and b) they gave plenty of motivation in HN comments, the rewrite PR, etc.
I don't like the idea of AI slop code either but it seems to work at least reasonably well for porting from one language to another.
Anyone still be able to trust Bun? It looks like piece of garbage to me. Doesn’t even offer much compared to node or deno.
Rust Bun has been running Claude for some time now.
I'd be inclined to trust production code in such a large usebase.
I can’t imagine working at a company called Oven and expecting it to be a good time.
Anthropic should make their own language, and openai should follow suit.
3
The only reason we're paying attention to this is because of the drama.
The fact that rust is likely more interesting than zig (which is also interesting) is indictated by community size (and other signs like linux kernel inclusion).
The fact that anthropic is very likely overselling their timeline and max-utility for an IPO is generally well accepted as well.
Also that us tech bros are somewhat annoying is also well understood.
But who doesn't love a good street fight?
Sometimes I suspect the rust-rewrite is just a way to advertise Claude Code power.
In all my professional carrier so far, a full rewrite without reason is a recipe for disaster, see
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
This Joel Sposky article is always my northstar when I have such "temptations". My 2 cents
hey, does anyone remember when Slack wanted to replace email?
An excellent analysis. So the Bun rewrite story is full of contradictions, irrationality, and bullshit. Not that that's really a surprise at this point.
>We’re supposed to let the Tech Bros go on about how cutting corners is some genius productivity hack.
Vibecoding in a nutshell
[flagged]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
It's hardly really about Anthropic. It's about all the people who funded them, and other AI companies, who are on the campaign by funding Anthropic seeking to end a majority of life for most humans.
Because that's what it really appears to be about, preserving a rich man family's legacy so his children can live for another few generations before they over populate and humanity repeats the cycle of indefinite war, hoarding of resources, and killing to have more for yourself. I guess every rich, powerful generation though doesn't think that future will come now, so they keep manipulating their way to extracting more and more from people and stealing their way to the top.
When a majority of the population is sick, naive, and overstimulated its not hard to convince them with your propaganda that that you are on their side and that the sacrifices they make for your power are worth it. of course they don't see how their life spans, their deaths, etc were for you cause and not theirs.
Nice write-up!
I have no beef in this flight -- I don't write Zig or Rust or use Bun (other than using Claude Code which runs on Bun, but that's an implementation detail that I don't care). But the more I look at this, the more I despise Anthropic and respect the Zig foundation. One is like "we can do whatever we want because WE HAVE MONEY, what can you do about it", the other looks at things from a engineering perspective.
It will be sad if everyone buys Anthropic's hype, forget the basic engineering principles in this industry and think that AI solves every problem. Fortunately lots of people don't.
AI is still 95% useless. The Zig article is spot on
I'm with Andrew.
It was just a marketing piece. It offered many data and pretty graphics but only that, no way to attest the veracity of it.
> Anthropic is actively campaigning to end software engineering
I didn’t read further, this is just sensationalism at its crudest
What do you mean? It's literally been a significant part of their marketing.
Let’s assume their marketing argument is in good faith (it isn’t, they’re just capturing market knowing very well they won’t replace most software dev):
Where did Anthropic say that they want to “end” software development. They make it more efficient, which could lead to less software developer.
How is this “campaigning to end software engineering”? It’s an exaggeration at best, dishonest and sensationalist at worst
>Where did Anthropic say that they want to “end” software development
https://www.entrepreneur.com/business-news/ai-ceo-says-softw...
https://xcancel.com/Vivek4real_/status/2074990159783768107
If you're selling a product and you're claiming that product will replace something, it's not unreasonable to claim that you want to end that thing.
https://twitterwebviewer.com/?tweet=2048130059412844995
There's like a trillion more examples you can pick from, as we all know it's been a core part of their marketing.
> It’s an exaggeration at best, dishonest and sensationalist at worst
It is quite literally what they're CEO keeps claiming over and over, it does not get more cut and dry than that.
>Where did Anthropic say that they want to “end” software development.
https://digitalstrategy-ai.com/2026/01/23/claude-code-anthro...
This article explains what they mean by end of software engineering:
> his engineering teams rarely write code from scratch anymore. The role has shifted from creation to orchestration. Engineers now operate as “conductors”—defining high-level problems, prompting AI systems to generate implementations, then reviewing and integrating outputs.
Well I have been working like that as well but sure as hell I still consider that to be software engineering. You won’t get anywhere if you try doing this without being a software engineer. At least not very far, see how far purely vibe coded applications can get.
Can you point out exactly where it says that? As I read it, the claim is that AI boosts the productivity of writing code to the point that it's usually not productive for humans to write code directly. I think that boost only goes so far -- safety-critical code still needs to be well-understood by people, and a lot of the higher level thinking has insufficient ground truth to train AIs on it -- but it's fundamentally a claim about transforming software development rather than ending it.
Wat?
Anthropic leadership, including CEO Dario Amodei and co-founder Boris Cherny, has declared that software engineering is dead or will become obsolete within 6 to 12 months due to AI automation.
Cherny states that at Anthropic, no code is manually written anymore, with engineers using Claude Code to generate 22–27 pull requests daily and AI agents operating in autonomous loops.
https://www.reddit.com/r/BlackboxAI_/comments/1qxhqry/anthro...
very narrow vision, openai and anthropic realized what they have probably won’t lead to agi so they moved the goalposts to replacing jobs, programming just happened to be the easiest field because engineers are technical, willing to pay, and the input/output is relatively easy to measure, even that has problems though, a lot of managers are noticing that code generation is fast but actual production output doesn’t improve at the same rate, anthropic basically bootstrapped itself on coding and now they’re looking for higher paying fields that put less pressure on their servers
So much drama between all these completely irrelevant actors circling the drain.
Anthropic have lost their minds, and eventually a metric shit ton of money. Meanwhile, nobody uses Bun or Zig either. Rust continues to chug along very very slowly.
Writing the blog post took longer than the million line Rust rewrite. That is all someone with a few brain cells needs to understand what’s going on here.
When I see bullet point lists, I hit the back button. Is this just me? The smell of AI- it's like rotting vegetables.
Probably just you. I use them somewhat frequently to make it clear where a set breaks down into alternatives or parallel factors. If there's a preface and trailer around a list of complex items, I think writing the list in one paragraph is often ambiguous and hard to follow. Using a bullet list within that kind of paragraph (IMO) makes it easier to follow what I think is important.
Well, yeah, most social media posts that contain a list or a table these days are ai slop.
To me it seems as if the AI corporations declared war on software engineers in general. I understand that many software engineers have already been addicted to e. g. claude (look at github, you see tons of "co-authored" rubbishness here) but to me it is clear that the AI corporations also work against the humans here - this example of the creator of the zig language (which I don't use myself, as I dislike several design choices made) being harassed by Anthropic shows this clearly as well.
Yeah, but argumenting that "Bun codebase is a mess" is anti-Zig in itself.
The whole point of the borrow checker is to make it impossible to write wrong code. If Zig accepts bad code, but assumes people will have self-discipline to maintain it, how is that different from C?
C assumes good discipline, as well as C++. But it will happily accept bad code. So I'm not even sure what Zig is even improving on.
Rust was designed to answer this exact problem (among a few others of course).
So the argument "your code is fscking sheet" is very 1990's. In 2026 we need guarantees that we can't produce invalid code.
> The whole point of the borrow checker is to make it impossible to write wrong code.
> In 2026 we need guarantees that we can't produce invalid code.
Rust doesn't provide either of those guarantees.
If I were to rephrase your sentiment for accuracy: Rust disallows certain coding patterns. Certain classes of bugs can only appear in those coding patterns.
IOW, Rust disallows $FOO which is a superset of "specific class of errors". This means that while Rust prevents specific bugs, as a side-effect it will also prevent some correct code.
Very true. Rust prevents some good code as well.
Also it doesn't guarantee that the code is always 100% correct.
But I think this is the correct direction of programming language evolution.
The borrow checker is a good tool (and it makes Rust objectively better than Zig to me), but it unfortunately doesn't prevent writing bad code
An issue with Bun is that it interfaces with a C++ JS engine and it needs unsafe. In this case, the best practice is to write a safe binding to encapsulate this external dependency (that's why in Rust we have -sys crates with raw unsafe bindings, and other crates with a safe interface on top), and then write your business logic entirely in safe Rust
However, the Rust port of Bun didn't follow such best practices (perhaps with good SDD practices it could, not sure about that). The resulting code has literally thousands of unsafe blocks. It also contains plenty of UB. The port already costed hundreds of thousands of dollars. It's unclear if Mythos/Fable is able to refactor it further to remove unsafe usage without introducing further UB, and how much it will cost
(here It's important to note something. Rust UB is in some abstract sense harder to deal with than C or Zig UB, because it also needs to uphold the guarantees of safe Rust. If you get to write your business logic in safe Rust that's a good deal, but the price of that is that your unsafe code has extra responsibilities)
Rust requires discipline too. I can go around using Arc, Rc and .clone() everywhere without upsetting the borrow checker, I can use let mut a bunch and pretend if, match, etc. aren't expressions. This results in worse code, and Rust didn't stop me.
The borrow checker prevents a set of errors from being possible, but it doesn't prevent bad code from being written.
It would be easier for you to argument that the user is expected to have discipline to NOT use "unsafe" keyword in all functions.
Because a lot of mechanisms actually still have guards in runtime. And using .clone() on Rc/Arc is actually the idiomatic/preferred way of evading the borrow checker if we can't design the data structure in a different way.
It's a big difference between cases when you need to spend brain energy to find ways to "out-smart" the compiler, and spend brain energy to "fit into the proper set of assumptions" of a programming language.
Static memory safety is a spectrum and so is code quality.
> how is that different from C?
Zig gives you far more memory and type safety than C and without a borrow checker and a complex generics system.
Zig also allows optional runtime checks (at the cost of runtime performance).
There is no better language between Rust and Zig because they have different tradeoffs that are better or worse in different scenarios. It is more like Rust vs C++ and Zig vs C.
Most bugs are logic bugs which rust does nothing to help you with.
I disagree; Rust's type system, which supports pretty rich algebraic data types, makes it easier to specify the correct data model for your system than it would be in languages with simpler type systems like C or Python. The ability to define enum types with arbitrary shapes for each variant, and then match on them in code, allows programmers to build better, more-accurate abstractions and have less fear of screwing up and causing a logic bug.
In my experience, it absolutely does (at least if you use it idiomatically). Using the type system (esp. enums, Result and newtypes) makes a good bunch of invalid states irrepresentable.
This also helps to focus on the remaining things that could go wrong.
The integration of unit tests also lowers the barrier to just sprinkle some tests in, if you're unsure that you got an edge case right. Anf clippy (not stricly the language, but still kind of a core component) greaty helps to stay on the idiomatic track.
No silver bullet of course, but I never had so few runtime issues with any other programming language so far.
What logic bugs did you encounter the most?
edit: mobile typos
Rusts memory safety is enforced via type safety. You can enforce more than just memory safety related invariants with the same type system?
I've seen many people make this claim and it's wrong but also silly. How do you think type systems work?
This post is ultimately complaining about a build step consisting of an automatic translation from technically irrelevant language A to technically slightly less, but still substantially irrelevant language B.
I don't care what Anthropic says and what the CEOs buy, I care about my own output and the recent models give me 2x uplift easily, I'd say 10x in single digit percentage of the time and I know I'm not using them to their full potential. We're living in an era of mass produced software. You can still be an artisan in this era, but you have to be aware.