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

Rewriting Bun in Rust

bun.com

Post reply on HN
Print view View original

461–470 of 560 posts

Re: Rewriting Bun in Rust

#461

Post by endospore »

insanitybit wrote: post #460
lunar_mycroft wrote: post #444

Earlier quoted context omitted.

There were/are absolutely plenty of real problems with the resulting code pointed out. Running Miri trivially found soundness issues, `SAFETY` comments that demonstrate that the model in question fundamentally doesn't understand/simulate understanding how unsafe rust works [0], etc. [0] https://github.com/oven-sh/bun/blob/fc865b398e51de8a95ddde4b...

These seem really easy to address. Any SAFETY comment that relies on the caller is something you can trivially find and fix.

Look a few more till you find absolutely bs SAFETY comments marked on immediate UBs. They are everywhere.

Re: Rewriting Bun in Rust

#462

Post by sdevonoes »

sashank_1509 wrote: post #125

I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow. Forgetting all the predictions about singularity etc, at the very least AI as it is now, is going to make it very hard to justify…

Nah. You got it wrong. Don’t think too much of yourself, pal

Re: Rewriting Bun in Rust

#463

Post by tipiirai »

This post was clearly an important marketing effort from Anthropic and Jarred. Those interactive demos alone would take serious effort from a seasoned frontend engineer, AI-assisted or not. Pretty sure multiple devs were working on this post.

Re: Rewriting Bun in Rust

#464

Post by srdjanr »

atonse wrote: post #170
pier25 wrote: post #140

Personally I don't care that they used AI to rewrite Bun to Rust. Even if 1.4 is not good enough it will probably get better over time. What has pushed me back to Node is seeing how amateurish the transition has been handled. - No LTS support for the Zig version regarding CVEs etc. - Huge bugs like the 3MB memory leak mentioned in the blog post abandoned in the Zig version to basically force people into the Rust vers…

LTS is more relevant if there was any kind of compatibility that was broken. They still haven’t released 1.4 even though it seems to have gone extremely well by every metric in the wild, with tons of people using Claude code with no regressions in a month. Nothing to me suggests they’re being careless here. In fact, he had two adversarial reviewer Claude instances on every code change, every line. I don’t know a sing…

I have a few opinions on this:

1) My (and possibly other people's) last impression of this was when it was merged just based on all tests passing. In many projects, relying just on tests would definitely be reckless (not sure about coverage/quality of Bun tests).

I didn't follow much what where they doing later, maybe it is indeed good enough. For example, Claude Code using it and being fine is reassuring.

2) Making such a big decision that quickly and not (even having the time to) consulting community doesn't really inspire confidence.

3) You can be reckless even if everything ends up being perfect in the end.

Going 80mph in a city, you probably have like 80% chance of not crashing. And if you don't crash, you just had a much faster and more fun trip. Doesn't mean it wasn't reckless.

Re: Rewriting Bun in Rust

#465

Post by steveklabnik »

whytevuhuni wrote: post #252
steveklabnik wrote: post #187

Earlier quoted context omitted.

> way too big https://github.com/tormol/tiny-rust-executable This produces a 137 byte binary. Obviously AMD64 isn't used in embedded, but I've seen ARM ones that are in the ~256 range. It's all in how you use it. Of course, if you don't care about binary sizes, they can get large, but that's very different than actually paying attention to what you're doing.

I tried to use Rust for a tiny microcontroller (GD32VF103, 128KB flash). First of all, I was amazed by how much I could do with Rust ( safe Rust, even), and how well it was interfacing with my handwritten RISC-V assembly. I will definitely use Rust again for the next such project. But, every time my functions would get over a certain size, suddenly some optimizations stopped working, and Rust was trying to put the wh…

I don't disagree that I think that the Rust project could do more to make this kind of development easier, and it is true that it doesn't come for free. That doesn't change the point that if you want to, you can do it, it is not a fundamental language limitation.

Re: Rewriting Bun in Rust

#466

Post by lunar_mycroft »

insanitybit wrote: post #460
lunar_mycroft wrote: post #444

Earlier quoted context omitted.

There were/are absolutely plenty of real problems with the resulting code pointed out. Running Miri trivially found soundness issues, `SAFETY` comments that demonstrate that the model in question fundamentally doesn't understand/simulate understanding how unsafe rust works [0], etc. [0] https://github.com/oven-sh/bun/blob/fc865b398e51de8a95ddde4b...

These seem really easy to address. Any SAFETY comment that relies on the caller is something you can trivially find and fix.

