Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewrite Bun in Rust has been merged

github.com

Post reply on HN
Print view View original

181–190 of 822 posts

Re: Rewrite Bun in Rust has been merged

#181

Post by dcchambers »

tvidas wrote: post #173

I don't really understand the point of this. Is it Anthropic showing off well their LLMs work? Was it too difficult to find Zig devs so Bun swapped to Rust? Did Jarred read one too many memes about "rewriting in rust" and took it at face value?? I would imagine that there will be bugs migrating all at once, performance will probably be close to the same, and the maintainers will need to context shift from Zig to Rust…

Probably some combination of: Anthropic is heavily invested in the Rust ecosystem and they want their core tools to be built on Rust. More Rust developers. More Rust training data so LLMs write better Rust code than Zig code. Advertisement for Claude Code doing major work on a high profile open source project.

Re: Rewrite Bun in Rust has been merged

#182

Post by embedding-shape »

davidghowell wrote: post #178
embedding-shape wrote: post #95

Earlier quoted context omitted.

I'd be surprised if they could eliminate memory issues completely, especially considering the amount of `unsafe` the codebase seems to contain. git rev-parse HEAD && ag "unsafe" src | wc -l 19d8ade2c6c1f0eeae50bd9d7f2a4bf4a2551557 14865

That's picking up all the "bunsafety" references in there :P

When I read what you wrote, I was like "of course, duh, I'm stupid" but running `ag "unsafe" src | grep -i "bunsafety"` it doesn't seem to be the case actually, I see zero bunsafety mentions from it.

However, `ag unsafe` does over-count anyways, just in a different way, matching stuff like SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION and _unsafe_ptr_do_not_use and others.

Better command with same previous commit, `ag -w unsafe src | wc -l`, reports 13914 "unsafe" usages now, slightly better but pretty awful still.

Re: Rewrite Bun in Rust has been merged

#183

Post by nDRDY »

veidr wrote: post #180
nDRDY wrote: post #169

Earlier quoted context omitted.

tsgo will inherit many benefits from go, even if it is never fully "idiomatic". This is in direct contrast to this port, which requires significant re-architecting (or made "idiomatic", if you wish) in rust to achieve any of the benefits of the language. You can't re-architect one step at a time.

I don't think you want to achieve any benefits of Rust in the initial port. Because at this scale you will definitely introduce new, and probably subtle, bugs that are not present in the Zig version. You just want it to be the same , to the maximum extent the language allows. E.g. 1000+ unsafe is the right move, for now. Reaping the benefits of Rust is for _future_ development.

That's my point - I don't see any hope of removing the 10,000+ unsafe calls, especially not one step at a time.

As such, this is a publicity stunt.

Re: Rewrite Bun in Rust has been merged

#184

Post by nDRDY »

tvidas wrote: post #173

I don't really understand the point of this. Is it Anthropic showing off well their LLMs work? Was it too difficult to find Zig devs so Bun swapped to Rust? Did Jarred read one too many memes about "rewriting in rust" and took it at face value?? I would imagine that there will be bugs migrating all at once, performance will probably be close to the same, and the maintainers will need to context shift from Zig to Rust…

I suspect one part of the puzzle is that Bun used its own fork of Zig, that had diverged signficantly in design and direction from mainline Zig.

Re: Rewrite Bun in Rust has been merged

#185

Post by asciimoo »

embedding-shape wrote: post #177
asciimoo wrote: post #176

Earlier quoted context omitted.

> Is it disrespectful if my proposed feature was merged, but then later was removed because the maintainer just didn't want the feature anymore? No, the big difference is that the described scenario does not require getting familiar with a new 1M LoC codebase written in a different language to be able to continue contributing to the project.

For who? What you say is true for everyone who doesn't know Rust (before Zig), and not true for everyone else, same as it always is been, for every single FOSS project out there. So it's disrespectful because before you could contribute, but because of the direction of the project, you no longer can? Does that also means it'd be disrespectful to make projects more complicated and complex, because maybe someone who co…

