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

631–640 of 822 posts

Re: Rewrite Bun in Rust has been merged

#631

Post by giancarlostoro »

manlymuppet wrote: post #627

Software is only as good as the end result; it doesn't matter how we get there. There is reason to be suspicious of LLMs, but people should stop getting so wrought up over _how_ the Bun team writes their software, until they have complaints over the software itself. Just let the team do their thing. You're free to reject the end result.

I agree, if the code gets tested endlessly, and audited, and nobody, not even the LLM can find major jarring issues with it, it compiles, builds, and works as expected, isn't degraded in any way, I don't think I care how you built the "new" rendition of the software.

Re: Rewrite Bun in Rust has been merged

#633

Post by drzaiusx11 »

antonvs wrote: post #614
fdsajfkldsfklds wrote: post #485

Earlier quoted context omitted.

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.

Even before the advent of LLMs, I have personally (and largely successfully) translated several production systems from one language to another. I've learned it's best to start with a mechanical translation, literally bug for bug, leaving shit exactly as I found it (just in another language.)

I've done Perl to Java, Java to Kotlin, Python to Ruby, Ruby to Java, C to Swift, you name it.

It's only when you change behavior during the rewrite that it becomes an intractable problem. If you ship a 1:1 translation, THEN you can start going through the list of "bugs" you found along the way. Tread carefully when it comes to this, however, as I can almost guarantee that within your non-trivial codebase there will be some code that implicitly _depends_ on a "bug" to function at all. This where shit hits the fan.

Re: Rewrite Bun in Rust has been merged

#634

Post by drzaiusx11 »

famouswaffles wrote: post #370
Barrin92 wrote: post #344

Earlier quoted context omitted.

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…

>if half of your files in a million line codebase are unsafe that doesn't tell you much any more. If half of your files in the first pass of a million line rewrite are unsafe then that's completely fine. Do you understand what the tag actually is? It doesn't even mean that the code is actually unsafe, just that the compiler can't guarantee its safety, which can happen for a number of reasons, some benign. Who rewrite…

A 1:1 translation, warts and all, is the _only_ foolproof way to do a language to language rewrite. Anything else in a non-trivial codebase is almost guaranteed to introduce regressions.

Re: Rewrite Bun in Rust has been merged

#636

Post by tempest_ »

giancarlostoro wrote: post #626
brandly wrote: post #595

Earlier quoted context omitted.

Aren't the Rust unsafes a reflection of the Zig it was ported from? However now that you're working with Rust, you're in a position to continue improving and eliminating the unsafes.

Plus I seem to recall the Rust community solved this issue by making tooling that proofs if unsafe code is truly unsafe, I remember one of the concurrent frameworks got scanned and people freaked out, the creator was about to abandon ship entirely as a result, don't recall what fully came of it. Anyway my overall point being, if there's already tooling to find the truly unsafe / bad code, it might make fixing it simp…

There is no Rust tooling that tells you if your unsafe code is shit or not. If there was you wouldn't need the unsafe stuff at all.

The Actix web stuff was the maintainer using unsafe code to increase performance (iirc, it was a long time ago) in what was the most popular rust web frameworks at the time. It has since declined and been supplanted by other projects but the push was mainly a web framework shouldn't need so much unsafe. They eventually ceded the project to another maintainer and went off to work on something else.

Re: Rewrite Bun in Rust has been merged

#637

Post by LAC-Tech »

petcat wrote: post #308
gm678 wrote: post #249

$ rg 'unsafe [{]' src/ | wc -l 10428 $ rg 'unsafe [{]' src/ -l | wc -l 736 Language Files Lines Code Comments Blanks ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Rust 1443 929213 732281 116293 80639 Zig 1298 711112 574563 59118 77431 TypeScript 2604 654684 510464 82254 61966 JavaScript 4370 364928 293211 36108 35609 C 111 305123 205875 79077 20171 C++ 586 262475 217111 19004 26360 C Header 779 100979…

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?

It's worth pointing out that "unsafe" in rust is not a very sound concept - it's not like a monad or "function colour" whereby the compiler can say "this code ultimately calls unsafe". It's more like a comment on steroids; you call unsafe in a function, write a comment about it, and no caller of that function would have any idea that it's calling unsafe code.

Re: Rewrite Bun in Rust has been merged

#638

Post by tempest_ »

Daishiman wrote: post #364
Barrin92 wrote: post #344

Earlier quoted context omitted.

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…

And? This is absolutely the correct and standardized way to do mechanical rewrites: you do a rewrite that maps directly to the original source so you can rely on the original correctness guarantees and bug-for-bug compatibility and log issues, and then you go into the next phase where you begin to use idiomatic constructs. This is the same in COBOL-to-Java ports that have been done in banking and insurance for the pa…

If the rewrite was zig to C and half the code was in __asm blocks is that different or the same?

Re: Rewrite Bun in Rust has been merged

#639

Post by Daishiman »

Barrin92 wrote: post #585
Daishiman wrote: post #529

Earlier quoted context omitted.

> If the whole point genuinely would have been to do a purely mechanical translation they could and should have written a transpiler, which would have had significantly higher correctness guarantees than this given that it'd be deterministic, but of course that would have defeated the PR purpose of this whole thing, which just looks like a marketing for Anthropic frankly If it were just a marketing stunt you wouldn't…

>You're being extremely negative about this whole endeavour without looking at the evidence that this effort is going far more smoothly than expected no I'm being negative because as I just said, if you want to do a purely syntactic translation you don't even need an LLM , that's called transpilation and we've been doing it programmatically for decades . This is the kind of thing that looks great to people who can't…

A. Transpilation is not 100% compatible because there are many idioms in some languages that cannot be directly translated to others. The lifetime system in Rust disallows a lot of constructs coming from languages with more relaxed constraints. Ironically transpilation will produce code with worse semantics than an LLM. B. At this point it's clear that LLMs reason very effectively about code and its intent. If you haven't asked Claude Opus with Max Reasoning to do, I suggest you give it a try, because the results are pretty fantastic.

Re: Rewrite Bun in Rust has been merged

#640

Post by drzaiusx11 »

famouswaffles wrote: post #624
Barrin92 wrote: post #585

Earlier quoted context omitted.

>You're being extremely negative about this whole endeavour without looking at the evidence that this effort is going far more smoothly than expected no I'm being negative because as I just said, if you want to do a purely syntactic translation you don't even need an LLM , that's called transpilation and we've been doing it programmatically for decades . This is the kind of thing that looks great to people who can't…

Transpilation won't get you passing 99.8% of a comprehensive test suite of a 700K+ codebase in a week (and maybe none at all) and that's assuming transpilation is practical for the pair in question. So if you remotely want these kinds of results, then you most certainly do need an LLM.

There are literally formally verified language transpilers out there today. They can get you 100% coverage without "cheating" like LLMs tend to do by modifying test suites to pass, etc.

I'm currently using an LLM in my day job to accelerate such a 1:1translation, and it's certainly "working"/making progress but God I wish I had a formally verified machine translator instead of this probalistic bullshitting LLM.

Don't get me wrong, it's extremely helpful and impressive in what it can do. But I trust it somewhat less than if I had done it myself, and for good reason. The lies I tell myself tend not to take down production. The lies my LLM tells me do however.

Post reply on HN