First, we're talking about a massive rewrite of complex software project which no one has fully reviewed and which the people most familiar with the code base (the bun maintainers) aren't even qualified to do so. As such, the issues people have found are mostly surface level.

But second, you're right, this is an easy thing to search for (especially with LLMs). And yet, the example I linked has been there since may, surviving multiple rounds of review. From this, we can draw a few conclusions: 1) claude (including apparently mythos/fable) fundamentally doesn't "understand" how unsafe rust works, and 2) no one on the bun team is aware that they need to tell it to fix this (if they're even aware that this isn't allowed in the first place).

The reason such trivial defects in a codebase are a red flag isn't so much those specific issues themselves, it's what they reveal about the authors. If you find a lot of obvious defects in some code, it's very likely that there are also many more subtle harder to detect issues as well.

Re: Rewriting Bun in Rust

#467

Post by steveklabnik »

zamadatix wrote: post #370
steveklabnik wrote: post #51

Earlier quoted context omitted.

I don't think you can draw the conclusion that source length and binary size are correlated. For example, in Rust: #[derive(Copy, Clone)] enum Expr { Int(i32), Add(i32, i32), Neg(i32), } fn eval(expr: Expr) -> i32 { match expr { Expr::Int(x) => x, Expr::Add(a, b) => a + b, Expr::Neg(x) => -x, } } Rust's enums can carry data. You can write the same thing in C, but because it does not have the enum feature, you have to…

I'm not sure individual examples is the right way to go about this. A correlation isn't a guarantee for every instance and it's easy to concoct individual examples which tell any story you'd like them to. To properly answer this you'd need to compare a large number of identical implementations written idiomatically in several languages and see if there is a correlation. If I were to throw my 2 cents in I'd say "a ver…

Sure, I did not think that one example is a full survey of all possibilities. I think that it's quite intuitive that this feels right:

> it seems to me languages fine having a lot of bloat in the syntax also tend to be languages fine having a lot of bloat in the implementation or attracted to abstraction

Which is why I chose an example of the exact opposite: a language not known for bloat, taking way more code to produce the exact same thing as one that's more succinct.

It's not as good as some sort of scientific survey of a wide variety of options, but if you can find examples in all directions, assuming there's no correlation until proven otherwise is a pretty solid bet, I think.

Re: Rewriting Bun in Rust

#468

Post by insanitybit »

lunar_mycroft wrote: post #466
insanitybit wrote: post #460

Earlier quoted context omitted.

These seem really easy to address. Any SAFETY comment that relies on the caller is something you can trivially find and fix.

First, we're talking about a massive rewrite of complex software project which no one has fully reviewed and which the people most familiar with the code base (the bun maintainers) aren't even qualified to do so. As such, the issues people have found are mostly surface level. But second, you're right, this is an easy thing to search for (especially with LLMs). And yet, the example I linked has been there since may, s…

I think that's an interesting point that the models wrote SAFETY comments that are so obviously not what SAFETY comments are for. A SAFETY comment can never be about callers, that's the whole point of `unsafe`.

Re: Rewriting Bun in Rust

#469

Post by benced »

crote wrote: post #294
benced wrote: post #57

Earlier quoted context omitted.

I would guess the cost to do this with humans would be _at least_ $1.5M in compensation alone (I'm thinking three 500k/year Bay Area engineers) so this is already an order of magnitude cheaper. Is it worth $165K? I'm less sure of that but it's honestly a moot point - this will get to 5 then 4 digits of cost pretty fast.

Bay Area salaries are well-known to be extremely inflated. Have European engineers do it for $100k or Asian engineers do it for $50k and the math is already looking a lot sketchier.

More gets done in the Bay Area than those places.

Re: Rewriting Bun in Rust

#470

Post by Rohansi »

vlovich123 wrote: post #450
Rohansi wrote: post #240

Earlier quoted context omitted.

> For what it’s worth game devs often use C# or C++ engines which have even worse issues. Such as? You can't be referring to hot reload alone because you can already do that in both C++ and C#.

Well for c++ memory safety and sharp abstractions and even worse compile times than Rust. I’m not aware of hot reload really being done in c++ at any scale but I’m not a game dev so I’m open to learning. C# AFAIK holds a minor place in gamedev and also has slow compile times maybe? I assume it has better support for hot reload times. But generally the performance profile isn’t there for the most demanding games even…

It's not specific to game dev but Visual Studio has hot reload for C++ that you should be able to make use of.

C# compile times are fast. Performance is a lot better than you probably think, especially with modern .NET (not what Unity uses).

Post reply on HN