Live data from Hacker News

Rewrite Bun in Rust has been merged

github.com

431–440 of 822 posts

Re: Rewrite Bun in Rust has been merged

#431
post #196

Earlier quoted context omitted.

Yes sure it's ok to change your mind. But don't you think the people Jarred accused of "overreacting" in retrospect didn't?

The top comment at that link points out how many of the sibling comments are delirious and emotional, kneejerk responding to the news rather than giving any sort of sober analysis. That people were overreacting with emotional meltdowns (common in AI-related threads) is perfectly compatible with the branch making enough progress to get merged.

This seems dishonest.

I'm reading through the top comments next to his and don't see that. You can always find delirious and emotional takes, but those didn't dominate the discussion

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

> [...] Time will tell how this will turn out. Would be nice if the Bun maintainers could give some clarification about what they’re doing here, and why they’re doing this.

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

Compares this to Go runtime's C to Go migration

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

Link to Github diff view

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

> I wonder if a successful, albeit slower, approach would be to walk the git commit history in lockstep, applying the behavioral intent behind each commit. If they did this, I would be interested in knowing if they were able to skip certain bug fix commits because the Rust implementation sidestepped the problem.

Re: Rewrite Bun in Rust has been merged

#432

I'm confused. Never heard of Bun until a few days ago here on HN. It's some nodejs wrapper thingy, written in Zig, and someone decided to use LLM to rewrite it in Rust. Is this a big deal? Who is even using this software? Why is this big?

I've never done any JavaScript development of any kind and had never heard of this either. I thought it was a package manager at first, but apparently it's an entire runtime.

My question is, if it's this trivial to rewrite Zig to Rust, and trivial in general to write Rust at all, why not just use Rust for your server side code in the first place? What's the value of continuing to use JavaScript and putting so much effort into the runtime?

Re: Rewrite Bun in Rust has been merged

#433
post #242

By reading this thread I've learned that, apparently, you are not allowed to rewrite a large piece of software backed by a large test suite in another language within two weeks otherwise you are a witch and need to be burned on a stake. You are also not allowed to move from the PoC phase to lets-do-it phase within a couple of days without being called names. Why are we concerned with speed all of a sudden? Are we in…

The top comment in the thread explains it pretty well, so please don't pretend it's anything else. The point is they went from "chillax, it's just an experiment" to "we'll switch languages via a 1M line vibecoded patch" in two days. People that rely on this software are understandably fearful, since there is no way this change has been properly revised and tested. Although perhaps the mistake was relying on such soft…

People relying on this software can absolutely choose to stay on current/recent versions until this becomes more mature. My assumption is that the current state allows for public testing, but anyone needing a stable version wouldn't be affected and can choose to not be affected by it.

Re: Rewrite Bun in Rust has been merged

#434

Earlier quoted context omitted.

“Nobody could have seen this coming…”? Well apparently a lot of people did. Maybe Jarred didn’t, maybe you didn’t, but most people correctly predicted what was coming.

See what coming?! I really don't understand what's going on here. Correctly predicted what, that Bun was being rewritten into Rust? I'm not sure anyone doubted that, all the work they did was public??? What on earth is going on here?

> What on earth is going on here?

With the nearly complete PR with the port to rust, a number of people predicted that it was going to happen. They were assured it's unlikely to happen and then they were accused of overreacting over effectively nothing. When those same people who were already upset about the rewrite, learned that their predictions the same ones that were rudely dismissed, were in fact, correct, they became upset again; this time about being lied to.

Correct or not, it's reasonable to conclude they were lied to. Especially given they correctly predicted the future.

Re: Rewrite Bun in Rust has been merged

#436
post #322

Earlier quoted context omitted.

Which persons were attacked by their comment? The "them" is confusing me – I interpreted it as Bun the organisation / Anthropic?

I'm confused too as to how my comment can be interpreted as a personal attack on anyone. I was indeed talking about Bun as a whole and not any particular person. I'd even include the Bun community in my "them". But I'll take dang's word for it and will watch what I say.

Ah, I thought you referring to a person. I'm sorry for misreading you.

It's still a bad HN comment, I'm afraid (denunciatory rather than curious, for one thing), but it wasn't a personal attack and not a post that would normally clear the bar for a mod reply.

Re: Rewrite Bun in Rust has been merged

#437
post #76

Still writing the blog post about this. Will share more details. For where this is coming from, skim the bugfixes in the Bun v1.3.14 and earlier release notes. Rust won’t catch all of these - leaks from holding references too long and anything that re-enters across the JS boundary are still on us. But a large % of that list is use-after-free, double-free, and forgot-to-free-on-error-path, which become compile errors…

Any plans to issue a CVE for this HTTP request smuggling attack vector fixed in the latest bun release? https://github.com/oven-sh/bun/issues/29732

maybe you should ask on the issue directly?

Re: Rewrite Bun in Rust has been merged

#438

Earlier quoted context omitted.

> Claude Code itself is purely vibecoded [...] money they intend to squander [...] going to burn themselves to the ground getting high on their own supply. This really really really isn't the burn you think it is. Going from 0 to 2B+ in revenue from a "purely vibecoded" thing is what they've said they're doing, and what they've actually done. Like in already done. It's not going back, no matter how many nuh nuh peopl…

2B+ in revenue on hundreds of billions in investments and future commitments is completely worthless. Anybody can turn $100b into $2b, that's not a fucking accomplishment. And to the extent that something is driving any revenue, it is the model, not the TUI. Any success Claude is having is despite the godawful TUI, not because of it.

[deleted]

Re: Rewrite Bun in Rust has been merged

#439
post #76

Still writing the blog post about this. Will share more details. For where this is coming from, skim the bugfixes in the Bun v1.3.14 and earlier release notes. Rust won’t catch all of these - leaks from holding references too long and anything that re-enters across the JS boundary are still on us. But a large % of that list is use-after-free, double-free, and forgot-to-free-on-error-path, which become compile errors…

Is writing the blog post taking longer than the rewrite

Re: Rewrite Bun in Rust has been merged

#440
post #368

When announcements say that rewrite took 1 week, I wonder how much time went into preparing this file with very detailed instructions on mapping Zig to Rust idioms: https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd573... On top of that, if you look at 'Pointers & ownership' and 'Collections' sections, the Bun codebase is already prepared, using internal smart pointer types that map 1-to-1 to Rust equivalents,…

Ignoring things like whether the Rust that was output could be deemed qualitatively good, whether the resulting line count is appropriate, how much the codebase was ready or primed for this kind of exercise going in, and so on, is it fair to say that a 622 line artefact created up front is a relatively small cost for a potential increase in consistency or quality of output when the output is ~1M LoC? It seems like th…

I would guess it was a for ... each loop. They likely wrote a bunch of skills. The foor loop went through each file and generated a complimentary file, then had another process integrate/validate.

I doubt the entire process was a single week, just whatever harness they specially prepared for the work.

Post reply on HN