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.
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
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.
Instead, the first half of it solely consists of personal attacks.
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.
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.
For context, I'm using Codex and have no interest in either Zig or Rust, so just observing this drama from the sidelines.
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.
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.
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.
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.
I'm trying to not let this affect my thoughts about Zig as a language but it's hard.
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?
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.
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.
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’m not the one saying that their environment resulted in a buggy unmaintainable mess, Bun is the one saying that.
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.
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.
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.
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!
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...
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.
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...
- 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.
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.)
> 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.
and the rust version has been live in claude code since june 17th.
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.
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.
https://github.com/oven-sh/bun/blob/bun-v1.1.42/src/bundler/...
My take is they vibe coded too close to the sun
> 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.
> 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.
https://www.uber.com/us/en/blog/postgres-to-mysql-migration/
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
They’ve just found a way to explore that logical fallacy even faster.
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.
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.
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.
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?
The people selling shovels are the ones building data centers and energy. Tokens are the "gold".
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?
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.
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.
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.
No, they're intentionally in all the programming language markets.
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.
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.
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.
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.
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.
Jarred's post about Bun-Zig-Rust post was technical and polite.
Andrew's post in response was anything but that.
I browsed through the Bun code following Kelly's post, and decided to have Codex replace all my Bun usage with Deno.
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?
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
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.
> 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...
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.
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...
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.
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.
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.
> 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.
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.
now THAT is cynical
Huge problem with this is that typically safe, idiomatic Rust looks nothing like unsafe Rust.
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.
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.
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
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.
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.
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.
Judging from internet posts and HN comments, many do.
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.
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.
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.
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.
like linus lol
i hate marketing pr speak when it comes to technical things.
save that for the non technical customers
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.
In what world do you think they have to justify a rewrite to anyone outside their company? Bizarre mentality.
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.
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.
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!)
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.
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...
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).
…he had to resort to AI for this part.
In the meantime, most of us are just using whatever tools are at our disposal and minding our own business.
Yes, Andrew edited it. Diff here: https://github.com/andrewrk/andrewkelley.me/commit/8b86ac915...
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
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?
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.
Just like Google might sell ads on (approximately) all the websites, but they don't particularly care which website you visit.
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.
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.
there is a chance they tried..
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.
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.
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.
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.
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’s of course a tradeoff, since Rust moves more slowly than I think a lot of people would prefer.)
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.
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.
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.
That requires some proof, because the trend is that users of A apps dislike the lack of engineering that comes with AI involvement.
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
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.
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.
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.
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.
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.
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?
"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.
This premise makes no sense. AI makes rewrites to any language easy.
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.
If he doesn't want to get involved, then why even write this piece?
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.
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.
>outstanding relationships with essentially everyone who openly uses Zig and talks about it publicly
Essentially everyone? more blogposts incoming?
> 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).
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.
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.
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.
Edit to add: I'm unsure where assembly would sit in this analogy. Skateboard? Monocycle? Perhaps ice skates.
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.
> 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.
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.
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.
(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.)
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?
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.
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.
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
That would be Zig's 700 or so Codeberg issues + the 2,700 or so GitHub issues.
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.
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.”
Yes, that's the sour opinion piece full of personal attacks.
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."
Given the context, you mean Rust? Nothing against Rust folks but I wouldn't really call it more welcoming community.
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.
Sigh, there definitely an attitude creeping into the community and it's a huge turn off unfortunately.
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.
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.
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.
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.
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".
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.
'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!
Warts and ancient quirks, I can kind of see, but in what way have LLMs solved the footguns?
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.
You are the typical mark for hype cycles. Get a clue will you.
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.
> 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.
It's not even wrong.
- 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, 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 [...]
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.
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.
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.
- 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.
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.
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.
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.
And your parent is right to point out that emotionally loading posts tend to be a disservice to the message being carried.
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.
Except it is. The people using it told us.
> 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 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.
The only gain is speed.
I understand that many interpretations are open in such things, but this kind of logic seems ridiculous.
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.
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 in fact happens all the time and engine creators dont come out with bitter blog posts about it
The LLM companies have truly astounding power to now steer the direction of the entire industry. It should worry all of us.
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.
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'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.
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
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.
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.
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.
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.
It's insane that in 2026 we are still falling for these tricks really.
(I’m pretty sure both you and I would “know it when we see it”, but…)
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"
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.
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?
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
"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.
Worst of all I've seen good engineers lean in and begin thinking uncritically and magically.
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.
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.
Also, none of this is "new" or anything. Jarred openly bragged about overworking his people. Which, okay, fine, maybe that's a philosophy. But then you can't act like essentially saying your own words back at you is somehow an attack. It's just not.
People need to be more careful and understand that no, actually, you DO NOT own your perception. Your actions and words both curate your perception and, so sorry, you can't necessarily change it. It's not yours, it's ours.
1. https://www.battlefields.org/learn/primary-sources/lincolns-...
2. https://www.battlefields.org/learn/articles/abraham-lincolns...
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.
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.
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.
Does the program handle character data? It is indeed a rare server app which never handles strings.
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.
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.
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.
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)
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.
But assholes know how to get things done, they just do. If everyone becomes a bystander, then 100% of all decisions will be made by the absolute bottom of the barrel of humanity. I'm talking sub-human morally inept fundamentally evil people.
We're already kinda there, and maybe my phrasing here is harsh, but it's true. We've all seen what happens when you let the mad king be mad. It might be pleasant and peaceful for a while, but ultimately it is "your problem". Eventually the madness touches YOU, and now what?
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?
In fact we could summarize TigerBeetle as "the financial database developed like embedded software". Determinism is a cornerstone of critical software like in avionics, and naturally, dynamic allocation is forbidden, as in TigerStyle.
So even though it is not obvious, TigerBeetle represents one of Zig biggest strengths: embedded systems.
> 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?
Both needs heat.
"Technical substance" simply requires that some technically substantive things are mentioned. Which was indeed the case.
There really, truly, absolutely, 100% is no accounting for taste...
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.
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.
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
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.
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.
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.
> only works for very specific use cases.
It's not clear to me what you mean by this.
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 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.
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.
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
He then told me that it is, as you said, unfinished, and that he can't reasonably recommend it for embedded projects that are often long term and demand stability. C, a 1970 language is still king for a reason! So he is keeping Zig on his watchlist for when it becomes more mature.
Nope. I was on a Python project in 2006 and earned a paycheck doing so.
If Rust is gaining popularity because it is an alternative to C++, D-lang needs to be included into that conversation, IMO.
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.
That is such a miserably low bar
I'm not saying Andrew was right to write bitter personal attacks.
EDIT: You can't be serious people. Rust unsafe is safer than C, if for nothing else, for knowing which pointers are aliasable.
C is unsafe 100% of the time. Rust is only unsafe in unsafe{} blocks.
That's usually the case for Rust programs because the language encourages it. Are Zig programs like that?
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.
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.
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.
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 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.
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
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.
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.
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...
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?
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.
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.
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? ;)
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_...
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
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.
Just because it's better than you doesn't mean it's better than everyone else :)
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?
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.
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.
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.
Compare Cloudflare, the Google Chrome Security blog, etc.
(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.)
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.
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.
Granted we "aren't modules" yet, unless being on latest compilers with msbuild/cmake/ninja tooling.
As in, they did not, which I can prove by using Miri and seeing hundreds of errors.
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.
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.
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.
I wouldn't say "definitely", given Rust deps management is way more streamlined.
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.
That's true also if we see the impact their (and other frontier AI) tools have on employment and development practices.
Consider just having a typechecker. That alone eliminates a whole class of bugs and unit tests, which means your remaining unit tests check more logic. I've seen JS projects with high test coverage that cover essentially zero logic, only type checking class things. And nobody even knows it, really. But when your tests are just "okay pass an empty array. Now an empty string. This should fail, great. Now pass an array with the wrong elements..." you're not testing anything. You're probing the type system, which many languages do automatically and perfectly.
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.
And he didn't "expose" anything but gossip.
I'm just not following the logic at all.
We build vastly more ambitious software today than we did in the 80s
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.
http://www.catb.org/~esr/writings/taoup/html/end-user.html
"""Master Foo turned to the end-user. “Tell me”, he inquired, “why do you seek the Way?”
“I am discontent with the software I see around me”, the end user replied. “It neither performs reliably nor pleases the eye and hand. Having heard that the Unix way, though difficult, is superior, I seek to cast aside all snares and delusions”."""
You'll get the exact same muscle loss with a CICO calculation weight loss.
This is all friction that is intended to make car-driving work at scale.
As of this moment, even with all the new evidence being provided on Bluesky / mastodon, it doesn't amount to anything.
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,
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 workA 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.
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).
> 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.
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.
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.
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.
But to your larger point I would much rather work on improving that than let it drive me back to C fetishism.
And how does Miri help solve this issue?
> [what you just wrote]
So they gained nothing from a Rust rewrite, except introducing more bugs into their shit codebase.
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)
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.
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.
Meanwhile, years later Vlang still have not delivered on the initial claims that made the language even remotely interesting.
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.
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.
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.
By the engineer's wit of course!
> And how does Miri help solve this issue?
By detecting undefined behavior caused by violation these rules
Can you point to an equal number of issue tracker tickets showing novel bugs or regressions in the canary build?
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.
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.
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.
We often ensure a project holds water against miri. This one doesn't even pass for clippy.
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?
(Surely a relatively bland technical criticism of Zig - one that gets couched with praise - does not count as “a big fuss.”)
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.
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.