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

111–120 of 822 posts

Re: Rewrite Bun in Rust has been merged

#111

Post by preommr »

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

Well I've got egg on my face.

I am in that post, defending bun.

I thought for sure the peanut gallery was overreacting. Especially when the concern was absurd - because who would do such an insance thing? Like, at the time I legitimately thought 'no way a project switches over in a few months'. Even as an absurd hypothetical, I couldn't even imagine the prospect of it being done in a matter of days.

Feeling really confused right now.

Re: Rewrite Bun in Rust has been merged

#112

Post by aapoalas »

pulsartwin wrote: post #80
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…

Looking forward to the blog post. Do you plan to run both the Zig and Rust binaries side-by-side across a wide range of real applications (potentially shadowing in production) to weed out bugs?

They have a PR (~~closed by GitHub bot as AI slop, ironically~~ this was wrong info, it was apparently closed by Jarred himself as it missed a conversion or some 20 Zig files to Rust) to remove the Zig code.

I guess the answer is "no".

Re: Rewrite Bun in Rust has been merged

#113

Post by LucidLynx »

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…

[flagged]

Re: Rewrite Bun in Rust has been merged

#114

Post by embedding-shape »

LucidLynx wrote: post #113
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…

[flagged]

Coming on a bit strong no? Isn't it possible one could do an experiment almost two weeks ago, then by today the experiment concluded and now you've made a choice?

Did you think "experiment" meant 100% this will be thrown away? Wouldn't make much sense to experiment with something you know you'll throw away, unless you have some specific reason for it.

Re: Rewrite Bun in Rust has been merged

#115

Post by Klonoar »

LucidLynx wrote: post #113
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…

[flagged]

You don’t speak for most of us.

Re: Rewrite Bun in Rust has been merged

#117

Post by skeledrew »

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

Does anything from that comment say that there was 0% chance the experiment wouldn't be merged into main? I see "very high chance all this code gets thrown out completely", which just means the low chance of it not being thrown out has occurred.

Re: Rewrite Bun in Rust has been merged

#118

Post by zapnuk »

We should be greatful for this. This is the one public case study on how large-scale llm-driven code generation actually works out.

With node and deno there are reasonable alternatives for everyone who don't want to use bun anymore.

Re: Rewrite Bun in Rust has been merged

#119

Post by roxolotl »

fragmede wrote: post #73
rzmmm wrote: post #28

Earlier quoted context omitted.

I doubt it will end up as stable release very soon, but I'm happy to be proven wrong. I have some skepticism about this whole rewrite, Jarred Sumner has enormous internet following and it feels like an ad.

How do you wash to define ad, and why does it matter? If I tell you I had lunch, I mean. okay, great. If I tell you I had a delicious Coca-Cola with my lunch, sure. If I happen to work at Coca-Cola, does that now become an ad? And what level does it become an issue? And I what is the issue?

If you work for Coca-Cola then yea there’s reason to question your intent even if simply because you aren’t objective due to your proximity to Coca-Cola.

Re: Rewrite Bun in Rust has been merged

#120

Post by dolmen »

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…

Does that mean that from now your coding agents working on the Bun codebase are themselves running on that rust-Bun runtime?
Post reply on HN