Hacker News Reader

Comment by cyber1 | Hacker News Reader

To me, this whole effort of rewriting Bun from Zig to Rust looks like a big marketing move. The question is: if Anthropic AI is really that powerful, why not just fix the bugs and give it the more ambitious task of redesigning the existing Bun Zig codebase in a way that eliminates not only the current bugs but also prevents similar ones from happening in the future?

View on HN

The sole reason for that rewrite was Zig creator announcing he won't be accepting AI contributions. It hurt Anthropic's feelings.

[citation needed]

Citation that this was the reason or citation that he said that?

For the latter: https://youtu.be/iqddnwKF8HQ?si=cvU8Fh3ah7ZCxg3M

From 26:38

Here[0] are other reasons besides AI

- [0] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...

I think that post highlights a difference in philosophical approach to software development. Bun is focused on moving fast and will deal with the consequences as they come. Zig takes a more planful approach.

I've experienced both in my career and I fall solidly on the planful side. It's why stopped using homebrew and I've avoided huggingface packages as much as possible.

What are you using instead of Homebrew?

MacPorts

Conversely we have actual evidence of Bun rewriting in Rust because Andrew wouldn't accept AI contributions, actually hurt Andrew's feelings.

Not really. It seems like the Rust rewrite blog post triggered this. Which, even though I don’t agree with the tone, seems to be valid criticism.

But Rust is exactly the tooling that gives humans and LLMs a lot of those checks for free, and things like RAII.

If you use Rust the way it was designed to be used, rather than relying on countless "unsafe" blocks, you need to redesign the entire codebase architecture to make it compatible with the borrow checker rules.

The borrow checker really isn't that bad. It isn't like they were porting from something with GC. They were already having to think about these things anyway. Even then opus seems to have no difficulty going between c# and rust while respecting the idioms of both. No unsafe needed. Zig should be even easier except the lack of a training corpus for whatever frankenversion of zig that bun was using.

Even if you “rely on countless unsafe blocks”, unsafe is additive, it gives access to additional APIs which are not checked. It does not disable affine types, the borrow checker, or send/sync traits. Unless the entire codebase is unsafe (e.g. fresh out of c2rust) it’s very hard to not have more guarantees.

And because unsafe is generally highly local or localizable reasoning (conventionally backed by safety justifications) it really is quite reasonable to go plugging at it, or task an AI within that.

For 99.99% of cases, you're reading and writing this under an operating system whose kernel is written in a language without send/sync, and inside a browser that also largely written in languages without send/sync, because those systems are fundamentally well designed. So instead of fixing the bugs and rethinking the architecture, the author of Bun decided to transpile almost the entire codebase from Zig to Rust without a deep architectural review. Okay...

Those systems you're alluding to received ungodly amounts of work and resources, vastly more than most projects can ever hope for, and yet they're still full of holes and security exploits. You're unwittingly making a great argument against using C, C++ – or Zig.

What I mentioned is only a tiny part of the entire software, which has been successfully written in C, C++, and now in Zig as well, and is used daily by people around the world.

Those systems are primarily written in C or C++-but-in-C-style, right? Without exploiting RAII among other features, as Jarred mentioned that he liked in Rust. While Rust took RAII from C++.

All that unsafe does in these cases is enable the "unsafe super-powers" which the compiler can't check, thus shifting the responsibility onto the author. But for example if you've got some code which doesn't borrow check, and you just sprinkle unsafe keywords on it, now you've got code which still doesn't borrow check and diagnostics telling that this unsafe keyword was futile and you should remove that.

I haven't reviewed this code, but the percentages described don't sound like they'd need a huge architectural overhaul to use much less unsafe, it might take more actual human effort than they want though.

It seems they’ve already done analysis over what unsafe usage they can get rid of after the port.

https://bun.com/bun-unsafe-audit

If you are writing in C-like codebase and aren't tracking lifetimes and ownership at least as well as a borrow checker you're opening yourself to CVEs.

The concept of lifetimes was invented long before Rust borrow checker was even "scratched on paper." Of course, people who understand what they are they doing have known about these concepts for decades and have built their architectures around them. However, Rust borrow checker is much stricter than that. You have to build your architecture around the fact that you can't have more than one mutable reference at a time, and your data structures have to be represented as directed, acyclic graphs, etc. If you have to break all these rules by using a lot of unsafe because it's too difficult to represent your system within Rust safe subset using only value semantics and borrow-checked references, etc, then why use Rust instead of C++, C, or Zig?

Where did I say Rust's borrow checker predates lifetimes?

I'm saying you have to be as meticulous as a borrow checker. Not as strict, of course, but you have to analyze each pointer, how and when it's used, and then cross-reference with the documented lifetime.

Just like thread safety existed before Rust made it explicit. Now you don't need to investigate if data is thread safe if it's `Send + Sync`.

This is a job humans suck at and compilers excel at. With some caveats. There will be edge cases that will need to be manually proven.

I do wonder to what degree this weird play originated from Anthropic, versus from an overeager founder selling past the close.

I can imagine Anthropic wanting to acquire Bun without the gimmicks.

IMHO 'marketing' as a supposed incentive is too easily thrown around by people who probably don't know what marketing really is.

It is worth noting that before rewriting in Rust, Bun maintained a fork used to accelerate the compilation and informed those who asked that this fork could never be merged due to Zig's zero-LLM policy.

A few weeks later, Bun began the Rust rewrite. Although not explicitly stated, I suspect these two events may be related.

As was mentioned countless times here on HN, the fork didn't get merged not because of any no-AI policy but because the Zig maintainers considered it to be of poor quality and were already working on more comprehensive improvements to the compiler which would bring the same (and more) benefits, but without the downsides and quality issues of the fork.

zig doesn't accept ai written code

How is Bun codebase connected to Zig codebase?

You can't do "redesigning the existing Zig code in a way that eliminates not only the current bugs but also prevents similar ones from happening in the future" without actually changing Zig itself.

Why?

Rumor has it there is a HN submission on the frontpage right now about that very thing:

https://news.ycombinator.com/item?id=48843352

"effort" is a big word to describe typing out a few prompts to create something with 5k+ open issues.

"Typing out a few prompts" does not match the process described in Jarred's article. https://bun.com/blog/bun-in-rust

Static guarantees are better than stochastic parrots. A static linger beats telling Claude "check this idiom". Etc etc.

Well either Claude cannot fix those bugs or it can but the Bun team decided to not fix those bugs on purpose.

Not sure which is worse.

Reply on news.ycombinator.com