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

351–360 of 822 posts

Re: Rewrite Bun in Rust has been merged

#351

Post by vinnymac »

asdfasgasdgasdg wrote: post #340
Aurornis wrote: post #333

Earlier quoted context omitted.

The Bun codebase had a similar number of lines of code before the rewrite. There's nothing unusual about a rewrite coming in with a similar LOC number.

If anything, it's a little surprising that the Rust code isn't significantly larger because I tend to think of Rust as requiring somewhat more boilerplate than JS.

Not to mention how trigger happy LLMs can be when it comes to being overly verbose and adding unnecessary bits even with explicit direction not to do so.

Re: Rewrite Bun in Rust has been merged

#352

Post by SwellJoe »

losvedir wrote: post #276

Wow. This is going to be interesting to follow. There's absolutely no way any of this code was reviewed, but maybe we're in a post-human world now where you can trust the models to write and review the code. This is like Gastown but on a higher profile project. Will be fascinating to see how this project is able to add new features going forward (or even _if_ it will be able to). Does anyone know how exactly Bun is u…

How's the test suite?

Re: Rewrite Bun in Rust has been merged

#353

Post by [deleted] »

Barrin92 wrote: post #344
petcat wrote: post #308

Earlier quoted context omitted.

Cool you can just search specifically for potentially unsafe code in Rust. How do you search for unsafe code in Zig? Or do you just have to assume it's everywhere?

if half of your files in a million line codebase are unsafe that doesn't tell you much any more. Presumably the point of a Rust rewrite is that you actually make use of Rust's safety features in a coherent way. But given the whole "let AI rewrite this for me" stunt nature of this project that was not going to happen because that would require well, actual thinking and a re-design. So now you have Zig disguised as Rus…

[deleted]

Re: Rewrite Bun in Rust has been merged

#354

Post by tasuki »

xydone wrote: post #193
szmarczak wrote: post #165

Earlier quoted context omitted.

Wait till you hear about https://github.com/nodejs/node/pull/61478

This is a PR that has been getting reviewed since the end of January. The Bun port branch was created 9 days ago.

Yes, reviewed since January, has almost 400 comments, and 7 (seven!) approvals from core nodejs contributors.

Re: Rewrite Bun in Rust has been merged

#355

Post by debugnik »

bhaak wrote: post #335
losvedir wrote: post #276

Wow. This is going to be interesting to follow. There's absolutely no way any of this code was reviewed, but maybe we're in a post-human world now where you can trust the models to write and review the code. This is like Gastown but on a higher profile project. Will be fascinating to see how this project is able to add new features going forward (or even _if_ it will be able to). Does anyone know how exactly Bun is u…

It passed all the tests. If you can't trust your test suite to catch an automatic language translation you shouldn't trust it at all. :)

It also modified many of the tests to make them pass in mischievous ways. You can't trust a test suite to catch regressions if the new version doesn't use the same test suite.

Re: Rewrite Bun in Rust has been merged

#357

Post by serial_dev »

embedding-shape wrote: post #223
tasuki wrote: 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?

No, what we knew then is still what was known then. Today is different, and seemingly they've committed to the rewrite, so now it makes sense that people have strong feelings about it, as it's no longer just an experiment.

“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.

Re: Rewrite Bun in Rust has been merged

#358

Post by layer8 »

sunrunner wrote: post #306
vitaminCPP wrote: post #253

> +1009257 -4024 Bun is now over 1M lines of Rust code. This is approaching the size of the Rust compiler itself; except that BunJs is mostly a JavaScript interpreter wrapper + a reimplementation of the NodeJS library (Rust STD wrapper). I think BunJS is becoming the canary for software complexity management in the LLM era.

I'm not sure if it's just the leading '+' or if there are other factors for phone number detection on iOS, but on mobile the line count changes are underlined and I can tap it to start a call, which, if it is because of the diff size, is something I find pretty amusing.

The leading “+” is not needed. Numbers with seven digits are automatically hyperlinked (possibly depends on locale).

123456

1234567

12345678

Re: Rewrite Bun in Rust has been merged

#359

Post by nzoschke »

janice1999 wrote: post #93
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…

I'm curious how much this would cost a paying customer. Can you please give us an estimate?

Great question and I'd love the answer.

I bet the answer is industry changing even if the token cost is high.

This work was impossibly expensive in terms of people hours and time before. Architectural planning, engineering alignment and politics, phased engineering that gets interrupted by changing priorities.

That it's possible to do R&D, the port, and get 99.X test passing in less than 2 weeks is so much more efficient for the humans.

Re: Rewrite Bun in Rust has been merged

#360

Post by 12_throw_away »

Aurornis wrote: post #336
ordu wrote: post #289

Earlier quoted context omitted.

The half of the files contain 'unsafe' keyword? It doesn't seem as a good rewrite. What is the point of rewrite into Rust, if ~half of your code is still unsafe?

unsafe just means that you take responsibility for the safety of the code contained within. Calling into non-Rust libraries has to be wrapped in unsafe. Making syscalls has to be wrapped in unsafe. Bun needs to interact with FFI code. This gets wrapped in unsafe blocks. There are many places where a JavaScript interpreter and library would need to make unsafe calls and operations. It doesn't literally mean the code i…

There's actually a good example of this in the rewrite [1], in `PathString::slice`. They are doing an unsafe operation to return a slice that could be a use-after-free, if the caller had not already guaranteed that an invariant will remain true. Following proper rust idiomatic practices, claude has added a SAFETY comment to the unsafe block to explain why it's safe: "caller guarantees the borrowed memory outlives this".

Now, normally, you'd communicate this contract to your API users by marking the type's constructor (PathString::init) as "unsafe", and including the contract in its documentation. Unfortunately in this case, this invariant does not exist - it appears to have been fabricated out of thin air by the LLM [2]. So, not only does this particular codebase have UB problems caused by unsafe code, the SAFETY blocks for the unsafe code are also, well, lies.

[1] https://github.com/oven-sh/bun/blob/63035b3e37/src/bun_core/...

[2] https://github.com/oven-sh/bun/blob/63035b3e37/src/bun_core/...

Post reply on HN