ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
58% Positive
Analyzed from 8741 words in the discussion.
Trending Topics
#zig#rust#bun#code#language#post#anthropic#don#andrew#software
Discussion (172 Comments)Read Original on HackerNews
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.
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.
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.
Zig has 110 open "segfault" issues [1] versus Rust's 175 open "segfault" issues [2]. So, by your logic, Rust is also bad.
[1] https://codeberg.org/ziglang/zig/issues?state=open&type=all&...
[2] https://github.com/rust-lang/rust/issues?q=is%3Aissue%20stat...
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.
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.
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.
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!)
and the rust version has been live in claude code since june 17th.
They’ve just found a way to explore that logical fallacy even faster.
People did this also before LLM, but the difference is that now the prototype is a fully functional product in the technical sense whereas before it was little more than a glorified Hello World. The human effort and calendar time used remains roughly the same.
There's gonna be amazing products made with LLM, but it'll take some time. Not as long as it did before, but still significant time.
Rel: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
It's not better, it's worse given the average bear's assumption about a rust project.
You are acting like they need to complete everything at once...why?
Bun (rust) is not even released as stable yet and getting extensive usage on Claude code. They are making improvements and fixes. So what's the issue here?
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.
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.
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.
Does that include Claude itself? Half joking aside, my main concern remains that both OpenAI and Anthropic practice this fear mongering as strategy at the executive level because they have to. A corporation is a different beast. Not human, exactly. Not AI either. What happens when a corporation starts being informed by the AI it is building?
If you want a lens into master craft corporate human slung bullshit, read this: https://www.theverge.com/podcast/944138/microsoft-ai-ceo-mus...
In this, not only did the interviewer admit he knew Suleyman had written about the issues he talks about in his rebuttals, he then says he's only asking (the hard question) because the "audience" wants it.
Suleyman's response talks about taking "accountability for the things that we build" and the "types of problems that we choose to work on," it highlights the fundamental flaw in the cloud-rented AI model.
In that ecosystem, "we" means a handful of corporate executives deciding what tools the rest of the world gets to use, how they operate, and what data they extract. All based on the profitability of the corporation. It is the absolute antithesis of a sovereign architecture where execution happens locally and the user dictates the terms of the system.
They are coming for open models. It's time to harden the gates.
For context, I'm using Codex and have no interest in either Zig or Rust, so just observing this drama from the sidelines.
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.
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."
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.
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.
Incredible the different takeaways people get from text content on the internet. I'd say it'd be more like if you moved from Unity to Unreal and then Unity made a blog post saying they were happy about you moving to Unreal, publishing they think it'd be a win-win, then outlining why they think so.
It is incredible isn't it.
"Jarred was already writing slop well before he had access to LLMs"
"The grapevine was large and healthy and full of juicy grapes, and all those grapes contained the juice of the same message: Jarred was a stinky manager. Poor communication, unrealistic expectations, low empathy, no experience. Just a total shit show, from an employment perspective."
"at some point they would sell out (let's be honest, their vague "sell some cloud something" business plan was a farce from the get-go"
"he was essentially groomed from a young age into uncritically embracing the Silicon Valley mindset"
There is more but I'll stop quoting to not end up copying the whole thing.
I mean, that makes it all sound very polite and dispassionate, but Andrew's piece was anything but. I have no dog in this fight, I don't use Zig, Rust, Bun or Claude, and initially I thought the bun rewrite sounded like a terrible idea. I changed my mind after reading the piece about the migration - it was very interesting and the process was obviously quite thoughtful. Andrew's piece made me want to take a shower afterwards.
Yeah, exact words you would expect from someone who is happy about a win-win situation.
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.
Edit to add: I'm unsure where assembly would sit in this analogy. Skateboard? Monocycle? Perhaps ice skates.
I browsed through the Bun code following Kelly's post, and decided to have Codex replace all my Bun usage with Deno.
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.
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.
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.
Jarred's post about Bun-Zig-Rust post was technical and polite.
Andrew's post in response was anything but that.
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.
No, they're intentionally in all the programming language markets.
Just like Google might sell ads on (approximately) all the websites, but they don't particularly care which website you visit.
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.
I mean, they did buy a JS runtime, so surely they must care more about JavaScript and TypeScript than other languages, right? Otherwise that move makes 0 sense.
Maybe this part from their marketing post about the acquisition is just a straight up lie I suppose?
> Together, we’ll keep making Bun the best JavaScript runtime for all developers [...]
Anthropic'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.
Not sure; it has some elements of personal issues, but they're followed by a rationale from the author.
Honestly, seeing the project lead (Andrew Kelly) take a stand against poor engineering practices without any equivocation makes me more inclined to want to use Zig - their values (in this regard, at least) align with mine.
He also substantiates what many of us are saying to all these "Very Senior Chief Engineer with 40 years experience" who are boasting of 10x productivity: these people aren't reading the code they are generating, and were producing slop even without AI.
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.
Insane that people + tokens are slobbering to rush to Clownthropic’s defense when the whole migration and subsequent blog post was just sour grapes about the Zig project’s no slop policy.
And this is a warning shot from Anthropic intended to have a chilling effect, we have tens of billions of dollars at our disposal and if you take any stance we don’t like that undermines our narrative we will fuck with your shit and throw billions of dollars of muscle at rewriting you or trying to make you irrelevant.
I read both posts, and didn’t leave the Bun one with a negative opinion of Zig. But I did leave the response post with that opinion.
I knew it was gonna happen at one point, guess I didn't believe it'd happen so soon, but I still can't believe that nowadays people make choices about what programming language to used based on what semi-celebrity they like the most, and it's all about emotional arguments. What happened and since when is this the way people make technical choices? I feel like I woke up in an alternative universe.
BTW the rhetorical device of misrepresenting what someone else says as something much weaker or incorrect and then arguing with that is usually called “strawmanning”. Just thought I’d point that out to you in case you weren’t conscious that this is what you’re doing.
> We wouldn't have gotten this far if not for Zig, and I'll always be grateful. Until very recently, programming language choice was a one-way decision for a project like Bun.
https://bun.com/blog/bun-in-rust
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.
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
If he doesn't want to get involved, then why even write this piece?
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.
Maybe people were more interested in the agentic part more than the actual rationale for the port in the first place, because it was very disappointing from a technical standpoint.
Did we read the same article? I mean it wasn't talking about a specific line of code, but it had deep architecture details, rational for memory safety and bugs, agentic coding patterns for scale. It was full of substance, multiple times.
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.
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.
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.
Now the Zig community is attacking one of the largest and best-known codebases ever built with the language. Anthropic’s motives are clearly promotional, but even so, I would not choose Zig for any project.
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 trying to not let this affect my thoughts about Zig as a language but it's hard.
Judging from internet posts and HN comments, many do.
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.
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.
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.
> 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.
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...
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.
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.
https://www.uber.com/us/en/blog/postgres-to-mysql-migration/
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?
In the meantime, most of us are just using whatever tools are at our disposal and minding our own business.
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.
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 don't care what Anthropic says and what the CEOs buy, I care about my own output and the recent models give me 2x uplift easily, I'd say 10x in single digit percentage of the time and I know I'm not using them to their full potential. We're living in an era of mass produced software. You can still be an artisan in this era, but you have to be aware.
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.
It was just a marketing piece. It offered many data and pretty graphics but only that, no way to attest the veracity of it.
And I think the only sensible backend languages when starting a new for-profit project is Python, Go, and Rust for 99% use-cases.
In other cases, third-party packages, tooling, integrations, and telemetry starts to suffer.
Specially if their community and their BDFL continues to be welcoming and fun to interact with.
Their 1.0 roadmap announcement is cool: https://youtu.be/dLPAqXi9In0
Here's most of the language in a single demo file: https://odin-lang.org/docs/demo/
If nobody knows why the unsafe is required there's no way they'll be able to unwind it. If they can't unwind it then they're in a worse version of C (+ cargo).
It's practically impossible to write safe Rust when you are calling external libs written in C/C++, like they do for the Javascript engine.
The interesting part will be whether they can transform that "mechanical Rust" into something idiomatic. I'm waiting ...
Life would be paradise if people were just good for each other. They are not though. So you need a system for that case. Rust is a system that fits the modern real world software development dynamics than Zig.
I commented on Mastodon[2] to point out to Kelley that it's dishonest to silently remove the accusation, as so many people were already talking about it, and it confuses the conversation if Kelley retroactively edits it, and he replied[3]:
> the false claim is in the bun blog post not mine. I only changed the text because it's easy to lazily argue against it. Please read more carefully. They are the ones being deceitful not me.
Loris Cro, Zig's VP of Community, gave a slightly clearer response[4]:
> Jarred's post has a section about what they "were already doing" to maintain their Zig codebase, which includes "24/7 fuzzing", which will make the average reader assume that the codebase has been fuzzed thoroughly, while in reality it has been for, what, 2 months before the rewrite?
Even then, I find it so bizarre that Loris thinks that if someone says, "We've been fuzzing Bun," and shows evidence of months of fuzzing, then that person is lying because "We've been fuzzing Bun" somehow implies something longer than two months.
The duration is irrelevant. If you say you've been fuzzing it and you've fixed bugs that your fuzzer found, then clearly you're fuzzing. The Zig team doesn't get to arbitrarily move the goalposts of what "fuzzing" means.
[0] https://news.ycombinator.com/item?id=48845652
[1] https://news.ycombinator.com/item?id=48854921
[2] https://m.mtlynch.io/@michael/116896188093796421
[3] https://mastodon.social/@andrewrk/116897155344411469
[4] https://hachyderm.io/@kristoff/116898483283387067
If you read the post again this sentence is not removed and Sumner did not refute that
If Sumner says today, "We do X," then Kelley can say, "Nine months ago, Sumner did not do X," and both can be correct. What Kelley can't do is say, "It's an outright fabrication that Sumner does X today," based on an observation from nine months ago.
Anthropic does not need to tell me that much of software engineering is being re-written. In my opinion, the costs have crashed. I build commercial projects at 1/3rd my earlier costs. I started build everything I can in Rust and I am still doing that. My projects have only gotten more ambitious, latest being https://github.com/brainless/akar - a WIP, please don't scream at me.
Many folks have publicly said they want to keep AI agents away from their works. Good for them. I want to accelerate software engineering, something I have done passionately for 20 years, with all the agents I can use. And I make my own agents, constantly experimenting to push local llm based agents.
If engineers want to stay behind, good for them. Not everyone does. Andrew Kelly's post read like an attack, IMHO. But why care about me? I am just a farmer (https://www.instagram.com/curryhostel) who uses AI to now build ambitious software.
But that change does not mean my products will become popular. That is a lot beyond software. Also, the tooling is just barely 1.5 years old and people are already asking for world-changing results. All the while totally ignoring what indies are saying.
The fact that people’s personal experience using the tool don’t cohere with the impact the tool has had in the world to me doesn’t suggest a slippage between how long it takes for productivity multipliers to be felt, it suggests that these tools might actually be better at delivering the perception to the user (and where relevant, the user’s manager) of increased productivity while real productivity gains are lower, or maybe zero, or maybe negative in some cases.
For the normal person, they now have more choice. To businesses it is an even more fierce competition. There is an illusion of productivity since everyone using LLMs can’t stop because their competitor is also moving faster with LLMs.
So everyone is so “productive” in “building” anything at the third of the cost, it also means that even the customers that the builders are selling to are also building their own solution themselves.
Customers turn into competitors faster and those in pure software are now making even less money. Except for companies in frontier AI, infrastructure and hardware.
And this whole thing reeked of a publicity stunt. Show people you can use $$$ of tokens to vibe code a refactor. The headline is how great anthropic - bun's owner - is.
Anthropic have lost their minds, and eventually a metric shit ton of money. Meanwhile, nobody uses Bun or Zig either. Rust continues to chug along very very slowly.
It's a good thing to point out these unspoken truths explicitly. As people internalize the norms that make it bad form, it becomes easy to skip the mental step of acknowledging the problem. Even internally. But that quiet acknowledgement is necessary to keep oneself sane. Without it, the best case is someone steers away without good reason, at worst it leads to experienced and expressed frustration that doesn't add up and can snowball into the wrong places.
The whole point of the borrow checker is to make it impossible to write wrong code. If Zig accepts bad code, but assumes people will have self-discipline to maintain it, how is that different from C?
C assumes good discipline, as well as C++. But it will happily accept bad code. So I'm not even sure what Zig is even improving on.
Rust was designed to answer this exact problem (among a few others of course).
So the argument "your code is fscking sheet" is very 1990's. In 2026 we need guarantees that we can't produce invalid code.
An issue with Bun is that it interfaces with a C++ JS engine and it needs unsafe. In this case, the best practice is to write a safe binding to encapsulate this external dependency (that's why in Rust we have -sys crates with raw unsafe bindings, and other crates with a safe interface on top), and then write your business logic entirely in safe Rust
However, the Rust port of Bun didn't follow such best practices (perhaps with good SDD practices it could, not sure about that). The resulting code has literally thousands of unsafe blocks. It also contains plenty of UB. The port already costed hundreds of thousands of dollars. It's unclear if Mythos/Fable is able to refactor it further to remove unsafe usage without introducing further UB, and how much it will cost
(here It's important to note something. Rust UB is in some abstract sense harder to deal with than C or Zig UB, because it also needs to uphold the guarantees of safe Rust. If you get to write your business logic in safe Rust that's a good deal, but the price of that is that your unsafe code has extra responsibilities)
> In 2026 we need guarantees that we can't produce invalid code.
Rust doesn't provide either of those guarantees.
If I were to rephrase your sentiment for accuracy: Rust disallows certain coding patterns. Certain classes of bugs can only appear in those coding patterns.
IOW, Rust disallows $FOO which is a superset of "specific class of errors". This means that while Rust prevents specific bugs, as a side-effect it will also prevent some correct code.
Also it doesn't guarantee that the code is always 100% correct.
But I think this is the correct direction of programming language evolution.
The borrow checker prevents a set of errors from being possible, but it doesn't prevent bad code from being written.
Because a lot of mechanisms actually still have guards in runtime. And using .clone() on Rc/Arc is actually the idiomatic/preferred way of evading the borrow checker if we can't design the data structure in a different way.
It's a big difference between cases when you need to spend brain energy to find ways to "out-smart" the compiler, and spend brain energy to "fit into the proper set of assumptions" of a programming language.
I've seen many people make this claim and it's wrong but also silly. How do you think type systems work?
This also helps to focus on the remaining things that could go wrong.
The integration of unit tests also lowers the barrier to just sprinkle some tests in, if you're unsure that you got an edge case right. Anf clippy (not stricly the language, but still kind of a core component) greaty helps to stay on the idiomatic track.
No silver bullet of course, but I never had so few runtime issues with any other programming language so far.
What logic bugs did you encounter the most?
edit: mobile typos
I didn’t read further, this is just sensationalism at its crudest
Where did Anthropic say that they want to “end” software development. They make it more efficient, which could lead to less software developer.
How is this “campaigning to end software engineering”? It’s an exaggeration at best, dishonest and sensationalist at worst
https://www.entrepreneur.com/business-news/ai-ceo-says-softw...
https://xcancel.com/Vivek4real_/status/2074990159783768107
If you're selling a product and you're claiming that product will replace something, it's not unreasonable to claim that you want to end that thing.
https://digitalstrategy-ai.com/2026/01/23/claude-code-anthro...
Anthropic leadership, including CEO Dario Amodei and co-founder Boris Cherny, has declared that software engineering is dead or will become obsolete within 6 to 12 months due to AI automation.
Cherny states that at Anthropic, no code is manually written anymore, with engineers using Claude Code to generate 22–27 pull requests daily and AI agents operating in autonomous loops.
https://www.reddit.com/r/BlackboxAI_/comments/1qxhqry/anthro...
ding ding ding!