Live data from Hacker News

Rewrite Bun in Rust has been merged

github.com

211–220 of 822 posts

Re: Rewrite Bun in Rust has been merged

#211

Earlier quoted context omitted.

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

This is really poor form given that Anthropic is going around getting all kinds of public goodwill for finding CVEs in other people’s products.

Re: Rewrite Bun in Rust has been merged

#212

Earlier quoted context omitted.

I can hope this will lead to little to no memory issues in using bun as a web server

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

Doesn't that count anything that has 'unsafe' in it, not just the keyword?

Re: Rewrite Bun in Rust has been merged

#213
I think one of the things I had forgotten about but sheds some more light in my mind about how this was done is that anthropic bought bun.

The change of tone with the author in the capabilities of Claude. The strategy of merging everything at once instead of a more slow, careful cutover. The “single” author story that every company loves to put forth.

Re: Rewrite Bun in Rust has been merged

#214
post #74

Earlier quoted context omitted.

No matter how I look at this, it's churn for the sake of churn. Even if the translation was free and into ideal idiomatic Rust (and it's obviously not - it's now Zig with Rust syntax) then this would be churn for the sake of churn. At some project scale the language really stops being any limiting factor, and you're instead mostly dealing with working past past architectural decisions, integration of large changes, d…

The "idiomatic Rust" thing rubs me the wrong way. If someone writes Rust that compiles and works, that's Rust. full stop. Telling people it doesn't count until it's "idiomatic" is just gatekeeping. It quietly says you're not a real Rust dev until you've put in years and absorbed all the unwritten rules, which shuts out exactly the people who are still learning. Everyone writes "non-idiomatic" code when they start. Th…

I get the feeling, and shooting for idiomatic on a rewrite is definitely wrong.

That being said, "idiomatic" is more just saying "clean and familiar". It's using the right language features in the right places.

For example, you could write something like this

    fn add_double(a: f64, b: f64) -> f64 {
      return a + b;
    }

    fn add_float(a: f32, b: f32) -> f32 {
      return a + b;
    }
But that's not idiomatic. Idiomatic would look something like this

    fn add>(a: T, b: T) -> T {
      return a + b;
    }
The benefit of the idiomatic approach is now you have a function which handles a bunch of types from u32, to f64 and it also handles custom types and traits which implement the add ops.

The first method is what you might write if you were, for example, translating from C to Rust. It isn't idiomatic but it's easy to do.

The other thing to realize is that compiler authors optimize for idiomatic. The more you do things in a strange fashion, the more likely you are to stumble over a way of writing code which isn't being looked at when the language team is looking at performance and compile time optimizations.

There's nothing wrong with non-idiomatic code per say. However, part of learning a language is learning the idioms. It makes you better at that language.

Re: Rewrite Bun in Rust has been merged

#215
post #206

If LLMs can achieve this level of task in 9 days, why do we even need Bun in the first place? Shouldn't we just write our apps in Rust and not even deal with JS?

Why even rust at the first place? I dont see why we can't go straight from natural language -> Claude -> HTML/JS/CSS bundle. Instead of writing webpage, one can just write prompt for each page and serve it with claude.cgi

Can a webpage run my factories?

Re: Rewrite Bun in Rust has been merged

#216
post #135
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…

You, nine days ago[0]: > I work on Bun and this is my branch > This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. Maybe... it wasn't such an overreaction? [0]: https://news.ycombinator.com/item?id=48019226

I was down voted pretty hard for calling this comment out. I would say I'm surprised but honestly? Completely predictable.

Re: Rewrite Bun in Rust has been merged

#217
post #183
post #180

Earlier quoted context omitted.

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.

You could do, but maybe they never will. I have no idea.

But the point is, in 2027, 2028... your new code doesn't have to suffer from these frankly 1970s issues

You could also gradually fix the internals — if you wanted to

Re: Rewrite Bun in Rust has been merged

#218
post #206

If LLMs can achieve this level of task in 9 days, why do we even need Bun in the first place? Shouldn't we just write our apps in Rust and not even deal with JS?

Why even rust at the first place? I dont see why we can't go straight from natural language -> Claude -> HTML/JS/CSS bundle. Instead of writing webpage, one can just write prompt for each page and serve it with claude.cgi

>> I dont see why we can't go straight from natural language -> Claude -> HTML/JS/CSS bundle.

Or we could just rewrite everything in assembly, becauase thats fast. Well, Claude can do that. (/s ??)

Re: Rewrite Bun in Rust has been merged

#219
post #215

Earlier quoted context omitted.

Why even rust at the first place? I dont see why we can't go straight from natural language -> Claude -> HTML/JS/CSS bundle. Instead of writing webpage, one can just write prompt for each page and serve it with claude.cgi

Can a webpage run my factories?

Yes, it can. Just vibe code Claude to connect to your lithiography machine and voila! Claude will run your factories. Claude can even apply oil to your rusty machines if you choose the $1000/month package

Re: Rewrite Bun in Rust has been merged

#220
post #206

If LLMs can achieve this level of task in 9 days, why do we even need Bun in the first place? Shouldn't we just write our apps in Rust and not even deal with JS?

Why even rust at the first place? I dont see why we can't go straight from natural language -> Claude -> HTML/JS/CSS bundle. Instead of writing webpage, one can just write prompt for each page and serve it with claude.cgi

And if you inject information about the user into the context, everyone can have their own personalized version and we'll turn the internet into the tower of babel where no two people see or experience the same thing.
Post reply on HN