Live data from Hacker News

Bun has been converted to rust. Now what?

bytecode.news

51–60 of 113 posts

Re: Bun has been converted to rust. Now what?

#51
I always thought if they are vibe coding all the unsafe Rust code, they might as well keep it in zig, at least someone understands what they are doing. With Rust, when there is a CVE, chances are that nobody can even understand what the issue is, let alone fixing it.

I for one am definitely going to stick to Node.js instead of taking my chances with Bun.

Re: Bun has been converted to rust. Now what?

#52
> This is a measurement discipline: when someone offers you a test pass rate as evidence of a safety property, check whether the test suite measures that property. Behavioral equivalence and memory soundness are different axes. A green test suite tells you the new thing acts like the old thing. If the old thing was a body of manual memory management and the new thing is a faithful translation of it, then green tells you the translation is good - and tells you nothing whatsoever about whether the thing is safe. The number that would actually answer the question is the one nobody can produce yet, because producing it is, for now, an unsolved problem.

Bottom line is we didn’t have a measurement of safety before the port, and we don’t have one now.

What we do have is a known list of unsafe blocks, and we can use that as our safety measure. (I’m neither a Zig not Rust programmer, but I’m guessing that the unsafe parts of the Zig codebase were also mostly measurable so we could have had this measure.)

I do wonder if the next step is to move bun into WASM for an additional layer of security. Those unsafe blocks might be neutered by not granting WASM the ability to run them. That would give anthropic a “sandboxed by default” opportunity.

It’s a fun project to watch!

Re: Bun has been converted to rust. Now what?

#53
post #10

The irony of a post about a port primarily written by Claude having been primarily written by Claude on a website primarily designed by Claude. Come on.

Claude (and Codex) designed the site, mostly because I'm not a UI coder; if I'd designed the site nobody'd want to read it but me, simply thanks to the UX. And I have a full-time job and more; I draft with an LLM's assistance and revise with another LLM (and other humans where possible) because I'm just arrogant enought o think that what I think might be useful to others. If it's not useful to you, I get it. Such is…

It's not about that. Me as a reader wants to read you as a human, with all of its colors and nuances.

These days due to usage of LLMs I developed (unknowingly) an LLM detector when reading these. I actually get distracted.

So please, I believe you do have something to tell to the world, but please take it slower. No need to rush. I'd rather have something to read uniquely made by you.

Re: Bun has been converted to rust. Now what?

#54
post #10

The irony of a post about a port primarily written by Claude having been primarily written by Claude on a website primarily designed by Claude. Come on.

Claude (and Codex) designed the site, mostly because I'm not a UI coder; if I'd designed the site nobody'd want to read it but me, simply thanks to the UX. And I have a full-time job and more; I draft with an LLM's assistance and revise with another LLM (and other humans where possible) because I'm just arrogant enought o think that what I think might be useful to others. If it's not useful to you, I get it. Such is…

Your process loses your unique voice. The content was OK, but too verbose, and needed data on other rust ports of similar scope.

The issue is the quippy titles, “something - aside - continue” phrasing, and other constructions are feel like they or actually are wholly LLM written. I find a high correlation to this and low density fluff. The author did not have 10 paragraphs of things to say, but used an LLM to inflate a short outline to that. We would all of been better off with a tighter document - either human written or better prompted.

Re: Bun has been converted to rust. Now what?

#55
post #3

Deno 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.

Depends on who vibe codes it. At the end of the day the Bun developers are the ones responsible for the quality of their software. If they've reviewed the code closely, tested it, and eat their own dog food, then I don't see why I should treat it any different from any other untrusted 3p dependency.

IMO, the main problem with vibe coding is that it empowers reckless behavior at companies like Microsoft, and that people with no serious investment in outcomes are empowered to make things. Does that apply to Anthropic? The Bun team? It's not 100% clear yet.

Re: Bun has been converted to rust. Now what?

#56

Earlier quoted context omitted.

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…

Mostly because I finally figured out what I thought was relevant about the Bun port over the last couple of days, thanks to someone far more embedded in the ecosystem than I complaining about it. That complaint was the seed idea in the post, and shows up only remotely, because I thought the complaint itself was ranty and misplaced, but cast a shadow that actually interested me more.

So I did some casual research, but used generalized numbers and impressions; I wasn't trying to pretend deep research, and some of the numbers (like the 99.8%) were drawn from publications and discussions that seemed not in debate.

I am not an akshual journalist - I'm a systems architect who enjoys writing, who's served in a sort of journalistic role, and I sometimes write about topics that are not in my area of expertise. I don't write JS often myself; I've looked at Bun, particularly when it first came out, but my in-depth experience with it is minimal, so I'm writing everything from afar, and that includes the impression about the git interaction, which people wrote about and from which I inferred my conclusion, particularly because I didn't see the point of manually triggering the rejection.

Re: Bun has been converted to rust. Now what?

#57

> 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…

I would trust a zig -> rust translation far less if it didn't make liberal use of unsafe, because that implies an order of magnitude more aggressive refactoring

Re: Bun has been converted to rust. Now what?

#58
post #10

The irony of a post about a port primarily written by Claude having been primarily written by Claude on a website primarily designed by Claude. Come on.

Claude (and Codex) designed the site, mostly because I'm not a UI coder; if I'd designed the site nobody'd want to read it but me, simply thanks to the UX. And I have a full-time job and more; I draft with an LLM's assistance and revise with another LLM (and other humans where possible) because I'm just arrogant enought o think that what I think might be useful to others. If it's not useful to you, I get it. Such is…

I agree with the others - I'm sure that you've provided your own input, but Claude's writing and design style is so overwhelmingly dominant that those who have spent time with it can immediately recognise it, and it makes it hard to take at face value that you were the primary author, even if you were.

For your workflow, I'd suggest drafting with a LLM to help you find the right balance of content, and then throwing all of that out and writing it yourself. Otherwise, it won't sound like you.

Re: Bun has been converted to rust. Now what?

#59
post #50

Earlier quoted context omitted.

Claude (and Codex) designed the site, mostly because I'm not a UI coder; if I'd designed the site nobody'd want to read it but me, simply thanks to the UX. And I have a full-time job and more; I draft with an LLM's assistance and revise with another LLM (and other humans where possible) because I'm just arrogant enought o think that what I think might be useful to others. If it's not useful to you, I get it. Such is…

Why can't you just publish the prompt instead? Do you not see how LLMs subtly alter your original message and erase your voice? They fill gaps that didn't exist, they create syllogisms that make no sense, and the voice is now so ridiculously AIdiosyncratic that it makes my eyes boil! If you have a message that takes 100 words to say, do not use a LLM to add 400 words to it, this isn't a school assignment! Stretching…

Heh. Funny thing: I've been writing online and professionally for literal decades, since around 2002 or so, and the LLMs tend to change my actual writing voice relatively little and usually in positive ways, since they say I meander too much.

Re: Bun has been converted to rust. Now what?

#60
post #26

Earlier quoted context omitted.

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…

For normal use of unsafe in Rust, I completely agree, and I love the concept. But if you have a gazillion unsafe blocks written by someone (something) you don't trust to at least try to do the right thing, you're bound to have unsoundness in one of those blocks. And now your entire codebase is UB.

I don't see how this is any different from every line trailing with a comment of the form "FIXME: This line might be wrong".

And I say this as something of a Rust fanboy. I love the way unsafe blocks work, and the "locality of danger" they give you. But that all goes out the window if there's a gazillion haphazardly written such blocks.

Post reply on HN