How much of an architectural change does the borrow checker require? It feels to me like a pretty central part of Rust, and you can't just translate all the files one to one, then refactor out the unsafe blocks, it might need a full think through and project analysis to make it actually work with rust, instead of being forced into rust
Bun has been converted to rust. Now what?
31–40 of 113 posts
Re: Bun has been converted to rust. Now what?
#32Deno was already implemented in Rust, and not done by vibe-coding. Would you trust a fully vibe-coded runtime? Not some features, not some fixes, but a full translation from one language to another.
[dead]
Re: Bun has been converted to rust. Now what?
#33Deno was already implemented in Rust, and not done by vibe-coding. Would you trust a fully vibe-coded runtime? Not some features, not some fixes, but a full translation from one language to another.
Would you vibecode a house?
Re: Bun has been converted to rust. Now what?
#34Deno was already implemented in Rust, and not done by vibe-coding. Would you trust a fully vibe-coded runtime? Not some features, not some fixes, but a full translation from one language to another.
Yes, but only because it is a translation. Easily the best use case for LLMs.
Re: Bun has been converted to rust. Now what?
#35> There is a small, ironic coda. The follow-up PR to delete the 600,000 or so lines of leftover Zig was titled, by Sumner, "ai slop." GitHub's automated anti-slop detection - built to flag exactly the kind of AI-generated mass change this was - caught it and auto-closed it. The author named his own cleanup slop, and the platform's tooling agreed. That looked suspicious to me (you could almost say hallucinated...), so…
Humans can make errors; part of why I waited so long to write and post this is because I'm not a great Rust coder (at all) and I don't use Bun, so I felt like I lacked enough relevant insight to say anything, and this is part of that, I think.
> Humans can make errors
Sure, that makes sense, no one bats an eye over that.
But this seems like a typical LLM hallucination, get the overall picture right, but misattributed where the actual work was done, this time it confused a GitHub feature for a feature of that particular repository, very common LLM mistake.
I'd be curious to know, if you were actually the one who made this mistake, how it actually came about? When you looked into how the label/actions were working, how did you manage to confuse a Actions Workflow for a built-in GitHub feature?
Re: Bun has been converted to rust. Now what?
#36Earlier quoted context omitted.
For one, you now know exactly where the memory unsafe code is, rather than a cloud of suspicion hanging over every line of the codebase.
Sure, as long as all the code in all those unsafe blocks is sound ! If not, the program is UB and all bets are off for every line of the codebase . I think Rust strikes a perfect balance between a safe default and, as you say, "localized unsafety". Said localized unsafety is however only localized as long as you're "doing it right". I would absolutely not trust an LLM to do it right for hundreds of thousands of lines…
Right, but the point is that you now have an explicit todo list of blocks to fix. You can trivially enumerate all sources of unsafety, and when a grep for unsafe blocks turns up empty you know your codebase is memory safe. When could you say the same about your Zig or C/C++ codebase?
I'm writing this as someone who doesn't even really like Rust; I'd probably prefer to write Zig! But those unsafe blocks definitely buy you something.
Re: Bun has been converted to rust. Now what?
#37> For scale: uv, a Rust project of broadly comparable size from the same general corner of the ecosystem, contains 73.
As a point of information: uv's use of `unsafe` largely involves interactions with OS APIs that don't have safe wrappers yet (in practice, this is mostly Win32 and similar APIs). It makes sense that Bun would have more `unsafe` than uv does, insofar as it needs to interact with JavaScriptCore's C API.
(This is without making a value judgement; only to observe that the magnitude of `unsafe` across projects doesn't necessarily communicate anything without knowing what the `unsafe` is for.)
Re: Bun has been converted to rust. Now what?
#38I am idly wondering, would it have made a difference if this was done over a month or two rather than say 9 days.
If it was really a thought experiment, and the test suit was so good, and hopefully further improved after this. Could the same experiment be run translating to Go, C, C++, Pascal, Swift, Crystal or Ada?
Re: Bun has been converted to rust. Now what?
#39Couple of notes here: - This is blatantly irresponsible, and killed any credibility this project has - Comparing unsafe counts to UV makes no sense here. - There is already a strong, safe runtime that's not vibe coded, called Deno, that more people need to check out. - I am skeptical why Bun was even an acquisition target in the first place, other than pulling stunts like this.
> - There is already a strong, safe runtime that's not vibe coded, called Deno, that more people need to check out.
But people don't like the differences in the other feature parity. Otherwise they would already use it.