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

611–620 of 822 posts

Re: Rewrite Bun in Rust has been merged

#611

Post by awwaiid »

dlopes7 wrote: post #607
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 bet the blog post will make no mention of pressure from anthropic to do this and instead will celebrate the fact that “it passes all tests”, of course omitting how many tests were modified to forcibly pass

Was there pressure to do this, or freedom to do this? If I had an unlimited token budget I'd probably try all sorts of crazy things. Also you (one) can read the tests and see that they weren't modified to forcibly pass.

Re: Rewrite Bun in Rust has been merged

#612

Post by deathanatos »

I feel like there's an iron triangle here, that involves "is vibe-coded", "is secure" and "accepts bugfixes".

Like, you didn't review that 1M LoC. There's no way to have done so. If we're accepting slop-fest PRs, then nothing stops an attacker from burying a security bug in a slop-fest PR that then gets reviewed. And if I'm the attacker, I'm crafting that security hole to have subtle clues to the security AIs reading it as to why it's "correct" so that your AI review bot goes "oh, yeah, this logic works".

Re: Rewrite Bun in Rust has been merged

#613

Post by AlienRobot »

j-pb wrote: post #284
AlienRobot wrote: post #265

Earlier quoted context omitted.

I think if you use a programming language that is clearly version zero you can't complain that it's not stable...

I'm not expecting the whole language to be stable, but I expect certain parts of it to be more stable than others. E.g. control flow vs. async. I'm not saying that they can't work that way, more power to them. But then having the expectation of anybody using it in a professional setting is also unrealistic. You can't have your cake and eat it too, either it's your personal project and you are fine with nobody using i…

Having tried both, I think Zig is a replacement for C, while Rust is a replacement for C++.

One thing Zig has that lots of "niche" languages don't is that you can include C headers directly. This means if you want to make a game in SDL, for example, you don't need to wait until someone ports SDL to your new language. You can just include SDL.h directly and start using it. D also has this feature, by the way, but Rust requires you to generate the bindings.

Even if people move from Zig to Rust for some things or vice-versa, the strengths of Zig remain there.

Re: Rewrite Bun in Rust has been merged

#614

Post by antonvs »

fdsajfkldsfklds wrote: post #485
sunrunner wrote: post #402

Earlier quoted context omitted.

Ignoring things like whether the Rust that was output could be deemed qualitatively good, whether the resulting line count is appropriate, how much the codebase was ready or primed for this kind of exercise going in, and so on, is it fair to say that a 622 line artefact created up front is a relatively small cost for a potential increase in consistency or quality of output when the output is ~1M LoC? It seems like th…

This is effectively a very expensive and resource-intensive machine translation. As such, there is no increase in consistency or quality of output.

How would you have achieved this “machine translation” without an LLM?

It seems to me it would have been highly likely to be more expensive and more resource intensive - if realistically possible at all, short of implementing a general Zig to Rust translator first.

Re: Rewrite Bun in Rust has been merged

#616

Post by BoorishBears »

famouswaffles wrote: post #533
BoorishBears wrote: post #530

Earlier quoted context omitted.

You know, we used to look down on engineers who didn't realize there's more to software than the raw lines of code.

You're free to look down on whoever you want. I'm free to tell you I couldn't care less, and that both replies so far just confirm how much of an emotional meltdown the reactions here really are. Your comment has managed to have nothing to do with the point I was making.

You're getting the responses you earned by intentionally being flippant as possible.

If you had presented your point more thoughtfully, maybe I'd have spoon fed the point of my response, which 100% relates to what you said: your model of time compression is describing the speed of creating code.

But Bun is more than lines of code and serves as core infrastructure for lots of other projects. It's a terrible look in terms of governance to approach this migration as they have, especially the initial denial.

That shouldn't be contentious.

Re: Rewrite Bun in Rust has been merged

#617

Post by tovlier »

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.

[dead]

Re: Rewrite Bun in Rust has been merged

#618

Post by tovlier »

tln wrote: post #447
Jarred wrote: post #422

Earlier quoted context omitted.

> mostly a JavaScript interpreter wrapper Not accurate. Bun is a batteries-included JavaScript & CSS transpiler (parser), minifier, bundler, npm-like package manager, Jest-like test runner, as well as runtime APIs like a builtin Postgres, MySQL and Redis client. This is naturally a ton of code.

Now that Bun can leverage Rust do you think some of this code will get disaggregated? Eg, Bun could use swc crates

[dead]

Re: Rewrite Bun in Rust has been merged

#619

Post by harrygeez »

defen wrote: 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?

I find that LLMs are quite good at translating code. If you are writing something from scratch you have the burden of preparing something for the LLMs to "translate" from, i.e. prompt or specifications – next best thing to actual source code.

Defining specifications with the level of detail needed to build applications exactly as intended is not as trivial as it may seem.

Re: Rewrite Bun in Rust has been merged

#620

Post by antonvs »

embedding-shape wrote: post #390
serial_dev wrote: post #357

Earlier quoted context omitted.

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

See what coming?! I really don't understand what's going on here. Correctly predicted what, that Bun was being rewritten into Rust? I'm not sure anyone doubted that, all the work they did was public??? What on earth is going on here?

> What on earth is going on here?

Irrational armchair quarterbacking driven by emotional reactions to change and perceived threats. It’s not worth worrying about this specific instance, but the overall trends could get messy. This is just a taste of that.

Post reply on HN