> For who? What you say is true for everyone who doesn't know Rust (before Zig), and not true for everyone else, same as it always is been, for every single FOSS project out there.

Even if you are fluent in rust, it is going to require significant efforts to contribute to a new 1M LoC codebase.

> Open source literally isn't about you, let people run their projects as they so wish, them making choices they think are better

This is so far from the reality. The power of open source is coming from the contributors. Contributors are the most valuable assets of an open source project - without them most of the free tools you use would be significantly worse - including bun. The reason my open source projects got somewhat successful is the community that formed around the projects. And, it is hard to create a community when you give contributors no chance to participate in the projects direction, especially in such a critical decision that has enormous consequences.

Re: Rewrite Bun in Rust has been merged

#186

Post by dormento »

slig wrote: post #124
simonklee wrote: post #79

Say what you want, but for people building products on Bun, this is bad news for the foreseeable future.

This is bad for anyone building on Zig.

Cue the clueless CEOs of zig shops (I don't know many, but still):

"Rust is faster and safer! Port it! If you don't do it, I'll do it myself, because AI can do everything a programmer can, including the stuff you don't want to do. Ship it!"

Re: Rewrite Bun in Rust has been merged

#187

Post by borngraced »

worble wrote: post #19
tkel wrote: post #4

Turns out "its just an experiment, you all are overreacting" was just a lie to damp criticism. https://news.ycombinator.com/item?id=48019226

Merging a complete rewrite in another language in 9 days seems insane to me. Maybe I'm just too cautious but with something like this I'd split off as a separate binary and get some heavy use customers involved as testers first to see if it causes any unforeseen problems before slowly expanding it out. I'd want to be pretty damn confident it won't cause any regressions before sunsetting the original codebase in favor…

Testing in production xD

Re: Rewrite Bun in Rust has been merged

#188

Post by embedding-shape »

asciimoo wrote: post #185
embedding-shape wrote: post #177

Earlier quoted context omitted.

For who? What you say is true for everyone who doesn't know Rust (before Zig), and not true for everyone else, same as it always is been, for every single FOSS project out there. So it's disrespectful because before you could contribute, but because of the direction of the project, you no longer can? Does that also means it'd be disrespectful to make projects more complicated and complex, because maybe someone who co…

> For who? What you say is true for everyone who doesn't know Rust (before Zig), and not true for everyone else, same as it always is been, for every single FOSS project out there. Even if you are fluent in rust, it is going to require significant efforts to contribute to a new 1M LoC codebase. > Open source literally isn't about you, let people run their projects as they so wish, them making choices they think are b…

> Even if you are fluent in rust, it is going to require significant efforts to contribute to a new 1M LoC codebase.

Of course, but this is true for any project or any language, can hardly be disrespectful of me to chose Clojure just because you don't happen to know it? That sounds crazy to me.

> Contributors are the most valuable assets of an open source project

You're talking about something else. Open source is literally about "This code has a specific license that allows you to do X" where X and Y differs by the license. Contributors or not matters squat if some open source project is valuable or not.

Don't mix concerns here, you're talking about "open development" or something else, not specifically open source.

Sure it's hard to create a community and get contributors and what not. But a maintainer choosing a different language and people feel that being "disrespectful" instead of just "stupid" or "dumb"? No, give me a break, you run your projects your way, and let others run theirs that way, they're not made for you, they just happen to be available to you because someone was nice enough to make it so. Don't spoil that by acting so entitled about how they should maintain and develop their project.

Re: Rewrite Bun in Rust has been merged

#189

Post by classicposter »

halifaxbeard wrote: post #172
Jarred wrote: 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

https://github.com/oven-sh/bun/security

Surprisingly, they appear to have not disclosed any vulnerabilities whatsoever. It's likely there have been numerous vulnerabilities in the past, but they are all being ignored.

https://x.com/DavidSherret/status/2031432509301428644

Post reply on HN