I think bun is moving to rust because Anthropic owns it and the devs there like rust. So why would they invest in another implementation? Sad to see a good zig example go, but as soon as Anthropic bought it I wrote the project off.
I am not aure either, but bun wasn't using normal zig and there was drama about upstreaming. Combine that with anthropics desire to show they can help rewrite everything in rust and that probably accounts for some of it.
Bun has de-facto refused to use incremental compilation in Zig for ages. It got to the point where Jarred somehow seems to have forgotten that the feature exists.
In any case Bun has already committed to the Rust slop switch, so it doesn't matter anymore.
bun seems to be committed to slop rust already. so, with their ethic, maybe we should just disassociate them from zig and let them go realize their slop dreams?
zig is on its way to improving compilation times in its own pace and does so for the benefit of the project and everyone involved, so what is left to care for about bun by anthropic’s past?
I bet they'll ultimately reverse course on this, or the there will be a bun / zig fork becomes the de facto bun. Despite what the influencers say, I'm convinced you cannot vibe code a conversion this big. It will need a ton of human intervention. And for brand narrative reasons, Anthropic won't commit to such a path.
It depends on how thorough the test infrastructure is I think. Something like curl with its immaculate tests could probably get autonomously ported if you threw infinite tokens at it because you have deterministically defined what finished looks like. But I think you are likely right in this case.
> bun seems to be committed to slop rust already. so, with their ethic, maybe we should just disassociate them from zig and let them go realize their slop dreams?
Closing your eyes and pretending a problem does not exist is the a good solution. The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad that they opted to rewrite their entire 1M LOC project into a different language. This is a nightmare scenario for most companies, and will motivate similar sized companies/project to pick another language that will not require this than to risk using Zig. Also, Zig’s flippant attitude about Bun’s request (among other viewpoints) only further adds to why bigger projects would want to stay away from Zig.
> The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad that they opted to rewrite their entire 1M LOC project into a different language.
That is not the fact of matter. The fact is it got bought by Anthropic. And in larger scheme of things Bun is one example Claude capabilities of translation. And even if doesn't work, it just a part of Claude desktop stack so still have millions of installs.
Not really, if it doesn’t work then it will hurt their flagship desktop app’s stability, which would negatively affect their placing in an already cutthroat AI arms. Claude Code is the few business asset that Claude has the least moat compared to other providers( even open source). They can’t afford to be sloppy and use a buggy JS engine.
Huh, I don't know which world you live in. In my world trillion dollars companies regularly release absolute crap of the software that hardly affects their industry usage or popularity.
In case anyone is not following the AI tool's biggest growth is in enterprises. And usability, quality or stability is measured very differently there compared to individual users. In my last 20 years of experience of using enterprise software and tools being third rate is never any issue.
I don't remember where it was said first, but I think the problem was not "AI drama" or that zig doesn't have "a good solution". It was more a mismatch between Bun's & Zig's goals. Bun wants to move fast & break things, even more now after getting acquired, but Zig punishes that. Zig requires you to handle everything carefully, there's no GC or big runtime to let you "break things", zig will let you just segfault.
Companies like TigerBeetle can and will benefit from zig's model.
But this goes to my second point; it seems like Zig wasn’t open to any compromise about the solution that Bun submitted and one they built in house. Is it the Zig culture to reject a pull request like that wholesale? It’s really odd for them to have such a flippant attitude and not to even try offer ways that they could use the pull request or things that they need to tweak to make it more inline with what they want. Companies want to use languages that have a understanding committee, and are willing to work together to create solutions, not just say “No, this isn’t what we want, and we are building a similar system anyway so don’t even bother to try again”. It just looks unprofessional.
A large, complex, unasked for PR is pretty likely pointless to throw at any serious project. (Well, it's pointless if your goal is to merge something.)
Working together is a two-way process. To land a big change, the bun people probably needed to have been working/coordinating with the zig people throughout. E.g., zig outright cannot accept PRs that break the language in unplanned ways and any conflicts with the roadmap would need to be resolved.
I would assume the bun people know all this. That makes it more of a publicity stunt than a serious attempt to contribute to zig, and we should probably all treat it that way.
Of course, and it is expected that large pull requests/RFCs are iterated on. I will not believe Bun seriously asked for a pull request to be merged with absolutely no expectation of back and forth discussion. But this isn’t what happened. The whole reason everyone thought it was rejected by Zig because Bun used LLM to generate it was because they responded in a way that someone would if they didn’t want a certain pull request accepted under any circumstances. Which is my point; it I just insane that their largest project submitted a pull request, and they just rejected it with prejudice, gave some statement saying the real and potentially fixable reasons why, then turn around and say we don’t want your help, we are doing this in house.
My interpretation of what they said is closer to “we already improved compilation speeds by 4x and we did it without compromising our plans to go much further - also this PR introduces specific timing bugs.”
Compromising on project goals just because someone with somewhat different goals made a pull request doesn’t exactly scream responsible and professional to me. The way I understand it, many people appreciate Zig because it’s very consistent and restrained about the kinds of problems it’s trying to solve and how, so being very careful with accepting complex, externally developed solutions seems perfectly in character for the language.
I’m not sure how well the Zig developers have handled their communication, so perhaps there really was room for improvement there.
"Therefore, to implement this feature without an avalanche of bugs and inconsistencies, we need to make language changes."
"Put more simply, we are going to make these enhancements, but hacking them in for a flashy headline isn’t a good outcome for our users. Instead we’re approaching the problem with the care it deserves, so that when we ultimately ship it, we don’t cause regressions."
"So instead of wasting time writing a more robust implementation of this LLVM module splitting logic for a relatively minor improvement, we have instead put that effort towards features like self-hosted backends and incremental compilation, which can improve compilation speed by orders of magnitude.
[...]
There’s the 4x speedup claimed by the Bun team, already available on Zig 0.16.0!"
> The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad
It's unlikely to be just a devex issue. The fact of the matter is that a memory unsafe language is an extremely tough sell today, and companies that have a security team at all have likely already made or are planning on making policies like https://chromium.googlesource.com/chromium/src/+/master/docs...
There's a reason "rewrite it in Rust" was a meme long before LLM coding tools or this Bun drama. With AI accelerated fuzzing techniques and similar, memory safety is rapidly going to become a basic requirement of anything run in a production environment.
Reviewing code was also a big bottleneck. With lot more untested code where authors don't care about reviewing their own code it will take even more toll on open source maintainers. Code quality between side projects and open source projects are different. Ensuring good code quality enables long term maintenance for open source projects that have to support the feature through the years as a compatibility promise.
That's where pair programming came in but it turns out that most people hate each other so much that they'd rather work with a machine pretending to be a person.
I realize there are many levels to this claim but I'm not being sarcastic at all here.
Not really, LLMs do not push back on design decisions and will happy continue with whatever prompt you throw at them. That’s after we look past quality isssues.
It could push back more, true. Although it's role in pair programming is the driver, you are the navigator. I often begin a session with exploring and asking it questions of the code as I would a junior developer.
Not sure how to respond to this as clearly that's what I was getting at. Perhaps this is a response from an LLM though. Again, not being sarcastic, it just seems like it's maybe the case?
you make a good point and everything but have you considered the way people using LLM is similar to the way we review code together as humans? but if you think about it, they just swapped one of the humans with an LLM
Pair programming is exhausting to a lot of people, myself included. My brain just doesn't work like that. I work in fits and starts, with weird, sustained bursts of productivity.
It's exhausting to me too! But when you do it every day you get used to it. You also get a lot more done so last time I did it we would work shorter days.
I like to agree as sorta yes but also really no because it's a rubber ducky that doesn't give you the chance to come to your own conclusion and even if it does it has you questioning it.
Yeah, this. Every conversation inevitably ends with "you're absolutely right!" The number of "you're absolutely right"s per session is roughly how I measure model performance (inverse correlation).
Thanks, any idea what the “leet” Python version listed at the very top right of the first chart linked to below, which was in one of the links you provided; attempted to Google it and found nothing.
Direct link to the chart, see “133.7” Python version (elite version) in the top right:
https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
reply