| ▲ | cyber1 3 days ago |
| 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? |
|
| ▲ | dwdz 3 days ago | parent | next [-] |
| The sole reason for that rewrite was Zig creator announcing he won't be accepting AI contributions. It hurt Anthropic's feelings. |
| |
| ▲ | andrew_ 3 days ago | parent | next [-] | | Conversely we have actual evidence of Bun rewriting in Rust because Andrew wouldn't accept AI contributions, actually hurt Andrew's feelings. | | |
| ▲ | geraneum 3 days ago | parent [-] | | 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. |
| |
| ▲ | jorisw 3 days ago | parent | prev [-] | | [citation needed] | | |
|
|
| ▲ | Tiberium 3 days ago | parent | prev | next [-] |
| But Rust is exactly the tooling that gives humans and LLMs a lot of those checks for free, and things like RAII. |
| |
| ▲ | cyber1 3 days ago | parent [-] | | 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. | | |
| ▲ | galangalalgol 3 days ago | parent | next [-] | | 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. | |
| ▲ | tialaramex 3 days ago | parent | prev | next [-] | | 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. | | | |
| ▲ | masklinn 3 days ago | parent | prev | next [-] | | 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. | | |
| ▲ | cyber1 3 days ago | parent [-] | | 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... | | |
| ▲ | adwn 3 days ago | parent [-] | | 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. | | |
| ▲ | iigijshaba 3 days ago | parent | next [-] | | 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++. | |
| ▲ | cyber1 3 days ago | parent | prev [-] | | 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. |
|
|
| |
| ▲ | Ygg2 3 days ago | parent | prev [-] | | 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. | | |
| ▲ | cyber1 3 days ago | parent [-] | | 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? | | |
| ▲ | Ygg2 3 days ago | parent [-] | | 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. |
|
|
|
|
|
| ▲ | rao-v 3 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | jorisw 3 days ago | parent [-] | | IMHO 'marketing' as a supposed incentive is too easily thrown around by people who probably don't know what marketing really is. |
|
|
| ▲ | ofseed 3 days ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | codethief a day ago | parent [-] | | 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. |
|
|
| ▲ | advenn 3 days ago | parent | prev | next [-] |
| zig doesn't accept ai written code |
| |
|
| ▲ | bramhaag 3 days ago | parent | prev | next [-] |
| "effort" is a big word to describe typing out a few prompts to create something with 5k+ open issues. |
| |
|
| ▲ | andrepd 3 days ago | parent | prev | next [-] |
| Static guarantees are better than stochastic parrots. A static linger beats telling Claude "check this idiom". Etc etc. |
| |
|
| ▲ | pier25 3 days ago | parent | prev [-] |
| 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. |
