Bun is moving towards rust but does this also help bun's compilation times?
https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
That said, I hope that Zig posts won't be plagued by "but the bun thing" like this in the near future.
In any case Bun has already committed to the Rust slop switch, so it doesn't matter anymore.
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?
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.
Companies like TigerBeetle can and will benefit from zig's model.
I’m not sure how well the Zig developers have handled their communication, so perhaps there really was room for improvement there.
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.
There's no value to iterating on a PR when the approach itself is not right.
"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!"
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.
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.
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.